2.9.9

THE THE ‘‘AA’’ TEAM TEAMP R O J E C T S O L U T I O N S

Project Life Cycle

Version 3.0

Date of Issue: May 10,2003

Prepared by: The A Team, Project Solutions

Contributions from: Aisheng FengCynthia PerezJulie Tartaglia

Karen KishiNader RiahiRon Clifford

Confidential document

Project Life Cycle

Table of Contents

1 Overview......................................................................................................................................... 4

1.1 Project Life Cycle...........................................................................................................................................41.2 Project Concept.............................................................................................................................................41.3 Project Size Determination............................................................................................................................41.4 Project Definitions..........................................................................................................................................51.5 Control Strategies..........................................................................................................................................6

1.5.1 Guiding Principles and Team Communication Strategies....................................................................61.5.2 Project Quality Strategies....................................................................................................................6

1.6 Project Roles..................................................................................................................................................7

2 Initiation Phase........................................................................................................8

2.1 Initiation Checklist.........................................................................................................................................82.2 Initiation Process Diagram.............................................................................................................................92.3 Needs Analysis...............................................................................................................................................92.4 Project Start-up Administrative Requirements..............................................................................................92.5 Communication Planning and Information Distribution...............................................................................102.6 Quality Management Planning.....................................................................................................................102.7 Feasibility Study..........................................................................................................................................102.8 Statement of Work for Discovery.................................................................................................................102.9 Discovery.....................................................................................................................................................10

2.9.1 Gather Requirements........................................................................................................................112.9.2 Identify Risks.....................................................................................................................................112.9.3 Time & Cost Estimates......................................................................................................................112.9.4 Project Schedule...............................................................................................................................112.9.5 Identify Constraints/Assumptions......................................................................................................112.9.6 Identify In Scope & Out of Scope.......................................................................................................122.9.7 Scope Change Management Considerations.....................................................................................122.9.8 Impact Change Management Considerations....................................................................................122.9.9 GAPS document................................................................................................................................122.9.10 Human Resources, Roles and Responsibilities..................................................................................122.9.11 Cost Management Considerations.....................................................................................................122.9.12 Procurement and Vendor Management Considerations....................................................................122.9.13 Return On Investment.......................................................................................................................132.9.14 Project Plan (for Internal projects).....................................................................................................132.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..........................................................................................................................................143.2 Design Process Diagram..............................................................................................................................143.3 Detail Design Session..................................................................................................................................15

3.3.1 Planning Considerations....................................................................................................................153.3.2 Detail Design of Gathered Requirements..........................................................................................153.3.3 Design Sessions and Outputs............................................................................................................153.3.4 Identify Risks based on Detail Design...............................................................................................163.3.5 Development Planning......................................................................................................................163.3.6 Task Scheduling and Resource Allocation.........................................................................................163.3.7 Review of Existing Planning Documents...........................................................................................16

3.4 Project Strategy Planning............................................................................................................................173.4.1 Testing Plan.......................................................................................................................................173.4.2 Migration Plan...................................................................................................................................173.4.3 Implementation Plan.........................................................................................................................17

Date of Issue: May 10, 2003 - 2 - Printed: 2023/04/08

Project Life Cycle

3.5 Statement of Work for Project.....................................................................................................................173.6 Deliverables from Planning Phase - Design.................................................................................................17

4 Execution Phase - Development...............................................................................18

4.1 Development Checklist................................................................................................................................184.2 Development Process Diagram....................................................................................................................184.3 Development...............................................................................................................................................194.4 Development Testing...................................................................................................................................19

4.4.1 Write Test Cases...............................................................................................................................194.4.2 Unit Testing.......................................................................................................................................194.4.3 Integration Testing............................................................................................................................194.4.4 Acceptance Testing...........................................................................................................................194.4.5 Summary Report of Testing Results..................................................................................................20

4.5 Deliverables from the Execution Phase - Development...............................................................................20

5 Execution Phase – User Acceptance.........................................................................21

5.1 User Acceptance Checklist..........................................................................................................................215.2 User Acceptance Process Diagram..............................................................................................................215.3 UAT Support Plan.........................................................................................................................................225.4 Write UAT Test Cases..................................................................................................................................225.5 Conduct User Acceptance Testing...............................................................................................................225.6 Testing Results Review................................................................................................................................235.7 Deliverables.................................................................................................................................................23

6 Execution Phase - Implementation...........................................................................24

6.1 Implementation Checklist............................................................................................................................246.2 Implementation Process Diagram................................................................................................................246.3 Implementation Plan....................................................................................................................................256.4 Promotion and Production Acceptance Testing...........................................................................................256.5 Rollout.........................................................................................................................................................256.6 Deliverables for Implementation Phase.......................................................................................................25

7 Closeout Phase.......................................................................................................26

7.1 Closeout Checklist.......................................................................................................................................267.2 Closeout Process Diagram...........................................................................................................................267.3 Post Implementation Review.......................................................................................................................27

7.3.1 Administrative and Contract Closure................................................................................................277.3.2 Review...............................................................................................................................................27

7.4 Dissemination and Archiving.......................................................................................................................277.5 Deliverables for Closeout Phase..................................................................................................................27

8 Glossary.................................................................................................................28

8.1 Common Acronyms.....................................................................................................................................288.2 Template File Extension Glossary................................................................................................................28


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 CycleThe 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 ConceptThe 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 DeterminationProjects 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.


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 Charter

Typically written for projects that are internal to an organization. Details the objectives, 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.


Be aware of your organizations

terms of engagement.

Project Life Cycle

