 |
|
|
Analyze Activities
Last Update: September ??, 2004 |
Analyze Phase: Perform Project Startup
The purpose is test purpose of Perform Project Startup in the Analyze phase is to initiate various project control activities so that a project folder system is available and project control documentation is ready for use. Description:This activity begins after a project manager has been assigned and has received any project initiation documentation, specifically the Business Case. The project manager should complete the major project startup activities as follows:
Analyze Phase: Complete Scope Statement
The purpose of Complete Scope Statement in the Analyze phase is to define the project scope, high level requirements and business and system impacts so that the project team and the sponsor are in agreement as to the starting framework for the project. The scope statement becomes the baseline for all future project activities. Description:As soon as the project has been approved through the Project Initiation process and a project manager has been assigned, the business case must be expanded into a full scope statement. This document forms the basis for an agreement between the project team, and the requestor and sponsor by identifying both the project objectives and the project deliverables. The scope statement includes:
Project Change Requests:Each project team should have a Change Control Board (CCB) which is used to determine how to disposition requested changes. The CCB is comprised of the sponsor, requestor, project manager and other key stakeholders identified by the team. Significant project changes must go back through the GIS Approval Committee process. Contact a PMO member to get on the agenda for review or for assistance in deciding if the changes are considered significant. Depending on the impact of the changes, the project may need to also go back to the GIS PST.
Document Baseline & Version Control Instructions:
|
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
|
Objectives:
The purpose of Plan Resources in the Analyze phase is to identify, obtain and manage all project resources (all goods and services, including human resources) so that the appropriate resources are available when needed throughout the life cycle of the project.
Obtaining resources is an iterative process throughout all phases of the project. Early in the Analyze phase the project manager identifies as best as possible the roles (skills) and effort needed to complete the project plan. The project manager estimates the project duration and documents target effort using the "Target" column of the Resource Requirements sheet in the Status Report. Any known computer resources which are critical to the success of the project should be documented on the Critical Computer Resource Log (see instructions included in the template).
Resources may come from many organizations, not only GIS. It is especially important to gain approval and commitment for business resources needed by the project team.
Resource requirements are continuously updated throughout the life of the project as the project progresses and more detail is known. Updated effort targets are entered in the Target columns. If the updates are significant, contact STK GIS PMP Support to see if the GIS Approval Committee must review the changes. It may also require approval of the PST.
During the Complete Scope Statement activity, the project manager works with the appropriate managers (and TDMs when needed) to identify the resources that will be required to complete the requirements document, the WBS and the resource requirements (skills).
Project manager also contacts the business managers for business resources needed on the project, including resources needed to support testing throughout various phases of the project.
Managers identify resource availability and assign resources to the project.
Once the requirements document and the WBS are complete, the project manager updates the Resource Requirements by resource role. For example: DBA, Web Developer, Tester. If two or more of the same role are needed (2 DBAs, 3 Testers, etc.) enter each on its own row. This includes business resources required throughout the project. It also includes resources for code reviews, identification and delivery of maintenance & support turnover documentation, backup when key resources are unavailable and resources which will be required for production support once the product is deployed.
Project manager estimates the effort needed per resource role based on the WBS.
Through the project life cycle, the project manager reviews resource requirements with the appropriate managers at agreed-to intervals, to identify changes in resource needs. Due to constrained resource skills and availability, it is imperative that resource changes/needs are communicated as far in advance as possible.
The procurement processes are outside of the GIS PMP and are managed by the Sourcing department. The following URL provides links to related forms, instructions and information: http://gandalf.stortek.com/wwsrc/purchasing.shtml.
See your manager for assistance in determining the specific steps which must be followed for the individual project's circumstances.
At times it may be necessary to obtain resources through external sources, such as consulting firms. At StorageTek, the project manager makes the request to purchase goods and/or services to their manager.
New hardware and software purchases must go to the TRC (contact the architecture manager or the architecture team lead).
Once the forms are complete, they go through a series of approvals and end up in the Sourcing Department which is responsible for procurement management activities.
The project manager’s responsibility is to work with the purchasing agent to clarify and validate the project’s requirements for the goods/services being purchased.
After the document has been completed and approved at the end of the Design phase, enter the target numbers into the Baseline column. This will automatically populate the "Cost Plan" and "Metrics" sheets of the Status Report. Do not make updates to the baseline numbers unless approvals have been obtained and the PMO has instructed you to change your baseline numbers.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
Objectives:
The purpose of Conduct Kickoff Meeting in the Analyze Phase is to hold an initial project meeting so that all team members are brought up to speed on project information.
Project Kickoff is an opportunity to bring the project team together to discuss scope, requirements, processes, roles and responsibilities, expectations, project organization, project documentation, project tools and all other project information. This activity includes planning for, conducting, attending and documenting the kickoff meeting. Prior to the meeting make all documents available to the project team for review. Invite not only project team members but also business and technical subject matter experts who may be impacted as well as other interested business, technical or organizational areas.
There may be a couple of kickoff meetings – one for the initial core team that will complete the requirements document and the WBS. A second one with the expanded team identified and assigned when the schedule is built.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Determine Requirements in the Analyze phase is to obtain, understand, validate, document and gain business signoff for all business and technical requirements so that the project is positioned to meet stakeholder expectations.
The high-level requirements used to establish project scope are refined to detailed business and technical requirements that clearly define the functions and services to be delivered and the critical attributes of those functions and services. Review the scope statement to identify high-level requirements and determine if there are any additional requirements. Once all high-level requirements have been captured, drill down to the detailed requirements.
Individual requirements should be unambiguous, understandable, complete, appropriate, and verifiable. The set of requirements should be consistent, complete, maintainable, and traceable. An example of a poor requirement is “Easy to use”. A better requirement would be “No more than 3 mouse clicks from entry to home page to lowest level of information.”
Each individual requirement must also include user acceptance criteria. Identifying user acceptance criteria assists in understanding the full extent of the requirement. User acceptance criteria evolve later into test cases for use during the testing cycle.
User acceptance testing and formal acceptance of the product is based on compliance with the detailed requirements. Delivery of products and services will be measured at the end of the project against the agreed upon baseline requirements as well as any additional requirements approved by the sponsor and requestor during the scope management process.
Requirements fall into several categories, consider requirements in each category to assist in definition of all project requirements:
Functional requirements describe the features of the system in user language. They include requirements for business functions, transactions, tasks, user profiles and access control, security issues, training, documentation, information/data, reports, data conversions, content and content management and international/global/localization. They also include any ISO compliance or regulatory requirements.
Performance requirements identify any requirements for capacity, speed, up time, batch-processing turn around window, data management and retention, and business continuity.
Interface requirements identify automated interfaces to other internal systems and applications. They also include external interfaces to vendors, suppliers, customers, government agencies, and companies such as 401K administrators. Include frequency and formats when known. Identify both incoming and outgoing interfaces.
Design requirements identify requirements for operating system, hardware, software, user-interface standard and type, architecture and security structure. Please note that this requirement type does not imply that you should include application or system design in the requirements document. Instead it asks you to identify if there are any design constraints that must be considered to be a project requirement.
Implementation requirements identify requirements for program language, use of existing equipment, installation and training.
Maintenance and support requirements are identified by the support teams and include requirements which are necessary in order to take over production support of the new/enhanced project product.
If requirements extend beyond the project scope the scope statement must be revised or the requirement must be excluded (see Project Control: Scope Management). Example, the scope statement indicates that the audience will be US only, however, there is a requirement that France needs the application. This change must go through the formal project change control process.
Each project team should have a Change Control Board (CCB) which is used to determine how to disposition requested changes. The CCB is comprised of the sponsor, requestor, project manager and other key stakeholders identified by the team. Significant project changes must go back through the GIS Approval Committee process. Contact a PMO member to get on the agenda for review or for assistance in deciding if the changes are considered significant. Depending on the impact of the changes, the project may need to also go back to the GIS PST.
After the document has been completed and approved, save as a baseline version.
The scope management activity in the Project Control portion of the PMP is used to evaluate project change requests throughout the project lifecycle.
Approved project change requests that impact base-lined documents should be incorporated into a new version of the document. Do not overwrite the baseline version or subsequent versions – there should be a version for each change after the initial baseline document.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
The purpose of Conduct Business Impact Analysis in the Analyze phase is to understand the business impact of the project's output so the project and on-going support costs can be effectively estimated and customer expectations for system availability are met or exceeded.
Both the interview forms and the summary report are stored by the Business Continuity Planner on the Business Continuity website. A copy of the summary report must also be stored in the project's Analyze phase sub-folder.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
The purpose of Apply Measurement Guidelines in the Analyze phase is to ensure applicable measurements are documented so that the success of the project can be assessed objectively and to identify triggers for re-planning activities.
The measurement guidelines document the measurement activities required on all GIS projects. Any deviations from this plan or project specific measurements must be documented and approved by the appropriate manager.
Project metrics are captured and analyzed for the following reasons:
To provide the project manager with information needed to manage, track and report progress and assess performance during project execution.
To identify which measurements will be recorded and reported including their purpose, frequency of collection, granularity and source and to identify when corrective actions are needed.
To document project metrics and use them in future estimating of projects with similar characteristics.
To provide information that can be used to identify areas for process improvement.
To identify specific thresholds or measurements used on the GIS dashboard.
To relate project measurements to the objectives of the organization.
Measurements will be taken during the project and at the end of the project. Consistent measuring will ultimately allow the GIS organization to better manage customer expectations, improve the development process and improve our estimating ability.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Determine Project Solution Approach in the Analyze phase is to use a decision analysis method to assess various solution approaches against project requirements so that the project team, business users, sponsor and requestor have an understanding of the product to be delivered by the project.
In general the project approach will define the manner and methods to successfully complete the project objectives and commitments. The project approach may be defined in one or more ways.
This activity defines the boundaries for the project and/or the general manner and methods for successful project completion against objectives and commitments. At this point in the project lifecycle the solution/approach should be described in business terms. Engineering terminology will be included at the time of solution (technical) design. The boundaries identify the primary functions and services to be delivered by the project. The approach provides a general agreement on how the functions and services will be provided. For example, a web page vs. an SAP module.
The project team, sponsor and requestor also need to determine if the ultimate product will be delivered through a series of generations (phases). If so, the team needs to determine what portion of the product will be delivered in each generation.
In addition, they must determine if they will use an iterative or fast-track approach within the project lifecycle. If multiple iterations will be performed, the project must determine the iteration approach for the project, specifying iteration objectives. If a fast-track approach will be used, the team must pay particular attention to additional risk this method will introduce into the project lifecycle. These decisions will help determine how the project schedule is built, how the commit date (or dates) will be established for the project, as well as how reporting on percent project complete will occur.
Determine Project Solution Approach Instructions:
Determine a way to define a project approach. Examples are solution alternatives, product groupings, project iterations, project phases and fast-tracking.
Determine a set of factors or criteria to use to evaluate the approaches. Possible factors are:
Business objectives
Business and technology direction
Key success factors
High-level business requirements
Project constraints
Policies
Project strategies/tactics
Cost
Timelines
Resources - number and skills
For each approach, if there is more than one to be considered, follow a decision analysis method where each approach is evaluated against the same criteria.
Document the recommendation resulting from the decision analysis activity.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Assess Technical & Architectural Impact in the Analyze phase is to review the technical impact of the proposed project solution against existing or proposed architectural standards as well as the existing technical and application infrastructure so that the project's product will be planned within the generally accepted architectural framework and there will be a complete understanding of the technical infrastructure/architectural requirements and resources needed for implementation of the project.
The architectural design document and technical impact checklist are completed by the architect with the assistance of the project manager, technical project team members, and when appropriate a supplier. These documents provide basic architectural information that helps the architecture team and CAROT (Computing Asset Rationalization Enablement Team) to:
Determine impacts to the current architecture
The need to present the project to the TRC for review
Infrastructure resource requirements
On-going support requirements
Many projects will fit into the existing infrastructure and applications environment. However, others may require changes to StorageTek’s defined architecture and/or purchase of new hardware and software. The TRC must approve all such changes. The CIO must approve all new software.
When the architecture team has the opportunity to review project impacts early in the project lifecycle, they can also contribute suggestions as to the appropriateness of various solutions.
If necessary, initiate (or update) the Critical Computer Resource Log with those items which are determined to be critical to the project's success.
This activity provides the opportunity for a detailed architecture walkthrough. The detailed walkthrough of architecture documentation also includes sign off from all Green Team members. See the Green Team Process for more details. Documentation to be used and included at this time, where applicable, will be as follows:
Physical/logical diagram, including HW/SW requirements (Boxes, OS, DB, tools, etc.)
Special configurations, settings, etc.
Any licensing considerations, vendor documentation, contacts
Special considerations for impact to existing systems or environments
Documents proof-of-concept lab test results
Detailed information about the impact to the infrastructure will also help the project manager understand other areas that should be contacted for the purpose of determining requirements.
Architects and Green Team members work side by side on architecture issues throughout the project, where necessary.
Project manager sends a copy of the requirements document, the scope statement and the project solution approach to the architecture manager and team lead.
Architecture manager or team lead will assign the appropriate architects and communicate their names to the project manager.
Project manager coordinates a meeting between the technical project team members, the assigned architects and a supplier if appropriate. All invited participants must either attend or send a designated representative to the meeting so that re-work is minimized.
The architects will produce the architectural design and the technical impact checklist and send copies of these documents back to the project manager.
The architects will also decide if the project needs to go to TRC.
If this is a project that has already gone to TRC, the architects perform a detailed walkthrough of architecture documentation with sign off from all Green Team members.
The project manager will forward a copy of the technical impact checklist to the CAROT email address. CAROT members review the checklist to determine which CAROT members are needed on the project team. CAROT members assigned to the project team will assist the project manager in clarifying production support requirements. The project manager then informs the TDMs of project objectives for production support considerations.
Analyze Phase:
Setup Development & Test Environments
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Setup Development & Test Environments in the Analyze phase is to complete all technical tasks necessary to ensure the readiness of the development and test environments so that the project team has complete access to fully configured development and test environments.
This activity ensures that the appropriate project-specific development and test environments are in place. This activity includes designing and building the architecture. This involves the full spectrum from obtaining hardware and software to installation and configuration of the hardware and software, network, PC, etc. It includes the installation and setup of new tools. It also includes security design and access, database setup and installation. Training may also be necessary before the setup can be completed.
Analyze Phase:
Create Test Approach
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
|
Objectives:
The purpose of Create Test Approach in the Analyze phase is to develop, document and plan the types of anticipated project tests so that all impacted resources are aware of project expectations and a preliminary schedule is developed for all project testing.
All projects must plan for unit testing, code reviews, functional testing, release testing, user acceptance testing and production validation. When needed, projects should also plan for performance testing.
Standards – unit testing, etc. – for the project
High level test cases (use cases)
Tools needed for testing
Resources (roles) needed for testing
Testing scope
Methods of testing, including capturing results, feeding information back to the team (*TestDirector is used to track functional and release test results)
Training needed before testing can happen
Facilities for testing (location, PCs, etc.)
Planning far enough ahead when need to bring in users, especially from outside
Gaining business user commitment to providing needed resources
Who will write the test cases, test scripts
Test Environments
Use of appropriate archived test materials from past projects involving the KPE being tested. This includes any test beds or other appropriate materials within TestDirector and/or the archive folders.
* The project manager contacts the test team to request a project folder be set up in TestDirector for their project. The test team can also provide training for the TestDirector tool if necessary.
Analyze Phase:
Create Project Schedule
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Create Project Schedule in the Analyze phase is to develop the project schedule (work breakdown structure, work effort estimates, dependencies and resource assignments) so that the resources and effort can be documented so that all project stakeholders have a common expectation of what can be expected from the project and so that the project manager has a tool to use to guide and manage the project.
As part of this activity the project manager with the assistance of the project team identifies all work to be done on the project. WBS activities that are too large for effective management are broken out into smaller activities or tasks. Task dependencies and resource assignments are documented. The project schedule will then be determined based on the agreed-upon staffing level and work effort estimates. The critical path should be analyzed and resource leveling completed to ensure that the schedule is realistic.
Although creating the project schedule should be an iterative effort, it also provides a baseline for progress measurement and project control. Keep in mind that any changes to resource needs, especially timing, must be reviewed with managers of the resources. Communicate to all management, GIS and business, the level of effort and time frame in which resources are required.
The project schedule lists planned dates for performing activities and meeting milestones. It is expected that this document will change over time as part of the Schedule Management activity under the Project Control phase.
GIS uses the MS Project application for project schedules.
Identify major deliverables required to complete the project and break them into smaller, more manageable activities until they are defined to the point that the project team members have sufficient details to accomplish the activity. Start with the basic structure of the GIS PMP by using the schedule template. Add tasks as necessary for the specific project. Project managers are free to adjust the predecessors and successors to fit the project's needs. Tasks may also be re-organized to fit the project's needs.
Identify whether or not the team can adequately estimate costs and durations at the level the activity is identified. If not, break the activity down into smaller activities/tasks. For example, if the activity is “Build the Production Environment”, it may be difficult to estimate resources and duration at this level. Break this into smaller activities/tasks such as “Setup server”, “Install OS”, “Build database”, etc. Perform this step for each major activity.
To help verify that the activity/task has been captured at the right level, ensure:
that the activity is required
that the team can estimate the duration and resources required for the activity
that it can be assigned to a single entity (person, team, department, etc.).
If not, repeat Step 2. Complete this step for each deliverable.
For each activity identify the predecessor and successor activities. During this step, consider the types of dependences (finish to start, finish to finish, start to start and start to finish) and lead and lag time.
Link activities to "child" activities rather than to "parent" activities.
All activities must be linked to at least one successor and one predecessor activity. The only exception is the first and last activities. This will allow Microsoft Project to automatically determine the project's critical path. It will also provide the ability to predict how delays or early finishes will impact the entire project schedule.
Estimate the duration of each activity based on the activity, resource skill levels and availability, experience, historical data and known risks. Standard project management practices indicate resources should not be scheduled for more than 70% of their available time. This allows time for meetings, training, etc. In addition, there are formulas which can be used to help with estimating. Always build some “padding” into the schedule to compensate for unknowns. Be sure to document how the schedule was built in case adjustments need to be made in the future.
Review the schedule to ensure that all project deliverables are represented on the schedule. Use the requirements document to complete this step. For example, if one of the requirements is to provide a web-based tutorial for the application being built, make sure that the tasks required to build the web-based tutorial are on the schedule.
Each project team should have a Change Control Board (CCB) which is used to determine how to disposition requested changes. The CCB is comprised of the sponsor, requestor, project manager and other key stakeholders identified by the team. Significant project changes must go back through the GIS Approval Committee process. Contact a PMO member to get on the agenda for review or for assistance in deciding if the changes are considered significant. Depending on the impact of the changes, the project may need to also go back to the GIS PST.
After the document has been completed and approved, save as a baseline version in the Project Control folder.
The Scope Management activity in the Project Control portion of the PMP is used to evaluate project change requests throughout the project lifecycle.
Approved project change requests which impact base-lined documents should be incorporated into a new version of the document. Do not overwrite the baseline version or subsequent versions – there should be a version for each change after the initial baseline document.
Analyze Phase:
Create
Cost Plan
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Create Cost Plan in the Analyze phase is to identify expected project costs so that stakeholders understand the estimated project costs for planning and decision making purposes.
The cost plan is a way to identify project costs, both expense and capital. These costs should be broken out by each month of the project, throughout the project life cycle. The summary of this information is recorded, tracked and monitored in the status report.
Use the Cost Plan portion of the Status Report (instruction are in the Status Report User's Guide) to calculate and document estimated project costs.
Prior to the Design, Cost Plan & Schedule review, make any necessary changes to the cost plan. Be sure to identify and document each change. Along with the Design, Cost Plan & Schedule review, cover the estimated costs with the sponsor and requestor and obtain their approval. This becomes the “baseline”.
Project managers do not usually have visibility to actual budgets. For monitoring and reporting purposes, assume that actual costs are equal to baseline costs unless you are aware of significant differences. If significant negative differences, determine corrective action plans and record in the status report.
Update the "Actual Costs" portion of the "Cost Plan" sheet of the Status Report each month.
Analyze Phase:
Conduct
Quality Review
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Conduct Quality Review in the Analyze phase is clarify quality assurance expectations, identify any project document non-compliances, and get any document waivers approved and documented by QA so that quality issues are identified early in the process and ongoing standards expectations are understood.
In this meeting the project manager will review the project folder structure and content with Quality Assurance to confirm compliance with GIS standards. If the project manager believes that any of the required project documents are not applicable to the project, a list of these waiver candidates should be presented to Quality Assurance for approval. Waiver approval should be noted in the PMP Checklist (for each document waived) and in the meeting minutes. Any identified non-conformances will also be documented in the meeting minutes and reviewed during the Design Quality Audit to ensure closure.
Analyze Phase:
Review
Project Estimates
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Review Project Estimates in the Analyze phase is to review the current estimates for schedule, cost, requirements and resources with affected GIS managers to identify any significant changes in estimates from those developed during project initiation so that effective and accurate communication of the target information is assured.
This is an internal GIS review of the current targets for schedule, cost, requirements and resources. These estimates should be developed using an iterative approach until the end of design when the baselines are established. During this review, GIS management assesses the magnitude of changes in the estimates with those developed during project initiation. If the current estimates are significantly different from those created during project initiation, GIS management should determine if steering team approval is needed to continue work on the project.
This meeting should include the review of the following project deliverables:
Project initiation estimate document
Assumptions and constraints
Identified risks
Scope statement
Requirements Document
Solution Approach
Initial project schedule
Initial cost plan
Initial resource requirements (from the status report template)
Current targets including deployment date, project costs, resource requirements and design approach
The review presentation template can be used to summarize the highlights from all of the required documents.
Design Activities
Last Update: September ??, 2004 |
Design Phase: Design Solution
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. Description: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.
Design Phase: Obtain Development & Test Privileges
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. Description: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.
Design Phase: Create Functional Test Plan
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. Description:The primary purpose of a functional test is to ensure that functional requirements have been met and that the product works end-to-end.
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.
Design Phase: Review Control Activities
|
| 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.
Develop & Test Activities
Last Update: September ??, 2004 |
Develop & Test Phase: Determine Code Version Control Method
|
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
|
Objectives:
The purpose of the Determine Code Version Control Method activity in the Develop & Test phase is to identify how developed code will be managed so that integrity and security of the development effort is maintained.
This activity is a subset of Integrated Change Control, also known as Configuration Management. Reference Project Control: Integration Management.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
Objectives:
The purpose of the Develop & Review Content activity in the Develop & Test phase is to ensure that all customer-facing output conforms to StorageTek standards and has been reviewed by the business area and approved by the StorageTek Legal department (if needed) prior to implementation so that the product aligns with the consistent and professional StorageTek branded image as well as business area strategies and direction.
This activity addresses the need to clearly understand the business requirements for content. Content includes any text, pictures, instructions, etc. contained within a user interface or a web page. Content is static in nature. Content is NOT data populated from a system.
Customer-facing content (output) is any project deliverable that could be seen by StorageTek’s external customers and/or suppliers. This includes (but is not limited to) web pages, quotes, invoices and contracts. Content on customer-facing documents with legal implications, such as a notice on a web page that indicates pricing is subject to change without prior notice, must be approved by the Legal department.
If Legal approval is required, be sure to allow plenty of time in the schedule as it can take weeks to get something through Legal.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Develop Product activity in the Develop & Test phase is to construct the identified project solution so that the product meets all requirements and project objectives.
This activity involves technical construction of the product, including data conversion, system code, releases, installations, interfaces, reports, user interfaces, and supporting documentation. The product is the sum of all that is built and delivered as part of the project. This activity also includes implementation of the architectural plan as signed off by Green Team members. See Green Team Process for more details.
Develop Product, Conduct Unit Test, Perform Code Reviews and Conduct Functional Test activities are iterative in nature and are repeated until successful functional test results are achieved. It is also important to note that projects using an iterative approach may perform these activities several times throughout the project life cycle as they work through each iteration.
If this activity leads to any design changes, the project team needs to have the baseline design re-approved.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
The purpose of the Conduct Unit Testing activity in the Develop & Test phase is to ensure all work units operate as designed, without error, so that there is confidence that the individual pieces work as expected and meet the required functionality.
This activity involves the individual component testing to verify functionality and expected results. This activity includes development of unit test cases, unit test design, execution, capturing and analysis of results, rework to fix defects and retest. Components include application changes and any new functionality, interfaces and data conversion. Additional components are hardware and software installs, database setup and security access.
Develop Product, Conduct Unit Test, Perform Code Reviews and Conduct Functional Test activities are iterative in nature and are repeated until successful functional test results are achieved. It is also important to note that projects using an iterative approach may perform these activities several times throughout the project life cycle as they work through each iteration.
Execute and test every line of code or widget for the work unit
Test the work unit for all of the following
all conditional and compound conditional variations
test loop limits
error handling
file and data interaction including empty and multiple record files
all user interaction including, but not limited to, screen layout and navigation, numeric and alpha numeric fields, list boxes, drop downs, scrolls, etc
Usability test
human factors, navigation, presentation
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
|
The purpose of the Perform Unit Test Code Reviews activity in the Develop & Test phase is to validate that code is documented, accurate, efficient and supportable so that rework costs are reduced and quality of project deliverables is increased.
This activity involves the review of project-delivered products by team members and technical experts to validate that code is document, efficient, accurate and supportable. Unit Test Code Reviews identify defects in project deliverables early in the project’s System Life Cycle. The earlier defects are identified, the less costly it is to take corrective action.
Unit Test Code Reviews are held by the project team to ensure that project deliverables meet functional and technical requirements, adhere to documented standards and procedures, are accurate and contain the appropriate level of detail. Participants of the review assume the responsibility for the overall quality of the deliverable by assisting in defect identification. The author of the deliverable is responsible for the implementation of the findings and recommendations of the Unit Test Code Review participants.
Unit Test Code Reviews are scheduled at specified points, based on project events (i.e. milestones) or time passage. Periodic and event-driven reviews for the project are included in the project schedule. As unplanned events, such as changes to requirements or conflicts not resolvable at lower levels, occur during the life of the project, additional event-driven reviews may be scheduled. These reviews will be scheduled on an as-needed basis.
If there are multiple deliverables completed at approximately the same time by the same author, the author should determine which deliverables are similar in nature and include those deliverables in one Unit Test Code Review session. This will help determine the type of skills necessary for the review participants to possess in order to effectively review the material (for example, review of source code may require participants to have programming experience at a minimum).
Develop Product, Conduct Unit Test, Perform Unit Test Code Reviews and Conduct Functional Test activities are iterative in nature and are repeated until successful test results are achieved. It is also important to note that projects using an iterative approach may perform these activities several times throughout the project life cycle as they work through each iteration.
There are various roles for participants to perform in the Unit Test Code Review process. The following is a brief definition of the responsibility of each role.
|
ROLE |
RESPONSIBILITY |
|
Developing Author |
Responsible for initiating the review, preparing the review package, and making any necessary changes to the deliverables. The author will work with the Project Manager or Technical Delivery Manager to fill the Unit Test Code Review roles with appropriate team members (could include members not specifically assigned to the project). The author will reserve the location and time for the session to occur. The author is usually the person that developed the work product to be reviewed. |
|
Facilitator |
Responsible for direction during the Unit Code Review session. The facilitator will review the purpose of the session, establish session guidelines and determine that all participants have satisfactorily prepared for the review session. The facilitator is responsible for ensuring that the Unit Test Code Review participants have come to an agreement on actions to be taken after the review session is completed The facilitator will also summarize the session. The facilitator is a unique role unless the project team is small (2-3 people) in which case the facilitator may be a reviewer and/or the recorder. The facilitator may never be the author. |
|
Reviewer |
Responsible for reviewing the project deliverables prior to the review session. The reviewer will actively participate in the session by voicing defects, issues, concerns, and/or comments regarding the deliverables being reviewed. The reviewer will determine actions to be taken after the review session is completed. This role is generally assigned to the technical leader for the project (or an appropriate designee). |
|
Recorder |
Responsible for formally documenting defects/issues/questions identified during the Unit Test Code Review session, properly storing the Unit Test Code Review Report and Unit Test Code Review Defect Record documents. The recorder will validate that all defects and issues have been resolved and sign the Unit Test Code Review Report upon resolution of all changes. The recorder will also be a reviewer. |
|
Project Manager (PM) |
Responsible for ensuring that unit test code reviews occur. The PM is also responsible for assigning resources and roles for the Unit Test Code Review session, with the assistance of the author and/or Technical Delivery Manager. Resources should be assigned based on work loads and on prior roles taken in previous Unit Test Code Reviews. (For example, a person should not always be the recorder for Peer Review sessions unless the project is staffed with only 2 people.) |
|
Software Quality Assurance (SQA) |
Observes the Unit Test Code Review session and determines if the Unit Test Code Review process is being followed. SQA will have an open invitation to all Peer Review sessions and will be required to attend a minimum as defined in the SQA plan. |
This activity includes the following steps.
|
Steps |
Description |
|
Initiate a Unit Test Code Review |
The author completes the projects deliverables (e.g. code, documentation, etc.) and moves these deliverables to the location designated in the project’s configuration plan. The author also prepares the Unit Test Code Review package (put the file names in here) |
|
Coordinate the Unit Test Code Review |
The PM and author reviews the skills necessary for the participants of the review. They should look at the availability of project team members in selection of assignment of roles. They select participants that have an appropriate level of detail knowledge, and have skills or knowledge that will enable the contribution of meaningful comments. There should be a facilitator, a recorder and a reviewer for the review to take place. It is possible for a single person, other that the author, to take any or all of these roles.
The author schedules a time a place for the Unit Test Code Review to occur, completes the peer review packet and distributes it to the unit test code review team.
Team members review the packet prior to the scheduled review using, but not limiting themselves to, the criteria outlined in the review checklist. |
|
Conduct the Unit Test Code Review Session |
The facilitator conducts the Unit Test Review Meeting and ensures that the results are recorded in the Unit Test Code Review form. The facilitator establishes the session guidelines, leads the reviewers though each deliverable asking for defects or issues page by page (or as appropriate in the case of a demo or prototype). The recorder will formally document any defect, issue or change discussed for a deliverable on the Unit Test Code Review form along with severity codes, fault reasons and fault classes for each defect as it is discussed or after all defects have been documented and prior to obtaining consensus on the endorsement action. (Issues will not have a severity code, fault reason or fault class).
The author may address specific areas of concern during the review session on any deliverable being received. Once all deliverables have been reviewed, the participants select an endorsement action for the review and the recorder records the effort metrics and summarizes the defects for review. The recorder then stores the document in the proper location. (see template instructions). |
|
Resolve Unit Test Code Review Defects |
The author updates affected deliverables and
provides answers to any outstanding questions.
|
|
Perform Unit Test Code Review Follow-Up |
The author contacts the recorder when changes have been completed on the deliverables with defects and to schedule a validation session. Once the correction of all defects have been verified, the recorder will enter the recording time, validation time and resolution time on the review form and calculate the total effort metric for the review. |
|
Update the Project Workbook |
The author places the session documentation
in the location outlined in he project’s configuration management plan.
|
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
The purpose of the Conduct Functional & User Acceptance Tests activity in the Develop & Test phase is to ensure that the application’s functional requirements have been met and that the application works end-to-end so that the product is ready for release testing.
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
Includes revision of Requirements Document (Acceptance Criteria and Accepted By) indicating requirement was met
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 Test Director for their project. TestDirector produces reports which can be used in test review and readiness review meetings.
Develop Product, Conduct Unit Test, Perform Code Reviews and Conduct Functional Test activities are iterative in nature and are repeated until successful functional test results are achieved. It is also important to note that projects using an iterative approach may perform these activities several times throughout the project life cycle as they work through each iteration.
All of the web pages used to implement order entry functions for direct sales are tested together. Each ordering function is followed from start to finish within the application.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
|
Objectives:
The purpose of the Conduct Performance Tests activity in the Develop & Test phase is to test the product in the environment so that any issues can be addressed prior to moving the product to the production environment to ensure the product meets the performance requirements.
This activity should be completed, when required, as early in the Develop & Test phase as possible because a negative outcome could mean redesigning the solution. It can be performed as soon as the product is stable enough to test and an environment is available. If issues are discovered, the project team may need to work with the architecture and infrastructure teams to determine a solution.
This activity includes defining the test needs, the test scenarios and requesting the test team perform the tests.
Performance test - Simulates realistic transaction volumes, based upon projected system usage and prior project experience
Stress test - Determine the maximum throughput of transactions and data
Desktop configuration test - Test new / changed client software on existing desktop configurations
Project manager fills out the Performance Test Request.
Submit to test team.
Test team will schedule meeting with the project manager to discuss details and options.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Revise Business Processes activity in the Develop & Test phase is to update the business processes impacted by the product so that business users will know how the product interacts with their processes.
This activity can begin as soon as the solution and design are complete. The project manager should coordinate this activity with the process owner. If the process owner determines that there is no change required to the process, the project manager must obtain a statement from the process owner (in writing or email) stating that no process change is required.
Copies of the current and new processes must be kept in the Develop & Test project folder. If there are no process changes required, file the current process and the process owner's statement that no process changes are required in this same location.
The tasks involved with this activity include:
Schedule a work session with the process owner and business users to identify the new or changed process activities
Facilitate the session
Document the new or changed process
Obtain the process owner’s approval
Hand off the new or changed process to the process owner
The process owner’s responsibilities include:
Identification of business users who need to assist in identification of the new or changed process activities
Provide clarification in areas of the process which may need clarification
Ensuring the process is communicated to the process users
Any training necessary for the new process
ISO document requirements ongoing (includes periodic reviews, updates, approvals, etc.)
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
Objectives:
The purpose of the Develop Training & User Documentation activity in the Develop & Test phase is to ensure that all the necessary training and reference materials are developed so that the product’s introduction into the business area is smooth.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Develop Maintenance & Support Turnover Documentation activity in the Develop & Test phase is to complete all tasks documented in the Maintenance & Support Turnover Plan so there is a smooth transition from the project team to the support team.
Per the Maintenance & Support Turnover plan, all necessary system and turnover documentation should be completed. This includes any required documentation specific for each support team, identified project documentation (e.g., configuration management, design documents, etc.), updating or creating the application disaster recovery report and updating or creating the WORP page.
The GIS PMP Checklist identifies project documentation that may be requested by the support teams.
Related Links:
Application Disaster Recovery Process
WORP Process
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Develop Business Rollout Plan activity in the Develop & Test phase is to ensure that all required business-related activities have been identified, assigned and scheduled so that there is a smooth integration of the product into each of the affected business areas and that the product aligns with business area standards and procedures.
Below is a list of tasks which may need to happen (this should not be considered a complete list but rather a place to start):
Training
Training logistics (travel, room setup, etc.)
Communication
Update processes, procedures, flow charts, SORCAs
Update roles and responsibilities
New equipment setup
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Develop Technical Implementation Plan activity in the Develop & Test phase is to ensure that all required activities have been identified, assigned and scheduled to move the product into the production environment so that defects and scheduling problems related to turnover are minimized/eliminated.
Below is a list of tasks which may need to happen (this should not be considered a complete list but rather a place to start):
Setup production environment
Accuracy and completeness signoff on required project documentation.
Production change control
Note: All changes to the production environment as a result of project work need to be submitted at least two weeks early to change control. It is highly encouraged to submit changes even earlier, to guarantee your slot, and/or have the flexibility to rearrange schedules if conflicts are detected. Changes will be reviewed by the change review board every other week. Project managers will also be required to attend the change review board to represent their project.
Data conversions
Setup of business users environment
User access
Deployment notification
Contingency plan
Move to production (who does what and when, dependencies or a specific order in which code/modules must be migrated, etc.)
Setup war room if applicable
Identify maintenance and support team members and how the product will be turned over to them
Identify and develop production validation tests
Setup training environment
Deploy Activities
Last Update: September ??, 2004 |
Deploy Phase: Conduct Release Test
|
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
|
Objectives:
The purpose of the Conduct Release Test activity in the Deploy phase is to ensure that a set of standard tests of end-to-end business processes produce the expected results with the new product being released so that when the product is migrated to the production environment it doesn’t break existing functionality.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Finalize Maintenance & Support Turnover Documentation activity in the Deploy phase is to review and update the system documentation created in the Develop & Test phase so that the maintenance & support team will have the information if and when it is needed. The Maintenance & Support Turnover plan should also be reviewed to verify that all turnover tasks have been completed.
This activity is the verification that all tasks identified in the Maintenance & Support Turnover Plan have been completed. This includes, but is not limited to updating or creation of the application disaster recovery report and updating or creation of the WORP page. The project team is responsible for completing these tasks with the assistance of maintenance & support and business continuity team members.
All project documentation must be made available to the production support team. Review the PMP Checklist to see the specific documentation that may be requested by the maintenance & support team.
Related Links:
Link to Application Disaster Recovery Process
Link to WORP Process
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Finalize & Execute the Business Rollout Plan activity in the Deploy phase is to finalize the Business Rollout Plan created in the Develop & Test phase and execute according to the plan so that there is a smooth integration of the product into each of the affected business areas and that it aligns with business area standards and procedures.
This activity includes all tasks which need to be completed for a successful product launch with the business users. This activity is coordinated by the project manager but must be directed by the business lead to ensure the business needs are addressed. It is important to note that there are times when multiple business rollout plans will be required, for example, when a product is being deployed to one region at a time.
Below is a list of tasks which may need to happen (this should not be considered a complete list but rather a place to start):
Training
Training logistics (travel, room setup, etc.)
Communication
Update processes, procedures, flow charts, SORCAs
Update roles and responsibilities
New equipment setup
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Finalize & Execute the Technical Implementation Plan activity in the Deploy phase is to finalize the Technical Implementation Plan created in the Develop & Test phase and then execute according to the plan so that the deployment goes smoothly.
This activity includes all tasks which need to be completed for a successful product launch in the technical environment. This activity is coordinated by the project manager but the project team must provide the detailed tasks, durations, dependencies and roles.
The project manager might choose to build a separate deployment schedule using MS Project to be used at this critical point during the project life cycle.
It is important to note that there may be times when multiple implementation plans are required, for example, when a product is being deployed to one region at a time.
Below is a list of tasks which may need to happen (this should not be considered a complete list but rather a place to start):
Setup production environment
Initial and date required project documentation entries in the PMP Checklist (highlighted in red). This is an audit requirement to confirm that the required project documentation has been created (or updated), is complete and accurate at project deployment.
Production change control (Tuesday prior to planned move to production)
Data conversions
Setup of business users environment
User access
Deployment notification
Contingency plan
Move to production (who does what and when, dependencies or a specific order in which code/modules must be migrated, etc.)
Setup war room if applicable
Identify maintenance and support team members and how the product will be turned over to them
Identify and develop production validation tests
Setup training environment
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Conduct Deploy Quality Audit in the Deploy 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 stored in the appropriate project sub-folders
The documents comply with GIS standards
The project manager has signed off on all required documents in the PMP Checklist.
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 the Conduct Readiness Review activity in the Deploy phase is to ensure that all key stakeholders understand the status of the project and product and based on that status, approve the product so that it can be moved to production.
Status should not be a surprise to the stakeholders at this point, but merely dotting the “i’s” and crossing the “t’s”. It is a final check that everything is ready and nothing has been overlooked. The project manager is responsible for coordinating the review and obtaining approval to move forward. This activity is a formal gate review which is performed in two steps – an internal review and an external review. It includes a review of open issues, open test items (reports from TestDirector), risks, and status of business rollout plan and technical implementation plan. Projects with any severity 1 or 2 issues from the customer's point of view can not deploy until those issues are resolved. The project team can decide to be MORE rigid on this rule but the project must meet this requirement.
Prior to the internal review, architects should review and verify the architectural implementation in a pre-production environment. See Green Team Process for more details.
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 open issues, open test items, risks, and status of business rollout plan and technical implementation plan.
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.
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 approval to move to production.
* 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
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
Objectives:
The purpose of the Move to Production activity in the Deploy phase is to move the product to production so that the intended users have access to the product.
The technical implementation plan is the key component to this activity. It will ensure that all tasks occur in the proper sequence and at the proper time.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Validate Production activity in the Deploy phase is to ensure that the new product is working in the production environment as expected so that users do not encounter technical issues.
A small group of business users or project team members run through the production validation tests to ensure everything is working properly. This production validation test should be more than just verification of file moves. It is also important to verify business functionality at this time before general availability is announced. If problems are encountered, the appropriate team members or other technical personnel need to be contacted to research and fix the issues. If problems are encountered, the testing and fixing will be an iterative process. Stakeholders should be notified of problems and kept apprised of the status until issues are resolved. If serious enough problems exist, it may be necessary to implement the project's contingency plan (a component of the Technical Implementation Plan).
Confirm migrations, conversions, and configuration changes were completed successfully
Test the migration of the system to production including proper installation and configuration, operational support procedures and processes, and ability of the system to meet defined service level agreements
Validation of business functionality of the system in production
Test access control for each user group
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
Objectives:
The purpose of the Handoff to Maintenance & Support Team activity in the Deploy phase is to pass the ongoing support of the product to the Maintenance & Support team so that if issues arise, they will be ready to assist users with issues.
Communication that the product has successfully been moved to production is the “trigger” for the Maintenance & Support Team to take over ongoing support of the product. The Maintenance & Support Turnover plan should contain all requirements for the final turnover.
NOTE: Sometimes the Maintenance & Support Team is the project team for a defined period of time.
Post-Deploy Activities
Last Update: September ??, 2004 |
Post-Deploy Phase: Conduct
Lessons Learned
|
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Conduct Lessons Learned activity in the Post-Deploy phase is to ensure improvement opportunities from the project experience are identified, documented and shared with other project managers so that the organization can use historical information to improve the GIS PMP process, improve future project performance and mitigate risks and issues on future projects.
Lessons learned is a facilitated session with project team members and customers to identify, analyze and document what worked well and not so well during the project. Participants recommend changes/actions determined from the session.
The project manager is responsible for coordinating and documenting the session as well as ensuring that action items are documented and tracked to closure.
Set up meeting to review the project. Invite project team members, sponsor, requestor and other stakeholders.
Lessons learned sessions can be held throughout the project life cycle as applicable. However, a lessons learned session is required by the GIS PMP in the post-deploy phase of a completed project or when a project is cancelled.
The template is required so that the PMO has a consistent format to gather and analyze data to focus process improvement activities and so that the lessons can be shared easily among project managers.
The participants must reach consensus on each score.
Follow detailed instructions located in the Lessons Learned template.
Lessons Learned are filed at: G:\BET\Projects\1- Lessons Learned.
Review test deliverables and submit any best practice candidate materials and process changes to the Testing SME function by placing them in the appropriate file location at G:\BET\Testing Repository\Best Practice Candidates.
NOTE: The statistics tab is used in the monthly project reviews.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
Objectives:
The purpose of the Obtain Project Acceptance Signoff activity in the Post-Deploy phase is to ensure that the sponsor, requestor and the project manager are in agreement concerning the accuracy of the project measurements so that the project can be officially closed.
This activity is the final signoff required on the project and indicates the official closure of the project.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Close Project activity in the Post-Deploy phase is to officially close the project so that all resources are officially released from the project.
This activity includes all tasks which need to be completed to close down the project. NOTE: Some of these tasks may occur earlier in the project, for example, if contractors are no longer needed, they should be released when their work is complete.
Below is a list of tasks which may need to happen (this should not be considered a complete list but rather a place to start):
Release contractors
Return temporary equipment used by the product team (PCs, telephones, etc.)
Update all project documents - some examples are:
Close out action items
Update schedule
Complete checklists where necessary
Archive project documents (see communication management)
Review testing deliverables and submit any best practice candidate materials and process changes to the Testing SME function by placing them in the appropriate file location at G:\BET\Testing Repository\Best Practice Candidates.
Archive project testing deliverables per the Test Repository Process:
Testing materials developed in the Mercury Test Director tool will remain in the tool
Testing materials developed and stored in the project folder will be archived with the rest of the project folder documentation
Submit final project status report reflecting the completed status and providing all completion information (actual deploy date, actual cost, implemented requirements, actual effort and number of defects identified during the Post-Deploy phase)
Update the resource capacity planning sheet
Distribute the Customer Satisfaction Survey to the project sponsor and requestor
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
Objectives:
The purpose of the Reward Team activity in the Post-Deploy phase is to reward and recognize the project team (and others who played a significant role) for their contributions.
Have fun.
Project Control Activities
Last Update: September ??, 2004 |
|
Project Control: Scope Management
The purpose of Scope Management is to ensure that the program includes all the work (and only the work) required so that the program's objectives are met. Description:This activity includes:
* These can be direct changes at the program level or changes to projects under the program.
Project Control: Schedule Management
The purpose of Schedule Management is to control changes to the program schedule
so that the impact of changes can be identified, mitigated where necessary
and communicated to stakeholders. Description: This activity includes:
Instructions:The program manager meets with the project managers on a regular basis (at least once each week) to:
Project Control: Cost Management
The purpose of Cost Management is to review program costs so that issues associated with costs (staffing, materials, etc.) are identified and addressed, minimizing impact to program costs, schedule, quality as well as the program's overall objectives (benefits). Description:Individual project cost plans (including both expense and capital costs) are used to track each project's actual spending on a monthly basis. These numbers are placed in Program Summary Report which calculates program totals. This is used to identify This activity includes:
Instructions:The program manager monitors the individual project status reports to:
Project Control: Quality Management
The purpose of Quality Management is to identify, track and measure the project objectives and performance, and to ensure that appropriate standards and processes are followed so that the program will meet stakeholder expectations. Description:Quality management covers the program, the program's projects and all the products produced by the program. This activity includes planning, measuring and auditing compliance of the program, projects and products to ISO 9001:2000, Sarbanes-Oxley, corporate policies and practices and GIS policies, processes and standards. If the program manger discovers that the project is off course on any of these, it is his/her responsibility to develop and implement corrective action plans.
Project Control:
Resource Management
The purpose of Resource Management is to identify, obtain and manage all project resources (all goods and services, including human resources) so that the appropriate resources are available when needed throughout the program life cycle. Description:This activity includes:
Instructions:The program manager meets with the project managers on a regular basis (at least once each week) to:
Project Control:
Communication Management
The purpose of Communication Management is to develop, manage and execute the program communication plan so that the right people receive the right information at the right time throughout the program life cycle. Description:This activity consists of developing the program communication plan, setup and maintenance of the program folder, issue escalation, providing status reports presenting at the monthly project reviews, conducting regular meetings with project managers and with the program steering committee. Part of the overall communication plan includes the Escalation Guidelines. This document provides some basic guidelines to be used in escalating issues or risks which are outside of the program team's sphere of influence. Setup and Maintain Folder Instructions:
Program Summary Report Instructions:Need to review the template and update instructions here: The purpose of the Status Report is to communicate project status to stakeholders, managers and other project teams. The master workbook remains in the root folder while a copy is filed in the appropriate week’s folder. They are due by 5:00 pm each Tuesday. This is a firm cut-off as the data will be uploaded to the database beginning first thing Wednesday mornings. It is mandatory that this template is used since it is used to update the GIS Project Scorecard and is the format used for monthly project reviews. For detailed instructions on the Status Report, view the Status Report User's Guide. Monthly Project Reviews:All active GIS programs/projects are reviewed on a monthly basis. Program managers use their program summary report to present the status of the program to the GIS management team, other program/project managers, and other key stakeholders. Lessons learned for completed programs are also presented at the monthly project reviews. Program managers use their completed lessons learned document for the presentation. NOTE: It is the program manager's responsibility to ensure that their report or lessons learned document are filed in the appropriate location by the documented deadlines in preparation for the monthly project reviews. If they miss those deadlines, it is their responsibility to bring three copies of their document to the review.
Project Control: Risk Management
The purpose of Risk Management in the Project Control phase is to identify, analyze and document the project risks so that plans can be made to minimize the impact that unfavorable events would have on the project objectives (schedule, budget, resources, deliverables and defects). Description:Risk is defined as “an uncertain event or condition that,
if it occurs, has a positive or a negative effect on a project objective”.
There are times when plans to mitigate risks are outside the sphere of the
project team's influence. See the Escalation Guidelines for assistance. Instructions:
NOTE: Through out the life cycle of the project, more risks may be identified. Those should be assessed as above, approved by the sponsor and requestor and incorporated into a new version of the document. Do not overwrite the baseline version or subsequent versions – there should be a version for each change after the initial baseline document.
Project Control: Integration Management
The purpose of Integration Management in the Project Control phase is to ensure that the various elements of the project are properly coordinated so that the product will meet stakeholder expectations. Description:Integration Management is the sum of all the project activities and documents. It ensures that all aspects of the project fit together without conflict. In the event of a “program”, it integrates the management areas of the sub-projects. This activity includes:
PMP Checklist Instructions:The PMP Checklist is a tracking tool used to indicate at a glance where a project is in the project life cycle. It is used:
As deliverables are developed the project manager indicates the date completed on the PMP Checklist. If an activity isn't required for a project the project manager puts N/A in the Date Completed column and records an explanation of why the activity is not required for the specific project. NOTE: If the item deemed as not necessary for a project requires an approval, the project manager must obtain approval/agreement from the sponsor and requestor that the activity isn't required.
|
