2.9.9

617 views
511 views

Published on

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
617
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
24
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

2.9.9

  1. 1. THE ‘A’ TEAM A PROJECT SOLUTIONS Project Life Cycle Version 3.0 Date of Issue: May 10,2003 Prepared by: The A Team, Project Solutions Contributions from: Aisheng Feng Cynthia Perez Julie Tartaglia Karen Kishi Nader Riahi Ron Clifford Confidential document
  2. 2. Project Life Cycle Table of Contents 1 Overview.............................................................................................................................4 1.1 Project Life Cycle.............................................................................................................................4 1.2 Project Concept...............................................................................................................................4 1.3 Project Size Determination..................................................................................................................4 1.4 Project Definitions............................................................................................................................5 1.5 Control Strategies.............................................................................................................................6 1.5.1 Guiding Principles and Team Communication Strategies.........................................................................6 1.5.2 Project Quality Strategies.............................................................................................................6 1.6 Project Roles...................................................................................................................................7 2 Initiation Phase.....................................................................................................................8 2.1 Initiation Checklist............................................................................................................................8 2.2 Initiation Process Diagram...................................................................................................................9 2.3 Needs Analysis.................................................................................................................................9 2.4 Project Start-up Administrative Requirements..........................................................................................9 2.5 Communication Planning and Information Distribution...............................................................................10 2.6 Quality Management Planning.............................................................................................................10 2.7 Feasibility Study.............................................................................................................................10 2.8 Statement of Work for Discovery.........................................................................................................10 2.9 Discovery .....................................................................................................................................10 2.9.1 Gather Requirements.................................................................................................................11 2.9.2 Identify Risks...........................................................................................................................11 2.9.3 Time & Cost Estimates................................................................................................................11 2.9.4 Project Schedule......................................................................................................................11 2.9.5 Identify Constraints/Assumptions...................................................................................................11 2.9.6 Identify In Scope & Out of Scope...................................................................................................12 2.9.7 Scope Change Management Considerations.......................................................................................12 2.9.8 Impact Change Management Considerations......................................................................................12 2.9.9 GAPS document........................................................................................................................12 2.9.10 Human Resources, Roles and Responsibilities...................................................................................12 2.9.11 Cost Management Considerations.................................................................................................12 2.9.12 Procurement and Vendor Management Considerations........................................................................12 2.9.13 Return On Investment...............................................................................................................13 2.9.14 Project Plan (for Internal projects)...............................................................................................13 2.9.15 Statement of Work for a Project or Design (for External projects)..........................................................13 2.10 Deliverables from the Initiation Phase ................................................................................................13 3 Planning Phase - Design ........................................................................................................14 3.1 Design Checklist..............................................................................................................................14 3.2 Design Process Diagram.....................................................................................................................14 3.3 Detail Design Session ......................................................................................................................15 3.3.1 Planning Considerations..............................................................................................................15 3.3.2 Detail Design of Gathered Requirements..........................................................................................15 3.3.3 Design Sessions and Outputs.........................................................................................................15 3.3.4 Identify Risks based on Detail Design..............................................................................................16 3.3.5 Development Planning................................................................................................................16 3.3.6 Task Scheduling and Resource Allocation.........................................................................................16 3.3.7 Review of Existing Planning Documents...........................................................................................16 3.4 Project Strategy Planning .................................................................................................................17 3.4.1 Testing Plan............................................................................................................................17 3.4.2 Migration Plan..........................................................................................................................17 3.4.3 Implementation Plan..................................................................................................................17 Date of Issue: May 10, 2003 -2- Printed: 2010/06/03
  3. 3. Project Life Cycle 3.5 Statement of Work for Project ...........................................................................................................17 3.6 Deliverables from Planning Phase - Design..............................................................................................17 4 Execution Phase - Development...............................................................................................19 4.1 Development Checklist.....................................................................................................................19 4.2 Development Process Diagram.............................................................................................................19 4.3 Development ...............................................................................................................................20 4.4 Development Testing........................................................................................................................20 4.4.1 Write Test Cases.......................................................................................................................20 4.4.2 Unit Testing............................................................................................................................20 4.4.3 Integration Testing....................................................................................................................20 4.4.4 Acceptance Testing...................................................................................................................20 4.4.5 Summary Report of Testing Results ................................................................................................21 4.5 Deliverables from the Execution Phase - Development...............................................................................21 5 Execution Phase – User Acceptance ..........................................................................................22 5.1 User Acceptance Checklist.................................................................................................................22 5.2 User Acceptance Process Diagram.........................................................................................................22 5.3 UAT Support Plan............................................................................................................................23 5.4 Write UAT Test Cases ......................................................................................................................23 5.5 Conduct User Acceptance Testing.........................................................................................................23 5.6 Testing Results Review .....................................................................................................................24 5.7 Deliverables ..................................................................................................................................24 6 Execution Phase - Implementation ...........................................................................................25 6.1 Implementation Checklist .................................................................................................................25 6.2 Implementation Process Diagram.........................................................................................................25 6.3 Implementation Plan........................................................................................................................26 6.4 Promotion and Production Acceptance Testing.........................................................................................26 6.5 Rollout.........................................................................................................................................26 6.6 Deliverables for Implementation Phase..................................................................................................26 7 Closeout Phase....................................................................................................................27 7.1 Closeout Checklist...........................................................................................................................27 7.2 Closeout Process Diagram..................................................................................................................27 7.3 Post Implementation Review ..............................................................................................................28 7.3.1 Administrative and Contract Closure...............................................................................................28 7.3.2 Review..................................................................................................................................28 7.4 Dissemination and Archiving ..............................................................................................................28 7.5 Deliverables for Closeout Phase...........................................................................................................28 8 Glossary ............................................................................................................................29 8.1 Common Acronyms..........................................................................................................................29 8.2 Template File Extension Glossary.........................................................................................................29 Date of Issue: May 10, 2003 -3- Printed: 2010/06/03
  4. 4. Project Life Cycle 1 Overview This document provides an in depth framework of the Project Life Cycle, for all types of projects requiring fundamental Project Management. 1.1 Project Life Cycle The Project Life Cycle could be concise or elaborate, yet use of a framework is important to maintain synergy between projects and a uniformed approach. A typical project life cycle is divided into the following phases: 1. Initiation Phase 2. Planning Phase - Design 3. Execution Phase - Development 4. Execution Phase - Testing 5. Execution Phase - Implementation 6. Closeout Phase 1.2 Project Concept The Customer or originator of the “Idea” usually completes this process. There are many reasons to consider starting a project: 1. Problem Resolution 2. To Enhance Your Competitive Advantage 3. Evolutionary Improvement 4. A system, organizational or process change that hasn’t been made before 5. Developing a new product or service Taking the time to think about time and costs at this stage may or may not be an exercise in frustration. A cursory understanding of time and cost estimates is useful in helping to determine if the project would be beneficial or not. 1.3 Project Size Determination Projects can be broken down into the following: Size Amount Team Duration Large $ 600,000  $ ?? More than 10 More than 1 year Medium $ 200,000  $ 599,999 10 or less 1 year or less Small $ 40,000  $ 199,999 5 or less 6 months or less Enhancement (not a project) Under $ 40,000 2 or less 2 month or less • Projects can be internal to an organization or for an external customer. • All external projects must produce a statement of work contract. • Projects that are medium to large must go through a bid review process with senior management after the project plan or statement of work has been completed. Date of Issue: May 10, 2003 -4- Printed: 2010/06/03
  5. 5. Project Life Cycle 1.4 Project Definitions Item Definition Internal Project Internal to the organization. Can be for the same or different departments. Use the Project Plan template to outline the project objective, scope, schedule, etc. External Project A project for an external customer. Requires that the Statement of Work contract template be completed that clearly defines the project objective, scope, schedule, cost, terms of payment, etc. Project Plan or Project Typically written for projects that are internal to an organization. Details the objectives, Charter scope, timeline and deliverables for a project. Statement of Work A contract detailing a specific scope of work with definitive deliverables for an external customer. Typically includes a schedule outlining when work begins and is estimated to end based on the agreed upon scope, scope change process, cost and payment schedule. UAT User Acceptance Test. Once a ‘product’ has been completed and tested by the building team, the group who requested the product be built has an opportunity to test the product for deficiencies and to ensure the product meets all requirement and design specifications. WBS Work Breakdown Structure. Can refer to either a high level WBS or a detailed WBS. The A Team has two templates depicting each type of WBS. The detailed WBS includes hours and cost for each task in the WBS. Date of Issue: May 10, 2003 -5- Printed: 2010/06/03
  6. 6. Project Life Cycle 1.5 Control Strategies Protocol, procedures and tools for the communication and distribution of information between all stakeholders must be established at the start of the project and the level of detail will depend on the size of the project. Following are some guidelines. Be aware of your 1.5.1 Guiding Principles and Team Communication Strategies organizations terms of engagement. 1. All projects must have a project plan. 2. A reasonable number of meetings must be held with the project team to review task progress, share knowledge, identify schedule or specific issues and plan for upcoming tasks and milestones. The occurrence of these meetings can be determined based on the size of the project, the amount of work required and the duration of time allocated for the work. 3. Provide regular updates to all stakeholders. 4. Meeting agendas (sent prior to the meeting being held) are required and meeting minutes must be taken along with identified action items and distributed to the appropriate team members and stakeholders. 5. Review monthly with project resources, noting such things as vacations, sickness and staff attrition and evaluate the impact on the project tasks, schedule and costs. 6. The project schedule should be reviewed against the baseline and updated regularly with status completion and additional identified tasks. 7. Ensure during every phase of the project that cost, plans, risks, etc, are reviewed. If adjustments are necessary, the project manager needs to obtain authorization from appropriate stakeholders. . This evaluation process increases the project manager’s degree of confidence in the remainder of the estimate. 8. It is expected that duration and cost of projects will vary significantly between various engagements; therefore templates should be used where possible to provide guidance only. Templates are complemented by personal knowledge and experience, however some organizations do have required templates. 9. Each project resource should log his or her time monthly against each assigned task of the project as well as for each meeting or workshop that is attended. This information is used for task completion review and future comparison. 10. The project budget and expenses to date should be reviewed and updated regularly. 1.5.2 Project Quality Strategies Following is a list of strategies that help improve the quality of the product being produced during various stages of the project life cycle. 1. Identify all skills and roles that are needed to provide input and ensure all key people are involved during requirements gathering and detail design. 2. Commit to well-defined requirements, detailed scope, well-understood deliverables and having them signed off before detail design begins. 3. Identified and agreed upon success metrics should also be gathered during requirements gathering. 4. Agreed upon scope change process for changes or additions to existing requirements. 5. Manage customer expectations when changes are proposed and have an agreed upon approval mechanism. 6. Conduct feasibility studies, proof of concept or usability studies when necessary. 7. Break project into logical and manageable work units. 8. If testing will be necessary, begin planning test strategies during detail design. 9. Identify risks through risk brainstorming sessions that should be conducted at various stages throughout the project. 10. Sign off of detail design by all stakeholders. 11. If a unique endeavour, use prototyping if possible. 12. Confirm comprehensive and approved test cases to verify design. Date of Issue: May 10, 2003 -6- Printed: 2010/06/03
  7. 7. Project Life Cycle 13. Allow enough time to complete tasks and test properly. 14. Project milestones should be identified and progress is tracked and reviewed. 15. Investigate and use best practise standards applicable within your industry wherever possible. 1.6 Project Roles Following is a listing of some basic roles that may or may not be needed during the life of most projects that help ensure expertise is available and decision makers are identified. In some projects, specific people my take on multiple roles. Role Responsibilities Project Sponsor The Customer, or a senior manager designated to support the success of the project by providing liaison with the Client or Customer and providing policy direction to the Project Manager. Steering Committee or Provides approval to proceed Advisory Board and direction but does not authorize or take decisions . May provide user specific input to project design. Senior Management A person with the authority and/or responsibility to initiate work. The Initiator is responsible for defining and justifying the project and for securing the financial approvals. Project Stakeholders All affected or affecting parties partial to the outcome of the project. Subject Matter Experts (SME) Users or selected representatives with related knowledge or experience. Project Manager The individual responsible for managing the project. Directs and co-ordinates human and material resources through the life of a project using modern management techniques. Achieves a pre-determined scope, schedule, cost, and quality to customer satisfaction. Task Manager The person nominated by the Project Manager to be responsible for completing a defined scope of work (work package) to an agreed schedule and cost. Risk Manager The person nominated by the Project Manager to be responsible for completing and controlling the risk plan Scope Change Manager The person nominated by the Project Manager to be responsible for controlling changes to the original scope of the project. Impact Change Manager The person nominated by the Project Manager to be responsible for the planning and organizational changes impacted by the implementation of the project. Business Analyst Applies Business/Process needs to the Technical Specifications ‘Resource’ Managers Other managers of needed resources. Engineer Provides technical solution for operational requirements. Finance Supports or leads budgetary planning, controlling and close out Legal Provides expertise in related area regarding the legal technicalities, obligations and rights. Date of Issue: May 10, 2003 -7- Printed: 2010/06/03
  8. 8. Project Life Cycle 2 Initiation Phase 2.1 Initiation Checklist Checklist Customer Who PM Consults Suggested Template(s) Small Medium Large Type Needs Analysis I, E Sales or PM Case for Action.doc    Business Analyst Schedule.mpp (discovery tasks) Project Start-up Administrative I, E Finance Time Tracking.xls    Requirements Expense Tracking.xls Communication Management I, E All Stakeholders Communication Plan.doc    Statement of Work for Discovery External Project Sponsor SOW mini.doc    Discovery: I, E Project Team Requirements.doc    • Face to face sessions Impact Change GAPS.doc Manager • Internal Analysis • Reviews for clarification Risk Planning Session I, E Project Team Risk Assessment Checklist.doc    • Workshop Risk Management Plan.doc • Complete Checklist • Prepare Risk Plan Task Scheduling and Resource I, E ‘Resource’ Managers HR Management Plan.doc    Planning Time Management Plan.doc • Budget Estimate Cost Management Plan.doc • Cost Control Plan Procurement Management Plan.doc • Procurement Plan WBS.xls Schedule.mpp (design or project tasks) Identify Roles and Responsibilities I, E Project Team    Scope Change Management Planning I, E Project Team Scope Change Request.doc    Change Management Template.doc Impact Change Management Planning I, E Project Team Change Management Plan.doc Project Plan Internal All Stakeholders Project Plan.doc    Statement of Work for Design External All Stakeholders SOW.doc   Statement of Work for Project External All Stakeholders SOW.doc  Internal Team Review I, E Project Team  Client Approval Review I, E Senior Management (SOW) Approvers page    Project Sponsor Project Stakeholders Project Kick-off I, E Project Team    Date of Issue: May 10, 2003 -8- Printed: 2010/06/03
  9. 9. Project Life Cycle 2.2 Initiation Process Diagram It is implicitly agreed that the customer has the option of not moving forward at any juncture. No Discovery - Gather Requirements - Identify Risks Project Accounting Codes, - Estimate Time and Cost Project Concept Needs Analysis File Storage structure, Issue Yes - Constraints & Assumptions and Client with Communication Planning, Discovery Statement of Work - In Scope & Out of Scope Rules of Approval Client Review Quality Management Planning, with Client Review - Scope Change Management Engagement Feasibility Study - Impact Change Management - GAPS - HR Roles & Responsibilities - Return On Investment No Ensure Understanding Client/Internal Yes Issue Yes Client Go-No-Go Decision & Review & Project Statement of Work - Face to Face meetings Approval Stakeholder Sign-off Approvals with Client review - Client Reviews No Project Go to Design Review and update Kick-off information 2.3 Needs Analysis This type of analysis reviews the ‘idea’ and determines if there is a true need. This can be a function of sales or the intended project team. They would discuss with the customer and come up with very rough information to gain an understanding and commitment to go forward. Discuss the rules of engagement. For example the process that will be used to complete the deliverables, contracts and expectations for approvals and resources need to be discussed. 2.4 Project Start-up Administrative Requirements For project control purposes, capturing historical project information, cost tracking and budgeting analysis the following financial planning needs to be considered or established: 1. Create a new project code in accounting for charging time to. 2. Define the project tracking codes. For example you may want to track the following for an IT project: a. Project Management b. Planning c. Discovery d. Design e. Development f. Testing g. Implementation 3. Establish the time capture and expense reporting methodologies for all project participants. Date of Issue: May 10, 2003 -9- Printed: 2010/06/03
  10. 10. Project Life Cycle 2.5 Communication Planning and Information Distribution Establish procedures for documentation, transfer and sharing of knowledge, workflow and communication. Select the tools and medium most suitable for this project. Prepare a matrix for who communicates to whom and for what purpose. Part of this matrix is very important for knowing who to escalate issues to if the need arises. 2.6 Quality Management Planning Use the existing quality processes and procedures as a starting point and add in other checkpoints and approaches that may be pertinent to the current project. The plan should include all phases of the project and address such issues as scope change management, performance measuring and quality assurance for deliverables. As one of the internal quality checkpoints, project proposals will proceed through an internal review and approval process, prior to delivery to the customer. This step ensures quality of the solution and engages support from all affected functional groups. 2.7 Feasibility Study All large (and most medium) size projects will include a Feasibility Study after gathering the requirements for any new areas that need to have the design or technology proven. Sometimes referred to as a Proof of Concept or Usability Study, a Feasibility Study could be a separate project depending on the size of the study that is required. 2.8 Statement of Work for Discovery Compile a Statement of Work for Discovery that clearly states the order of magnitude cost and time required to complete the discovery process. A review of the Statement of Work for Discovery will have to be scheduled with the project sponsors and stakeholders. Need Signoff! 2.9 Discovery The project managers must clearly state the expectations for the Discovery Session prior to the session. The purpose of these sessions is to confirm the understanding of the initial project scope, identify deliverables and success metrics and determine the high level cost and schedule for the design and subsequent phases. These sessions are the project foundation (charter) and provide an opportunity for the project team members to get a sense of the big picture. All discovery sessions should be conducted face to face with both internal and/or external customers. It is important to identify and ensure that the right groups are represented and that the appropriate people (eg. SME’s, system users, business and technical experts) attend the discovery sessions. This will provide immediate feedback and interaction between the customers and the representatives of the project team to clarify issues and compile as much pertinent information as possible. A GAPS document (see section 2.9.9 GAPS document) will also be created, clearly stating any gaps that are identified during requirements gathering. The project managers must clearly state the expectations for the Discovery Session prior to the session. Date of Issue: May 10, 2003 - 10 - Printed: 2010/06/03
  11. 11. Project Life Cycle 2.9.1 Gather Requirements There are many aspects to project requirements, ranging from product related to the business environment and long- term support. In general the following areas may be considered while gathering requirements, but not limited to: a. Business needs b. End User c. Application Engage ALL d. Reporting the right people e. System and/or infrastructure f. Security g. Success Metrics h. Support i. Etc.. Requirements gathering for medium and large projects should be done during face-to-face session(s). Expertise from the business, users and management must be represented at these top-level meetings. Project teams may analyse the requirements after each session and formulate a set of questions to clarify their understanding. These questions will be reviewed during the next face-to-face top-level meeting. If a Feasibly Study or Proof of Concept is required then specific requirements around the study need to be identified and approved. This could be broken into a smaller separate project if warranted. 2.9.2 Identify Risks Using the Risk Assessment Plan, identify the project risks and note the mitigation strategy for each risk. For medium and large projects it may be worthwhile to hold a risk workshop involving various departments and customers that play a role in the project. After quantifying the identified risks you may include contingency. In some cases this is determined as a percentage of the total project cost. For example if your risk assessment works out to be 7% and your project is estimated at $100,000, include an additional $7,000 to your project estimate. Templates are no substitute for expertise 2.9.3 Time & Cost Estimates Using the Work Breakdown Structure (WBS) template, identify the high level tasks, people required and the estimated hours needed to complete each task. Keep in mind that this is a high level estimate (order of magnitude) and is used to assess the feasibility of the project. Identify team members who will be working full time on the project and subject matter experts from other areas that need to be drawn in at specific times. You will need to check for “experts” availability and how it may affect the project duration. For example, not taking this into consideration and generally allocating all of the resources at a 100% will jeopardize your goals of Time, Cost and Quality. 2.9.4 Project Schedule From your completed detailed WBS prepare a project schedule using MS Project or other scheduling tool. If known include specific resources to help provide a clear timeline. Your predicted schedule is dependent on resource availability. Moreover, getting or not getting specific resources contributes directly to the overall project cost and timeline. 2.9.5 Identify Constraints/Assumptions Think of everything possible and confirm understanding between all stakeholders. Date of Issue: May 10, 2003 - 11 - Printed: 2010/06/03
  12. 12. Project Life Cycle 2.9.6 Identify In Scope & Out of Scope It is as important to identify what is out of scope as well as what is in scope to ensure the project expectations are met by all. For example, you may be writing a new software application and the customer may have an expectation that training is included but if it’s not it should be explicitly stated that training is out of scope. 2.9.7 Scope Change Management Considerations Project Manager should re-iterate current Scope Change Management policies. Any changes to the policy will need to be reflected in the SOW and the template if appropriate. 2.9.8 Impact Change Management Considerations Determine the targets of potential impact of change to maximize the acceptance. This may the responsibility of the customer should the changes be primarily within their organization. Planning for this should be identified during requirement gathering. 2.9.9 GAPS document The purpose of this document is to identify any technical and business GAPS between the requirements and the proposed solution. The project managers should plan to update the GAPS document for every phase of the project. The GAPS document will be used to determine whether the Design phase has been completed. If there are sufficient GAPS to indicate that this phase cannot be completed, the GAPS will have to be reviewed and updated. 2.9.10 Human Resources, Roles and Responsibilities Identify who is required at each phase of the project to approve decisions, bring business knowledge, provide expertise and ensure timely completion of tasks. This is the initial stage of human resource management. At this point a plan must be put forward to explain the approach towards staff acquisition and team building. Procurement may also be considered here so far as approach is considered. Detail plan for both HR and Procurement will be developed during the next phase of the project. 2.9.11 Cost Management Considerations Cost management encompasses the managing of all costs associated to a project. This starts with the “Initiation Phase” and carries through to the “Close Out” phase. The following points are the areas to consider for managing project costs: 1. Project Budget 2. External Costs 3. Tracking Costs throughout the project (Budget vs Actual) 4. Project Performance Measurements 5. Cash Flow 2.9.12 Procurement and Vendor Management Considerations Procurement of vendor services creates a legal relationship in which the scope of work to be performed is defined in a written contract. Subcontracted project tasks must be well defined and managed with great care, or disputes may arise which can be costly to resolve, may impact the project schedule or may even bring the project to a crashing halt. Following are the main areas to consider during the procurement of vendor services: 1. Legal relationships created by contracting 2. The solicitation process 3. The importance of adequately defining the procured work 4. Procurement planning and scheduling 5. Contract types, administration and closeout 6. Vendor management Date of Issue: May 10, 2003 - 12 - Printed: 2010/06/03
  13. 13. Project Life Cycle 7. Monitor either cost or fixed-price contracts 2.9.13 Return On Investment The information necessary to calculate the return on investment should be obtained during the fact gathering sessions. Companies may use different data for different markets and projects. The templates must facilitate the flexibility to deal with these circumstances. Using the ROI worksheet template, during discussions gather the information needed to calculate the expected return on investment. For example, ROI relates to how much cash a new system is expected to generate versus how much it costs to implement and operate during its estimated life. 2.9.14 Project Plan (for Internal projects) A Project Plan or Project Charter should be generated based on the requirements and should include the Business, Application, System and Support requirements, a budgetary cost and timeline estimate, documented known risks and mitigations, constraints and assumptions, in scope and out of scope, etc. A walkthrough of the Project Plan or Project Charter must be scheduled between all the key stakeholders. The objectives of the walkthrough are to develop a common understanding of the topics covered within the Project Plan and obtain approval and/or sign off to proceed with the next phases of the project. 2.9.15 Statement of Work for a Project or Design (for External projects) A Statement of Work for a Project should be generated based on the requirements. This SOW includes the Business, Application, System and Support requirements, a budgetary cost and timeline estimate, documented known risks and mitigations, constraints and assumptions, in scope and out of scope, etc. A walkthrough of the Statement of Work for Project must be scheduled between all the key stakeholders of the project. The objectives of the walkthrough are to develop a common understanding of the topics covered within the SOW, and obtain a sign off to proceed with the next phases of the project. Although an order of magnitude estimate is requested at this time, a schedule or price may not be possible without delving into further research. The exceptions should be negotiated on a per project basis. For LARGE and medium projects there will be a third SOW produced after the Design Phase with definitive costs and final delivery schedule. 2.10 Deliverables from the Initiation Phase 1. Statement of Work for Discovery 2. Schedule for Discovery Tasks 3. Requirements document 4. GAPS document 5. Communication Plan document 6. Project Plan (for Internal projects, all sizes) 7. Statement of Work for Design (for external projects, medium and large) 8. Statement of Work for Project (for external projects, small) 9. Schedule for Design or Project Tasks Date of Issue: May 10, 2003 - 13 - Printed: 2010/06/03
  14. 14. Project Life Cycle 3 Planning Phase - Design 3.1 Design Checklist Checklist Customer Who PM Consults Suggested Template(s) Small Medium Large Type Risk review I, E Project Team    GAPS review I, E Project Team    Detail Design Session: I, E Project Team (Industry Specific)    • Interface Design • Feasibility Study • Functional Design • Technical Design Development Planning I, E SME    Risk Planning Session I, E Project Team Risk Management Plan.doc    Roles and Responsibilities I, E Project Team    Impact Change Management Review I, E Project Team    Scope Change Management Review I, E Project Team    Project Strategy Planning: I, E Project Team Project Strategy Plan.doc    • Test Plan • Migration Plan • Implementation Plan Task Scheduling and Resource I, E Resource Managers Schedule.mpp (project tasks)    Assignment Project Plan Internal All Stakeholders Project Plan.doc    Statement of Work for Project External All Stakeholders SOW.doc   Internal Team Review(s) I, E Project Team  Senior Mgmt Approval Review I, E Senior Management Signoff.doc   Project Team Client Approval Review I, E Senior Management (SOW) Approvers page    Project Sponsor Project Stakeholders 3.2 Design Process Diagram Detailed Design Session Review Statement Of Work - Requirement Analysis - Development Planning Strategy Planning - Scope - WBS Yes - Cost Estimate Client/Internal - Task scheduling - Testing Plan - Schedule Approvals - Resource Allocation - Migration Plan - Risks & Constraints - GAPS - Implementation Plan - Assumptions - Identify Risks - Roles & Responsibilities Issue Project - Review Existing planning No Statement of Work Documents with Definitive cost and schedule Review and update information Go-No-Go Decision & Go to Development Stakeholder Sign-off Date of Issue: May 10, 2003 - 14 - Printed: 2010/06/03
  15. 15. Project Life Cycle 3.3 Detail Design Session Design is an interactive process between appropriately identified project team members. Design sessions should always be conducted face-to-face. The Customer must be actively engaged in the design process especially where their architecture and interfaces are affected, and linked to the master design solution. The project team should develop a comfortable degree of confidence and understanding of the overall solution before the design is documented and presented to the Customer for review and comments. This should be done through a series of scheduled internal design verification reviews to ensure that the design outputs meet the specified customer requirements. Seek to The goal of design is to provide the “detail” solutions for the requirements that were gathered during clarify the discovery. This is typically an iterative process. Multiple sessions should be expected while detail common is sought, clarified and adopted. 3.3.1 Planning Considerations Some planning processes to consider: 1. Human Resources Consideration: a. Identify the existing critical paths and perform a preliminary analysis of the impact on the project due to resource allocation conflicts. b. Be aware of the resource requirements for all other projects while developing the project schedule and costing. It may be a lot more difficult to resolve conflicts after the project plan is completed. 2. Procurement: a. Compile a list of preferred supplier of parts, services or manufactures, hire consultants, etc. b. The customer should also be consulted with regards to their preference of suppliers, services, etc. c. Specific source will have to be made in co-operation with purchasing department (if applicable) and finance so that all administrative details could be sorted out 3.3.2 Detail Design of Gathered Requirements The following requirements where gathered during discovery. Conduct multiple design sessions to flesh out all of the detail for, but not limited to the following: 1. Business needs 2. End User Engage ALL 3. Application the right 4. Reporting people 5. System and/or infrastructure 6. Security 7. Success Metrics 8. Support Schedule multiple, 9. Etc.. iterative review 3.3.3 Design Sessions and Outputs Design may include some of the following considerations to ensure consistency and quality: 1. Preliminary design or usability design should be completed face to face with the customer. Prototyping during this aspect of design provides clarity, can enhance mutual understanding and provides an atmosphere of collaboration toward a single goal. This could include designing for a software application, business process change, moving a group of people to a new location, etc. 2. Functional and/or technical design compliments preliminary design by providing further specific details required to ‘make’ the product or identify ‘unseen’ aspects of a business process change. Date of Issue: May 10, 2003 - 15 - Printed: 2010/06/03
  16. 16. Project Life Cycle 3. Infrastructure design describes all ‘physical’ details, for example, new or upgrading software or operating systems may require purchasing new servers, new or upgraded telephony or network needs, additional office equipment, etc. In most cases these are diagrams depicting locations, space and equipment. 3.3.4 Identify Risks based on Detail Design Beginning from the Risk Assessment Plan used during discovery, further identify the project risks and note the mitigation strategy for each risk. For medium and large projects it may be worthwhile to hold a risk workshop involving various departments and customers that play a role in the project. A full disclosure of any known risks must be documented and mitigation actions should be identified to avoid any misunderstanding and future frustrations. Risk items should be communicated to all parties concerned as the issues arise, rather than at the end of the design phase. 3.3.5 Development Planning Development planning should involve at least one representative from each group that has any development activities attributed to them. All Customer, Vendor or other tasks should be included in the master project schedule maintained by the project manager in order to note dependencies that may affect the schedule. Development plan should also include procurement management plan, evaluation criteria and solicitation proposal. The development plan should primarily concentrate on how to assess work results and when to feed information into the performance reporting process. Development planning would deal with questions regarding: 1. How to identify development tasks and finding and allocating resources? 2. How often are progress reports needed from each functional group? 3. When to have review meetings and who should attend? 4. How to collect, compile and distribute information about divergence from the project schedule? 5. How to deal with divergence and when/how to generate a change request to scope and/or project schedule? 6. What to do about unforeseen problems? This is mostly concerned with items that arise unexpectedly and not accounted for during the design phase. 7. How to deal with issues and how often should we reconsider risk? 8. How to deal with corrective actions and when to update the project schedule? An internal walkthrough should be planned and conducted, to obtain an understanding of the schedule and assess any impact of any other simultaneous projects that may be in progress for all active project members. 3.3.6 Task Scheduling and Resource Allocation For medium to large size projects you will have completed your original SOW based on a high-level order of magnitude pricing. Having identified the design ‘details’ you now need to produce the final SOW for the project with definitive time and cost estimates. Using the WBS created for the Design estimate, further identify the project tasks, people required and the estimated hours needed to complete each task. Identify team members who will be working full time on the project and subject matter experts from other areas that need to be drawn in at specific times. You will need to check for “experts” availability and how it may affect the project duration. For example, not taking this into consideration and generally allocating all of the resources at a 100% will jeopardize your goals of Time, Cost and Quality. 3.3.7 Review of Existing Planning Documents Prior to signing off on the design documents the following should be reviewed for any changes and to evaluate the health of the project: 1. Communication Plan 2. Scope Change Management Date of Issue: May 10, 2003 - 16 - Printed: 2010/06/03
  17. 17. Project Life Cycle 3. Roles and Responsibilities 4. GAPS a. A review of the GAPS document must be done at this time to ensure all gaps which were identified during requirements gathering have been either accepted (which means a change request has been initiated), declined or left for future consideration. Strategy planning can uncover missing or inadequately 3.4 Project Strategy Planning defined requirements or 3.4.1 Testing Plan Depending on the type of project, implementation environment and the final product, there may be several aspects to testing. These would include such items as functionality, efficiency, performance, repeatability, and usability and integration. A Test Strategy Plan must be created for every project and certain aspects should be developed in collaboration with the customer. This plan should include the overall testing strategy, schedule and resource requirements. The constraints, assumptions and risks should be explicitly identified and the contingency and mitigation action associated to those risks should be clearly documented. 3.4.2 Migration Plan If this is an evolutionary improvement then understanding how the ‘enhanced’ application, process, infrastructure or other items will be migrated within the existing environment or areas, requires planning to ensure that any common component redesign, design constraints or additional requirements are identified. The project team should plan for this and assign some budget and appropriate resources for the task. 3.4.3 Implementation Plan Identify any infrastructure changes that will be required and/or the different groups that will be needed to participate during implementation. Develop a preliminary plan for how implementation will be achieved. You may also want to consider support strategies at this stage for projects with impact on the organization. It may identify a need to further break up your project into more discrete phases for ease of implementation. 3.5 Statement of Work for Project The original SOW for Design would remain relatively the same. Some additional details from the design can be included as well as updates to the following: 1. Revised Scope 2. Revised Cost Estimate 3. Revised Schedule 4. Revised Risks and Constraints 5. Revised Assumptions 6. Revised Roles and Responsibilities All designs and solutions require the Project Team’s approval. This is to be obtained through formal walkthrough and sign off for the Detail Design and the Project SOW. 3.6 Deliverables from Planning Phase - Design 1. Detailed Design 2. Project Strategy Plan Date of Issue: May 10, 2003 - 17 - Printed: 2010/06/03
  18. 18. Project Life Cycle 3. Statement of Work for Project Date of Issue: May 10, 2003 - 18 - Printed: 2010/06/03
  19. 19. Project Life Cycle 4 Execution Phase - Development 4.1 Development Checklist Checklist Customer Who PM Consults Suggested Template(s) Small Medium Large Type Risk review I, E Project Team    GAPS review I, E Project Team    Development and Unit Testing I, E Development Team    Test Case Development I, E Business Analyst (Industry Specific)    Development Team Lead Scope Change Management Review I, E    Integration Testing I, E Development Team Issues Log.doc    Lead Acceptance Testing I, E Business Analyst Issues Log.doc    Internal Approval Review I, E    Testing Results Review I, E    Project Team 4.2 Development Process Diagram Development Testing Control Execution - Test Cases Walkthrough - Monitor Progress Internal Yes - Unit Testing Summary of test - Monitor Schedule Review & - Integration Testing results & obtain - Manage Change Approval? - Acceptance testing Customer approval - Generate Status - Track Issues Reports - Summary Reports No - Make Modifications To Meet Requirements No Design - Fix minor problems Go to User Acceptance Change - Exercise Change Management - Generate GAPS Yes Go To Planning Phase - Design Date of Issue: May 10, 2003 - 19 - Printed: 2010/06/03
  20. 20. Project Life Cycle 4.3 Development Activities with mutual dependencies identified during the planning process, must be coordinated to ensure that the agreed upon deliverables are resourced and executed on schedule to avoid any overall schedule slippage. The project managers from each group should ensure that all internal standards are adhered to and best practises are used. Unit testing will be conducted to ensure that all components meet the requirements as outlined in the Detail Design document. The primary function of the project manager during the development phase is to control the execution of tasks in the project schedule. Considerations during the development stage: 1. All team members/leaders should regularly inform the project manager about the progress made on the execution of tasks, as described by the overall project schedule. 2. In case of problems, the project manager needs to co-ordinate any actions that may need to be taken to bring the project back on track or report necessary adjustments to the schedule in case of resource conflicts and/or technical problems. 3. Any change in the project plan will need to go through change management process and approved by the appropriate stakeholders. 4. Project manager needs to carryout procurement contract administration to ensure sellers performance meets the contractual requirements. 5. The project manager is also required to submit progress reports and project status on regular basis to all stakeholders. The period between each report depends on the size, complexity and degree of uncertainty (risk level) within the project. 6. Unit tests will have to be executed according to schedule. The results and implication of failure on the project schedule needs to be assessed and acted on appropriately. 7. Project manager should do an overall assessment of the project status for each scheduled milestone. No more fluff and planning stuff 4.4 Development Testing 4.4.1 Write Test Cases All high level test case requirements are outlined in the project strategies document. Details of the test plan or approach towards gathering test results may be fine-tuned when writing the test cases. The output from these tests is a verification document that describes the input, procedure and the results of the test. 4.4.2 Unit Testing The main purpose of unit test activities is to ensure functional correctness of smaller components of the product. 4.4.3 Integration Testing Integration testing verifies that the smaller product components function together as expected based on the detail design. Policy, process or procedure may be tested in a limited or controlled live environment often referred to as a pilot. 4.4.4 Acceptance Testing Using detailed test cases, each product function needs to be validated from a “users” point of view, to ensure all business rules (if applicable) are being observed and processed correctly. All aspects of the product must be evaluated, for example, support or help mechanisms, user experience and ease of use, reporting or follow-up procedures, etc. Date of Issue: May 10, 2003 - 20 - Printed: 2010/06/03
  21. 21. Project Life Cycle Further, we need to verify that the product adheres to the detail design and that all requirements have been met according to the original requirement specifications as well as any additional changes during the course of design and development. The acceptance testing is one of the last chances to evaluate and correct for inconsistencies between the overall product requirements and deliverables. The project manager may use this test as quality assurance before presenting the product to the customer. A good result from the internal acceptance test brings up the level of confidence in successful completion of the project. 4.4.5 Summary Report of Testing Results A report noting “in summary” the issues that were found during the Acceptance Testing should be prepared and discussed with the customer. Identify possible gaps, scope or design change requirements. A review and signoff of the GAPS document must be completed at this time to ensure all GAPS, which were identified during the gathering of client requirements, have been addressed. 4.5 Deliverables from the Execution Phase - Development 1. Summary Report of Testing Results 2. Completed “Product” ready for User Acceptance Date of Issue: May 10, 2003 - 21 - Printed: 2010/06/03
  22. 22. Project Life Cycle 5 Execution Phase – User Acceptance 5.1 User Acceptance Checklist Checklist Customer Who PM Consults Suggested Template(s) Small Medium Large Type UAT Support Plan I, E Client Business Analyst    Client Project Manager Technical Analyst Operations Write UAT Test Cases I, E Client Business Analyst (Industry Specific)    Conduct UAT I, E Client Business Analyst Issues Log.doc    Testing Results Review I, E Client Project Manager    • GAPS Review Business Analyst Client Business Analyst Client Approval Review I, E UAT Acceptance Sign-off.doc    5.2 User Acceptance Process Diagram UAT Support Plan User Acceptance Testing Client Yes Walkthrough test - Facilitate Resources - Write UAT Test Case Review and results & obtain - Match Tests With Requirements - Conduct UAT Approval Customer approval - Create Issue Log - Track Issues No - Make Modifications To Meet Requirements Go-No-Go Decision & No Stakeholder Sign-off Design - Fix minor problems Change - Exercise Change Management - Generate GAPS Go to Implementation Yes Go To Design Phase Date of Issue: May 10, 2003 - 22 - Printed: 2010/06/03
  23. 23. Project Life Cycle 5.3 UAT Support Plan 1. The project manager needs to facilitate and arrange for all identified resources (tools as well as human) to be available for the duration of the test. 2. Provision and availability of project team is purely for the purpose of support as the customers normally carry out the test themselves. 3. Although the customer creates the test cases, they will still need to be shared with the project manager to ensure they correspond with the requirements. 4. All customer issues found during testing must be captured in an issues log. 5. The project manager should follow-up on the issue log with a plan of action to resolve each issue. The plan of action will have to be authorized by all stakeholders if it results in a change in scope, schedule or cost of the project. Success criteria should have well defined metrics and measurable acceptance range. Subjective criteria must be avoided at all cost. Criteria such a “reasonably easy to use” or “perform much faster than” is nothing short of recipe for failure. If it cannot be quantified, it might as well be removed from the acceptance list. 5.4 Write UAT Test Cases All high level test case requirements are outlined in the project strategies document. Details of the test plan or approach towards gathering test results may be fine-tuned when writing the test cases. The output from these tests is a verification document that describes the input, procedure and the results of the test. UAT test cases are usually written by the customer. 5.5 Conduct User Acceptance Testing Using detailed test cases, product functionality needs to be validated from a “users” point of view, to ensure all business rules (if applicable) are being observed and processed correctly. The following points are related in general to UAT testing which the customer usually completes: 1. All product related development must have stopped prior to this test and the associated documents released to documentation control. 2. Testing may be iterative in nature to correct for errors and deficiencies. 3. A checklist is the best way of confirming compliance during the test. There should be a one to one correspondence between each item on the list and the product requirement. 4. An issue log should be generated for every item that is deemed non-compliant on the checklist. 5. Verify that the product adheres to the detail design and that all requirements have been met according to the original requirement specifications as well as any additional changes during the course of design and development. Date of Issue: May 10, 2003 - 23 - Printed: 2010/06/03
  24. 24. Project Life Cycle 5.6 Testing Results Review It is necessary that a review of the GAP document be carried out during UAT. This will ensure that the items listed in the GAP have indeed been resolved during the development. The project manager must also ensure that unresolved items have been accepted by the user as being unnecessary within the scope of this project. This is normally done during the design or development phase and confirmed during the UAT. It is necessary for the project manager to schedule and conduct UAT result walkthrough, in collaboration with the Customer and obtain a sign off before proceeding with the next phase. This is considered as one of the critical exit points of the project. A walkthrough of the test results must be planned and conducted to go over the UAT results and obtain a sign off. 5.7 Deliverables 1. UAT Support Plan 2. UAT Acceptance sign off Date of Issue: May 10, 2003 - 24 - Printed: 2010/06/03
  25. 25. Project Life Cycle 6 Execution Phase - Implementation 6.1 Implementation Checklist Checklist Customer Who PM Consults Suggested Template(s) Small Medium Large Type Implementation Plan I, E Client Project Manager    Business Analyst Client Business Analyst Promotion and PAT I, E Client Business Analyst    Client Project Manager Client Approval Review I, E Project Stakeholders PAT Acceptance Sign-off.doc    Conduct ROLLOUT I, E Client Business Analyst Issues Log.doc    6.2 Implementation Process Diagram Implementation Plan Yes Promotion Yes Go-No-Go Decision & - Implementation Activities Client Client and Stakeholder Sign-off - Support Requirements approval ? approval ? Production Acceptance Testing - Risk Assessment - Back out Procedures Rollout No No - Make Changes To The Plan No - Make Modifications To Meet Requirements Design - Exercise Change Management - Exercise Change Management Go to Closeout Change - Generate GAPS - Generate GAPS Yes Go To Design Phase Date of Issue: May 10, 2003 - 25 - Printed: 2010/06/03
  26. 26. Project Life Cycle 6.3 Implementation Plan The project manager will need to work in collaboration with the customer to determine the details of the plan. This plan should identify the detailed implementation activities, support requirements, risk and potential back out procedures. The project manager needs to assign appropriate development team to be available during implementation to log and resolve all unforeseen problems. This log needs to be included in the project file as historical data. A walkthrough of the plan must be scheduled and conducted with all appropriate parties to go over the Implementation Plan and obtain a sign off. 6.4 Promotion and Production Acceptance Testing This is the activity of changing from one environment to another or adopting a new process. It may be necessary to conduct a Production Acceptance Test (PAT) to ensure the new product works in the new environment or the new process is acceptable with the expected users. A walkthrough of the test results must be planned and conducted to go over the PAT results and obtain implementation sign off. Need Signoff to 6.5 Rollout complete After signoff of PAT The project team will execute the necessary activities in the plan to complete rollout. Rollout includes the final steps involving for “turning on an application” or “starting mass production” of a product or “signalling a new process is in active use”. Generally a support plan or service warranty agreement is applicable over an agreed upon timeframe. 6.6 Deliverables for Implementation Phase 1. Implementation sign off Date of Issue: May 10, 2003 - 26 - Printed: 2010/06/03
  27. 27. Project Life Cycle 7 Closeout Phase 7.1 Closeout Checklist Checklist Customer Who PM Consults Suggested Template(s) Small Medium Large Type Post Implementation Review I, E Project Manager PIR.doc    Business Analyst Client Business Analyst Dissemination and Archiving I, E Project Manager    Final Acceptance Review I, E Project Manager Final Acceptance Sign-off.doc    Client Business Analyst Client Stakeholders 7.2 Closeout Process Diagram Yes Dissemination Post Implementation Client Project closeout and Review approval ? (Celebration) Archiving Closeout Meeting & Stakeholder Sign-off No Date of Issue: May 10, 2003 - 27 - Printed: 2010/06/03
  28. 28. Project Life Cycle 7.3 Post Implementation Review 7.3.1 Administrative and Contract Closure 1. Document all project results to formalise acceptance by the sponsor or customer. 2. Collect project records and ensure that they reflect final specifications. 3. Provide formal written notice that the procurement contract has been completed. 7.3.2 Review A formal post implementation review (PIR) should be planned and conducted at the end of every project. This is a collaborative effort between the project manager, the customer and the project team. A document should be created for PIR. The PIR plan may include lessons learned and recommendations for improvements for some of the following areas: 1. Scope Management 2. Schedule Management 3. Cost Management 4. Quality Management 5. Human Resources Management 6. Communication Management 7. Risk Management 8. Procurement Management 9. Project Plan 10. Overall project effectiveness 7.4 Dissemination and Archiving The project manager should plan as to how he/she will disseminate the project information and archive them for future reference. 7.5 Deliverables for Closeout Phase 11. PIR sign off 12. Project sign off 13. CELEBRATION Date of Issue: May 10, 2003 - 28 - Printed: 2010/06/03

×