1.5 Control StrategiesProtocol, 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.

1.5.1 Guiding Principles and Team Communication Strategies

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.


Project Life Cycle

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.

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 RolesFollowing 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 Advisory Board

Provides approval to proceed

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.


Project Life Cycle


Project Life Cycle

2 Initiation Phase

2.1 Initiation Checklist

Checklist CustomerType

Who PM Consults Suggested Template(s) Small Medium Large

Needs Analysis I, E Sales or PM

Business Analyst

Case for Action.doc

Schedule.mpp (discovery tasks)

Project Start-up Administrative Requirements

I, E Finance Time Tracking.xls

Expense Tracking.xls

Communication Management I, E All Stakeholders Communication Plan.doc

Statement of Work for Discovery External Project Sponsor SOW mini.doc

Discovery:

Face to face sessions

Internal Analysis

Reviews for clarification

I, E Project Team

Impact Change Manager

Requirements.doc

GAPS.doc

Risk Planning Session

Workshop

Complete Checklist

Prepare Risk Plan

I, E Project Team Risk Assessment Checklist.doc

Risk Management Plan.doc

Task Scheduling and Resource Planning

Budget Estimate

Cost Control Plan

Procurement Plan

I, E ‘Resource’ Managers HR Management Plan.doc

Time Management Plan.doc

Cost Management Plan.doc

Procurement Management Plan.doc

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

Project Sponsor

Project Stakeholders

(SOW) Approvers page

Project Kick-off I, E Project Team


Project Life Cycle

2.2 Initiation Process DiagramIt is implicitly agreed that the customer has the option of not moving forward at any juncture.

2.3 Needs AnalysisThis 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 RequirementsFor 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.


Need Signoff!

Project Life Cycle

2.5 Communication Planning and Information DistributionEstablish 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 PlanningUse 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 StudyAll 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 DiscoveryCompile 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.

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.


Engage ALL the

right people

Templates are no substitute for expertise

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

d. Reporting

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.

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.


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.10Human 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.11Cost 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.12Procurement 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


Project Life Cycle

4. Procurement planning and scheduling

5. Contract types, administration and closeout

6. Vendor management

7. Monitor either cost or fixed-price contracts

2.9.13Return 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.14Project 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.15Statement 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


Project Life Cycle


Project Life Cycle

3 Planning Phase - Design

3.1 Design Checklist



Risk review I, E Project Team

GAPS review I, E Project Team

Detail Design Session:

Interface Design

Feasibility Study

Functional Design

Technical Design

I, E Project Team (Industry Specific)

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:

Test Plan

Migration Plan

Implementation Plan

I, E Project Team Project Strategy Plan.doc

Task Scheduling and Resource Assignment

I, E Resource Managers Schedule.mpp (project tasks)

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

Project Team

Signoff.doc

Client Approval Review I, E Senior Management

Project Sponsor

Project Stakeholders

(SOW) Approvers page

3.2 Design Process Diagram


Seek to clarify the common

goal

Engage ALL the

right people

Schedule multiple,

iterative review sessions!

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.

The goal of design is to provide the “detail” solutions for the requirements that were gathered during discovery. This is typically an iterative process. Multiple sessions should be expected while detail 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

3. Application

4. Reporting

5. System and/or infrastructure

6. Security

7. Success Metrics

8. Support

9. Etc..

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.


Project Life Cycle

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.

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.


Strategy planning can uncover missing or

inadequately defined

requirements or design details!

Project Life Cycle

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

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.

3.4 Project Strategy Planning

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


Project Life Cycle

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

3. Statement of Work for Project


Project Life Cycle

4 Execution Phase - Development

4.1 Development Checklist

Checklist Customer 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

Development Team Lead

(Industry Specific)

Scope Change Management Review I, E

Integration Testing I, E Development Team Lead

Issues Log.doc

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


No more fluff and planning

stuff

GET to WORK!

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.

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.


Project Life Cycle

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.

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


Project Life Cycle

5 Execution Phase – User Acceptance

5.1 User Acceptance Checklist



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

GAPS Review

I, E Client Project Manager

Business Analyst

Client Business Analyst

Client Approval Review I, E UAT Acceptance Sign-off.doc

5.2 User Acceptance Process Diagram


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 TestingUsing 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.


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


Project Life Cycle

6 Execution Phase - Implementation

6.1 Implementation Checklist



Implementation Plan I, E Client Project Manager

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


Need Signoff to complete Rollout!

Project Life Cycle

6.3 Implementation PlanThe 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 TestingThis 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.

6.5 RolloutAfter 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


Project Life Cycle

7 Closeout Phase

7.1 Closeout Checklist



Post Implementation Review I, E Project Manager

Business Analyst


PIR.doc

Dissemination and Archiving I, E Project Manager

Final Acceptance Review I, E Project Manager


Client Stakeholders

Final Acceptance Sign-off.doc

7.2 Closeout Process Diagram


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


Project Life Cycle

8 Glossary

8.1 Common Acronyms

Acronym Description

UAT User Acceptance Test

PAT Production Acceptance Test

WBS Work breakdown structure

PIR Post Implementation Review

SME Subject Matter Expert

SOW Statement of Work

PLC Project Life Cycle

PMO Project Management Office

PM Project Manager

ROI Return on Investment

8.2 Template File Extension Glossary

Acronym Description

XLS Microsoft Excel Spreadsheet document

DOC Microsoft Word document

PPT Microsoft PowerPoint presentation document

MPP Microsoft Project Schedule document


2.9.9

Business

subject matter

pm consultssuggested

project life

project life

project life

project life

exercise change

production