Project life cycle

Project Life Cycle
Project managers or the organization can divide projects into phases to provide better management control with appropriate links to the ongoing operations of the performing organization. Collectively, these phases are known as the project life cycle. Many organizations identify a specific set of life cycles for use on all of their projects. (PMBOK)
There is no single best way to define an ideal project life cycle. Some organizations have established policies that standardize all projects with a single life cycle, while others allow the project management team to choose the most appropriate life cycle for the team’s project. Further, industry common practices will often lead to the use of a preferred life cycle within that industry.

Project life cycles generally define:

What technical work to do in each phase (for example, in which phase should the architect’s work be performed?)

When the deliverables are to be generated in each phase and how each deliverable is reviewed, verified, and validated

Who is involved in each phase (for example, concurrent engineering requires that the implementers be involved with requirements and design)

How to control and approve each phase. Project life cycle descriptions can be very general or very detailed. Highly detailed descriptions of life cycles can include forms, charts, and checklists to provide structure and control.

Most project life cycles share a number of common characteristics:

Phases are generally sequential and are usually defined by some form of technical information transfer or technical component handoff.

Cost and staffing levels are low at the start, peak during the intermediate phases, and drop rapidly as the project draws to a conclusion.

The level of uncertainty is highest and, hence, risk of failing to achieve the objectives is greatest at the start of the project. The certainty of completion generally gets progressively better as the project continues.

The ability of the stakeholders to influence the final characteristics of the project’s product and the final cost of the project is highest at the start, and gets progressively lower as the project continues. A major contributor to this phenomenon is that the cost of changes and correcting errors generally increases as the project continues.

As a typical software project ,the life cycle of project will have generic five phases:

Phase I. Determine need and Feasibility
Phase II: Create Project Plan
Phase III: Create Specifications for Deliverables
Phase IV: Create Deliverables
Phase V: Test and Implement Deliverables

Different deliverables evolve in different ways, requiring different project phases. Stakeholders (Those who are effected By the project Activities) Review and approve deliverables at each phase before allowing the next phase to begin.

Let’s Briefly Examine each of these Phases:

Phase I: Determine Need and Feasibility

In this phase, the project manager and application specialist attempt to confirm that there is a need for the project deliverables. In addition, they try to decide whether the project is “Doable”—That is, whether it is possible to plan and execute a project to create these deliverables. This phase culminates in a formal approval of the project concept or a “Go/No Go” decision.


Activities in this Phase:
Activities that should be undertaken during this phase include, but are not limited to, the following:

Goal Definition

Concept Definition

Needs Analysis

Market Analysis

Strategy definition

Preliminary benefit/cost analysis

Phase II: Create Project Plan
Since projects are of finite duration and sometimes use unique work processes, the planning of a project is particularly important. In this phase, the project manager and/or application specialists create a formal document to guide the project team as they execute the project.

Activities in this Phase:
Creating a formal planning document that may be used to:

Link Project activities to expressed needs and feasibility studies at phase I

• Provide a written record of assumptions regarding deliverables, work processes,resources required, and so forth
  
• Help Communicate clearly with Stakeholders

• Provide a written record of agreed-upon scope, cost, and schedule
  

• Facilitate a critique of project assumptions help by stakeholders

Getting the project plan approved by sponsors and other stakeholders before project work begins

Phase III: Create Specifications for Deliverables

In this phase, application specialists create a formal document that describes in substantial detail the deliverables that are to be created like software design documents,Use Cases, Flowchart ,UML diagram and so on.

It is important to distinguish the extensive Phase III deliverables specifications from the preliminary specifications created as part of the Phase II Planning Process. In the Phase II Planning process, the project team describes the deliverables in just enough detail to create a project Plan. Once the Plan is approved, the project team can begin spending resources (including time and money.) on the project.

It makes good business sense to wait until phase III to extend the preliminary Specifications. At this time, they should be “Fleshed out” substantially so that project stakeholders can evaluate them at length.
In this way, the project team can make written modifications instead of reworking the deliverables.

Activities in this Phase:

Create one or more documents describing the specifications of all deliverables in substantial detail

Obtaining approval of the specifications from sponsors (usually customer)and other stakeholders

Note:
These detailed specifications sometimes identify unanticipated deliverables.
Therefore, this phase often includes description of ways in which schedules or budgets need to be refined, as well as new project assumptions.


Phase IV: Create Deliverables

The most time-consuming and resource-intensive phase of the project is usually this phase in which the project deliverables are created according to the approved deliverable specifications. The software coding and development is being done in this phase. The specific activities involved in this phase differ dramatically from one industry or application to another.

Activities in this Phase:

Creating prototype of deliverables

Creating portions or pieces of deliverables

Providing services as promised in the project plan

Completing fully integrated deliverables

Obtaining sponsor and other stakeholder approval for each deliverable or service, as appropriate

Phase V: Test and Implement Deliverables
In this phase, the project deliverables are shown to work as planned and are turned over to the sponsor or customer for use.

Activities in this Phase:

Testing of deliverables ,together or in part

Refinement of deliverables based on test results

Implementation of deliverables on a limited basis such as field trial

Further refinement of deliverables based on preliminary implementation

Full production of final deliverables

Customer/sponsor or other stakeholder approval of test results, resulting plans for modification of deliverables, and final deliverables



Key stakeholders on every project include:

Project manager. The person responsible for managing the project.

Customer/user. The person or organization that will use the project’ product. There may be multiple layers of customers. For example, the customers for a new pharmaceutical product can include the doctors who prescribe it, the patients who take it and the insurers who pay for it. In some application areas, customer and user are synonymous, while in others, customer refers to the entity acquiring the project’s product and users are those who will directly utilize the project’s product.
Performing organization. The enterprise whose employees are most directly involved in doing the work of the project. Project team members. The group that is performing the work of the project. Project management team. The members of the project team who are directly involved in project management activities.

Sponsor. The person or group that provides the financial resources, in cash or in kind, for the project.
Influencers. People or groups that are not directly related to the acquisition or use of the project’s product, but due to an individual’s position in the customer organization or performing organization, can influence, positively or negatively, the course of the project.
PMO. If it exists in the performing organization, the PMO can be a stakeholder if it has direct or indirect responsibility for the outcome of the project.

In addition to these key stakeholders, there are many different names and categories of project stakeholders, including internal and external, owners and investors, sellers and contractors, team members and their families, government agencies and media outlets, individual citizens, temporary or permanent lobbying organizations, and society-at-large. The naming or grouping of stakeholders is primarily an aid to identifying which individuals and organizations view themselves as stakeholders.


Next topic Project management process