Characteristics of a Project Phase
The completion and approval of one or more deliverables characterizes a project phase. A deliverable is a measurable, verifiable work product such as a specification, feasibility study report, detailed design document, or working Proto-type. Proto-types are an excellent way to demonstrate the technology to stakeholders and to prove certain methods without the expenditure of a full project. Some deliverables can correspond to the project management process, whereas others are the end products or components of the end products for which the project was conceived. The deliverables, and hence the phases, are part of a generally sequential process designed to ensure proper control of the project and to attain the desired product or service, which is the objective of the project.
In any specific project, for reasons of size, complexity, level of risk, and cash flow constraints, phases can be further subdivided into sub-phases. Each sub-phase is aligned with one or more specific deliverables for monitoring and control. The majority of these sub-phase deliverables are related to the primary phase deliverable, and the phases typically take their names from these phase deliverables: requirements, design, build, test, startup, turnover, and others, as appropriate. Each one of these major phases should have a formal sign-off with the stakeholders. Any change made to the scope of the project later on means that you need to re-open the previous phases to examine what changes occur to the schedule, resources, risks etc. because of the scope change.
A project phase is generally concluded with a review of the work accomplished and the deliverables to determine acceptance, whether extra work is still required, or whether the phase should be considered closed. A management review is often held to reach a decision to start the activities of the next phase without closing the current phase, for example, when the project manager chooses fast tracking as the course of action. Another example is when an information technology company chooses an iterative life cycle where more than one phase of the project might progress simultaneously. Requirements for a module can be gathered and analyzed before the module is designed and constructed. While analysis of a module is being done, the requirements gathering for another module could also start in parallel.
Similarly, a phase can be closed without the decision to initiate any other phases. For example, the project is completed or the risk is deemed too great for the project to be allowed to continue.
Formal phase completion does not include authorizing the subsequent phase.
For effective control, each phase is formally initiated to produce a phase-dependent output of the Initiating Process Group, specifying what is allowed and expected for that phase. A phase-end review can be held with the explicit goals of obtaining authorization to close the current phase and to initiate the subsequent one. Sometimes both authorizations can be gained at one review. Phase-end reviews are also called phase exits, phase gates, or kill points. Kill points are when the stakeholders decide that the project is not worth completing in its current state. It may be restarted with different criteria.
Project Life Cycle Relationships
Many projects are linked to the ongoing work of the performing organization.
Some organizations formally approve projects only after completion of a feasibility study, a preliminary plan, or some other equivalent form of analysis; in these cases, the preliminary planning or analysis takes the form of a separate project. For example, additional phases could come from developing and testing a prototype prior to initiating the project for the development of the final product. Some types of projects, especially internal service or new product development projects can be initiated informally for a limited amount of time to secure formal approval for additional phases or activities.
The driving forces that create the stimuli for a project are typically referred to as problems, opportunities, or business requirements. The effect of these pressures is that management generally must prioritize this request with respect to the needs and resource demands of other potential projects.
The project life cycle definition will also identify which transitional actions at the end of the project are included or not included, in order to link the project to the ongoing operations of the performing organization. Examples would be when a new product is released to manufacturing, or a new software program is turned over to marketing. Care should be taken to distinguish the project life cycle from the product life cycle. For example, a project undertaken to bring a new desktop computer to market is only one aspect of the product life cycle. Additional projects can include a performance upgrade to the product. In some application areas, such as new product development or software development, organizations consider the project life cycle as part of the product life cycle.
 ©2005 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 5
4 Comments »
- Business Analyst
- Communications Management
- earned value
- knowledge areas
- Living Your Best Life
- Performance Management
- Phase Review Process
- Project Initiation
- Project Management
- Project Phases
- quality management
- Risk Management
- Schedule Management
- Scope Management
- Writing and Documentaiton
- Young Life