| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
|
Objectives:
The purpose of Design Solution in the Design phase is to develop, document and review a detailed product design so that developers and other downstream project team members have adequate specifications to complete development and unit test work.
Using the detailed requirements document, architectural design, project solution approach and BIA summary report, technical and business representatives work together as a team to lay out a detailed design for the product solution. The design may be at many levels and involve many types of design elements, both technical and business related. Finalizing a complete solution may be an iterative process in which the project team continues to drill down to lower levels of detail until the design is complete. Various tools may be used to establish the design including interactive facilitated sessions (Joint Application Design), use cases, and storyboards. Various prototype techniques may also be used.
Some of the technical components which may be included in the overall design are data management, data storage, security access, maintenance & support, application process design, user interface specifications, automated/system interfaces, system availability requirements and application integration specifications. Consider all levels of the product including, but not limited to, screens, reports, conversions, interfaces, menus, web pages and web content.
The project team presents to architects the plan for implementation of the architectural solution. This is done prior to test and production release and requires sign off from all Green Team members. See Green Team Process for more details.
It is important to create a visual design view of the technical solution to assist the business in understanding the design so they are able to validate and approve the design. This view should focus on how the solution will impact the business area and summarize the technical aspects of the solution in language that can be understood by a non-technical person.
Ensure that all design elements are mapped back to requirements and that there is a design for every requirement. This process may uncover additional requirements. In that case, complete project change requests and follow the Scope Management process in the Project Control section of the PMP process.
Refer to any corporate standards such as web page look and feel, before completing a design. Complete all designs to the level of detail necessary for the developers to have sufficient information to complete the development and unit test work. This level of detail will vary from project to project depending upon the organization and skill level responsible for development. If part of the project team, especially the developers are located off-shore, more details will need to be documented to ensure understanding.
Documentation of the design may take many forms. Many designs will be within various tools, however, it is recommended to at least complete a high level design document that references or links to all the design elements in order to ensure that the solution design is complete.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Obtain Development & Test Privileges activity in the Design phase is to setup access to the development and test environments for the project team and testers so that team members are able to perform their project activities.
This activity involves the design and granting of development and test environment privileges to the development team and any other project team members that will be involved in the testing effort. Include access to directories, documents, web pages and databases as appropriate. Consider remote access requirements as well as local area networks. See the StorageTek security policies for access privileges for external customers. Ensure that the security design is according to StorageTek security policies and procedures.
It is highly recommended that the test environment matches the production environment for security roles as this is a good way to test access.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Create Functional Test Plan in the Design phase is to determine and document the functional test plan so that test scripts, resources and the test environment are ready when needed.
The primary purpose of a functional test is to ensure that functional requirements have been met and that the product works end-to-end.
Focused on work unit to work unit flow and control as well as data exchange and consistency
Organized by related business processes and functions
Includes test of application security
Network impact modeling, if necessary (Network impact modeling is required if new/changed network infrastructure components or client software are introduced with the project)
Includes user negative testing at the project team's discretion
TestDirector is used to track functional and release test results. The project manager contacts the test team to request a project folder be set up in TestDirector for their project. TestDirector produces reports which can be used in test review and readiness review meetings.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
The purpose of the Review Control Activities activity in the Design phase is to ensure that the project adheres to relative control activities and identifies possible changes/additions to current control activities so that environments and processes are not negatively impacted.
This activity includes review of current GIS Control Activities (or SORCAS) as well as related business area Control Activities. Existing Control Activities are reviewed to ensure that the project adheres to relative Control Activities and identifies the need for modifications or additional to the Control Activities. The project manager works with the GIS Compliance Manager for changes on the GIS side and with the Business Process Owner for the business Control Activities. If no changes/additions are required on the business side, the project manager must obtain the Process Owner’s approval/statement that no changes/additions are required.
If changes/additions are necessary, the project manager should incorporate actions necessary for making the changes/additions throughout the project as appropriate. For example, if a new control activity is required and as part of that control activity, a report needs to be produced, the report requirements should be included in the requirements document, design, develop, test plans, business roll out plan, training, technical implementation plan, etc.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
Objectives:
The purpose of Create Training Plan in the Design phase is to determine and document the training requirements and schedule for the project so that training is developed and delivered in a timely manner according to the project plan.
This activity focuses on training requirements for the project. Some training requirements may have been documented in the scope statement and/or requirements document. However, it is in this activity that the project team can drill down to more detailed training requirements and plans. The training plan is more than just a schedule. It should include training objectives, success criteria, desired results, critical issues, risks, assumptions and constraints. Training may be formal or informal and may take several forms (class, on-line, documentation to be read, etc.). Training may be for the project team, maintenance & support team, as well as direct and indirect end users. Where training fits into the over all project life cycle must be considered. It is especially important to document other activities in the project that may be dependent upon training activities and vice versa.
The training plan should focus on the following elements:
Training audience – the groups to be trained and the type of training for those groups. Skill levels, locations and number of individuals in each category may also be included.
Training approach – this element describes the types of training/modules. For each type of training define who is responsible for creating and delivering the training, the approximate length of the class, size of class, number of individuals to be trained, high level schedule and format of the classes.
Class Development and Scheduling – this element should include the detailed tasks needed to accomplish the various forms of training. This element could be added to the project schedule.
Training Logistics – training locations and materials that need to be in place for the training. This activity could also include travel plans, off-site arrangements, etc.
Class/Training Schedule – this element will evolve over the project lifecycle, but will eventually delineate the actual schedules for training which will be communicated to various user groups.
Things to be considered include:
Dependencies – for example, do business processes have to be modified before training can be developed and delivered
Constraints
Facilities
Resources to do the training
Resources to develop the training
Risks
Schedule for development and deployment
Training logistics
Include training for the project team as well as support teams and business teams.
Success measurements
Training environment – be sure to set the environment up prior to any planned training sessions
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Create Maintenance & Support Turnover Plan in the Design phase is to work with support teams to identify the turnover preparation tasks needed so that there is a smooth transition of the project's product to the maintenance & support team.
Description:
The Maintenance & Support Turnover Plan should include the following tasks.
Determination of turnover requirements
Assignment of tasks to meet the turnover requirements
Identification of technical project documentation (e.g., design documentation, configuration management, etc.) that should be made available to the project team and how it should be made available
Review and update or creation of disaster recovery documentation
Review and update or creation of WORP information
If support team members are part of the project team, they should drive the creation of the Maintenance & Support Turnover Plan. If there are no support team members on the project team, support team representatives must be included in the creation of this plan to ensure that all required tasks are identified and assigned, and that impacts to the project schedule, budget and resource requirements are considered.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Conduct Design Quality Audit in the Design phase is to review the project folder to ensure that all required documentation exists and is stored correctly so that GIS standards will be met.
The quality audit consists of the following steps:
The project manager completes the quality audit request form and sends it to Quality Assurance (QA).
The audit consists of a review, by Quality Assurance, of the project documentation to verify that all required documents have been created and are available in the project folder. Currently this is an independent audit and does not require the project manager's presence.
Once the audit is completed, a compliance audit report is produced and sent to the project manager.
The QA Corrective Action template is used by the project manager to document steps taken to resolve the non-compliances. This report must be completed with all action items closed, and sent back to Quality Assurance within 30 days after receiving the compliance audit report before escalation occurs.
These reports are used to provide periodic summary reporting for GIS management.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Review Design, Cost Plan & Schedule in the Design phase is to review and obtain business approval on the design, cost plan and schedule so that the project may continue to the next phase.
It is important to note that although this formal review allows a project to continue to the next phase, most projects continue moving ahead (fast-tracking) with the next phase while the reviews are being scheduled. Although this may introduce some risk of re-work, it is less costly than the risk associated with delaying a critical path activity and impacting the commit date. It is also important to note that projects using an iterative approach may perform this activity several times throughout the project life cycle.
This activity is a formal gate review which is performed in two steps – an internal review and an external review. In addition to covering a summary of the various design elements of the project, also review the schedule (milestones), cost plan, issues, accomplishments, next steps and risk mitigation plans. The design review is a review of the entire plan for the project. The project plan documents include, but are not limited to:
Business Case
Scope Statement
Project Estimates from Project Initiation and Analyze Phase
Requirements Document
Project Solution Approach
Architectural Design
Design/Technical Specification
Visual Design View for Business
Test Approach
Test Plan
Project Schedule
Assumptions and Constraints
Communication Plan
Training Plan
Risk Mitigation Plan
Resource Requirements (from the status report)
Critical Computer Resource Log
Cost Plan (from the status report)
The internal review may include review of the actual deliverables. Typically, the external review with the customers is based upon summarized information from the entire project plan.
This activity is the last task in the Design phase because all other activities must precede it in order to have sufficient information to set the project schedule, cost plan and the commit date. The commit date is the date the product is available in production for the intended audience to use. The deploy date is the date the intended audience will begin using the product.
Prior to communicating the commit date to all stakeholders, the project manager must:
Review final project estimates with GIS managers. If these estimates are significantly different from those produced during the Analyze phase, GIS management should determine if steering team approval is needed to continue work on the project.
Review the project documentation (from the Analyze & Design phases) with the managers responsible for the resources to obtain their commitment of resources
Validate accuracy and completeness in all project plan documentation.
Project manager coordinates and facilitates the review. Those invited to this review should be:
Project team
Affected GIS Managers
TDMs
Infrastructure team leads
CAROT representatives
Review project plan deliverables.
Issues are documented and addressed (tracked to closure).
Meeting minutes* and action items are documented and distributed.
NOTE: The internal review is conducted before the external review.
Project manager coordinates and facilitates the review. The sponsor, requestor, business users and other stakeholders are invited.
External reviews walk through the visual design. These reviews are not technical in nature, but focus on the business.
Issues are documented and addressed (tracked to closure).
Meeting minutes* and action items are documented and distributed.
Project manager obtains the sponsor and requestor’s signatures on the Design, Cost Plan & Schedule Acceptance form. These may be obtained via an email approval which is then attached to the Design, Cost Plan & Schedule Acceptance document.
* Meeting minutes must include the following information and a copy of the meeting minutes distribution list must be filed in the "Deploy" project folder:
Date
Name of meeting
List of attendees (including those on the phone)
Decisions
Action items - evidence that they were tracked to closure
Action
Assigned To
Status
Target Date
Actual Date
Once the external review has been completed and approval has been obtained, the project manager should baseline all documents that are part of the project plan to date. Any changes to the project should be saved in new versions of the appropriate documents. The original baseline versions should be retained.