What is the Project Life Cycle and How to Use It Better?

The project life cycle describes the stages a project goes through as it progresses from start to finish. A well-defined life cycle brings order and structure to the project. This article will demystify the project management life cycle and help you run better projects.

Few things in project management are more hotly debated than this:

The project life cycle.

Pop into any PM forum and you’ll see a ton of questions about it. Does it have four stages or five? Are the stages merely functional? Or do they demand different approaches as well?

That projects should be broken down into separate stages is accepted wisdom.

How this breakdown should take place, and what should be done in each stage is still up for questioning.

I’ll help demystify the project management life cycle in this post. I’ll review what PMI says, the latest literature, and cover tips, tactics, and strategies from practicing PMs to make some sense of the PM cycle.

A Brief Overview of the Project Life Cycle

Before we dig deeper, let’s quickly review the project life cycle.

As I noted in an earlier guide on project management, the entire PM process can be broken down into five distinct stages.

These are:

• Initiation: The first stage where you figure out the 'why' of the project's existence. You map out the project's objective, pick a manager, and clarify your approach. The key deliverable of this stage is the project charter.
• Planning: This is where you use your PM knowledge to develop a detailed plan for the project's execution. You'll define the project's scope, create a WBS, and map out a schedule. All the heavy lifting - communication plans, risk management plans, etc. - is done in this stage. Some of the key deliverables are the WBS, Gantt chart, and project plan.
• Execution: This is the "do" phase of the project where you actively track assigned tasks and ensure that the project stays on course. You'll hold meetings, send out status reports, and ensure that the project runs smoothly.
• Control: The 'control' phase runs alongside the Execution phase and is focused on monitoring the project's progress. You'll monitor milestones, goals, and activities to keep the project on track.
• Closure: In this fifth and final stage, you'll hand over all deliverables to stakeholders and formally close the project. You'll also review the project for lapses, insights, and positives. The key deliverable in this stage is the project report.

Some PMs remove the ‘Control’ stage and fold it within the ‘Execution’ stage. The PMBOK itself a distinct Control stage which interacts with Planning, though you are free to include it within Execution to simplify matters.

This division into five stages is easy enough to understand. But there are a lot of nuances that can complicate matters.

I’ll look at these issues in detail below.

Project Life Cycle Stages Often Share Activities

Going by the above definition, you might think that each stage is a distinct, compartmentalized entity. That once a stage gets over, the next one starts with no interaction with the earlier stage.

That’s not true of course. Project stages don’t exist in isolation. In actual projects, there is no hard line dividing stages. Activities, resources, and even objectives often bleed over from stage to stage.

For instance, the ‘Control’ phase is concurrent with the ‘Execution’ phase. Some activities from the ‘Initiation’ phase - such as defining the scope - fold well into the ‘Execution’ phase. And things that happen during execution alter the original plans.

The five distinct stages look a lot more like this in practice:

So what’s the real-world impact of project stages interacting with one another?

Let’s look at a few answers:

• Changing project scope: Although you define the scope in the Initiation stage, new developments, learnings and change requests through Planning and Execution can change the scope drastically. Thus, you’ll have to manage scope definitions throughout the project life cycle.
• Resource availability impacts planning: The availability of resources impacts the project’s scope and plan. If a project requires unique but limited resources, you’ll have to modify the scope definition to align with the resource’s availability.
• Subprojects: Large projects are often divided into smaller subprojects with closely linked initiation and closing. For example, a website project might be divided into two “design” and “development” subprojects. The closure of the design subproject might coincide with the initiation of the development phase.
• Planning-execution interaction: Changes in the execution stage affect your original plans, and vice-versa. For example, you might be forced to switch to a third-party contractor due to a resource falling sick. This contractor assumes all risk associated with the deliverable. You’ll now have to change your risk management plan to accommodate this change.

It’s important to think of these stages as dynamic categories. What happens in one stage impacts the other.

We make Workamajig, the all-in-one project management suite built for creative teams

• Everything in one place
• Project Management
• Resourcing & Scheduling
• Task Management & Time Tracking 
• Custom Dashboards
• Business Insights

Use Different Management Approaches in Different Project Stages

As you would know, activity and resource requirements aren’t really uniform across the five stages of the project life cycle.

Typically, there is little activity at the start of the project. It peaks as you move from initiation to execution before winding down at project closure.

The length of each stage isn’t uniform either. Initiation might take a few days, planning a few weeks, and execution several months.

If the requirements of each stage keep changing, shouldn’t your management approach change with the stage as well?

The basis of this argument is that different factors contribute to the success of each stage. You need clarity of vision in the planning phase, but the ability to marshal resources and keep the team motivated becomes a priority during execution.

In one survey, project managers ranked the success factors in each stage as follows:

This gives you an idea of what to prioritize in each stage.

Thus, your management style should change based on the stage the project is in.

Focus on the following in each stage to maximize project success:

Initiation phase:

• Keep clients involved in the decision making and consult them regularly.
• Emphasize clarity of vision and mission before developing the project charter.

Planning phase:

• Stick to the original brief and refrain from “over planning”.
• Make a list of client concerns and address them to improve acceptance.
• Don’t dawdle during planning; make it a priority for stakeholders on either side.

Execution phase:

• Stick to the project schedule and keep track of any deviations from the baseline.
• Follow the project brief as closely as possible.
• Use good project management techniques (Gantt charts, task management, collaboration, etc.) to ensure that the project stays on course.

Closure phase:

• Analyze the project thoroughly for failures and any issues related to scope.
• Make sure that the client is involved and is satisfied before hand-off.

Effectively, you’ll need to modify your management approach along with the project’s requirements. You’ll have to be empathetic and pragmatic during initiation and planning. But come execution time, you’ll have to forceful and disciplined.

Do this and you’ll see better results at each stage of the project life cycle.

Modify the Project Life Cycle on Technical Projects

The project life cycle, as it was originally formulated, was meant for projects where progress was linear and requirements were static. This is why it focuses so much on upfront planning. You’re expected to figure out what to do before you actually start executing.

Technical projects don’t work that way. Requirements, scope, and even objectives can change on the fly. If you use the Agile methodology, you can’t rely too heavily on strict plans.

To solve this problem, consider using the quality control model.

Quality-oriented project life cycle model

The traditional project life cycle is ideal for output that can be scaled, such as a factory producing widgets.

Scaling output is often a trivial matter in technical projects. If you can make one copy of a piece of software, you can also make a thousand easily.

Of bigger concern is the quality of the output. If the software is buggy, it will be reflected in every copy as well.

The quality-oriented model addresses this by distilling the project’s concepts into simpler, more achievable output. Once created, you expand the concept again to add new features and repeat the process.

For example, if you’re creating an app like Twitter, you would first create a public messaging system. Then you would expand the concept to add a login system, retweets, comment threads, etc.

Here’s an illustration to help you out:

This model divides the life cycle into three phases:

• Conceptualization: This is where you distill the project’s objective into something that is smaller and more readily attainable. That is, you move from concept - what might be done - to reality - what should be done.
• Materialization: This is where you actually create the distilled concept, or at least its most achievable form.
• Transition: In this phase, you expand the project’s focus and think of what else you can add (or “conceptualize”). Any new addition goes through the life cycle once again.

By breaking down complex ideas into simpler parts, you ensure that the output is actually functional. If a new addition breaks down the product, you can remove it easily.

Place the Project Life Cycle in Context

One of the shortcomings of the project life cycle model is that it is too project-focused. It places the project in isolation and not as part of a broader business initiative.

This often creates a sense of “project myopia”. Project managers get an idea of what is right for the project’s success, but miss what they should do to meet the client’s needs.

Perhaps the project planning took too long and the client’s goals are now completely different. Or maybe there is new management at the client’s company that doesn’t support the original objectives.

The traditional project life cycle model wouldn’t tell you these things.

To solve this problem, you have to place the project in context. You have to see it in light of its broader business and organizational environment.

One approach is to use life cycle project management (LCPM).

Life Cycle Project Management (LCPM)

LCPM fixes the shortcomings in traditional life cycles by involving the the following in project decision-making:

• Financial metrics such as internal rate of return and cost/worth ratio.
• Customer satisfaction objectives such as functionality, aesthetics, operability, end-user satisfaction, etc.
• Due diligence objectives such as the project’s adherence to regulations and exposure to risks & liabilities.

This creates a more integrated approach to project management. While you’ll still break the project into its five stages, you’ll constantly analyze it in terms of its financial, customers, and due diligence objectives.

For example, during the planning phase, you might analyze each planned deliverable in terms of its cost/worth ratio. Deliverables that don’t meet a baseline would be rejected. Those with the most favorable ratio would get priority during execution.

This way, you’ll not only run projects smoothly, but also ensure that they meet the client’s changing business needs.

Check out this article for further reading on life cycle project management.

Use a Professional Services Life Cycle Model

The traditional project life cycle works great when resources are static and scalable (as in a construction project). You can create strict plans for these resources and switch right to the execution phase.

But what if you're dealing with resources that are neither scalable nor fungible - as in a creative project? If a designer makes one design in 1 hour, you can't extrapolate that to assume he'll make 10 designs in 10 hours.

The strict planning requirements in the standard life cycle make it inadequate for such projects.

In such cases, you can switch to the Professional Services Life Cycle.

Professional Services Life cycle

This life cycle is designed for projects that involve complex human resources (such as designers, developers, etc.). For such projects to succeed, the involved resources have to understand the client's goals, agree on deliverables, and plan their work in a way to maximize creative output.

Consequently, the stages of the Professional Services Life Cycle are far more fluid. There is constant interaction between stages and you're encouraged to go back and forth until the client and your resources are in sync.

This model has five stages:

In brief:

• Selling or Pre-Planning: In this phase, project managers work with the sales team to analyze upcoming projects, their feasibility, and the resource availability for them. You're essentially pre-planning to ensure that you have the capability to fulfill any new project. Creative agencies that have a habit of taking on unprofitable or unfeasible projects can benefit greatly from this stage.
• Planning: The planning phase in this cycle is heavily focused on resources, their availability, and their suitability for each task. You can't assign just any resource to a project; you have to find the right fit. Thus, you'll focus on resource planning, scheduling, task assignment, and gather insight from past projects to determine resource fit.
• Delivering: The delivering phase is equivalent to the execution or control phase in the standard project life cycle. You'll keep track of the project's budget, tasks, and deliverables. You'll take corrective measures if things go beyond the baseline or if there are any upcoming risks.
• Accounting and Billing: This is an ongoing phase in the professional services life cycle. Its goal is to keep track of project financials and make sure that there's a positive ROI on each project phase, as well as the project as a whole.
• Analysis: You can call this the "business intelligence" phase. Rather than conducting a post-mortem after the project is finished, the analysis phase focuses on an ongoing review of the project's operations. If a designer isn't meeting his deadlines regularly, or a client pushing the project beyond scope, it will all go into the project analysis document. Your goal is to collect as much data about the project's running on an ongoing basis and use it to make better decisions in future projects.

If you’re running a creative agency, you stand to benefit a lot from adopting this life cycle. You’ll get better insight into your project’s operations and make sure that you only take on projects with a positive ROI.

Over to you

Despite its dominance in project management literature, the project life cycle is poorly understood, and even more poorly implemented. While it gives much-needed structure to your projects, it is also unsuitable when applied as-is, especially in creative or technical projects.

The approaches I outlined above should help demystify the project life cycle. Whether you’re running a technical project or handling a creative team, use these approaches to maximize your project success.

For even more strategies, tactics, and tips on running successful projects, check out our guide to creative project management below:

How do you handle the project life cycle in your organization? Share it with us in the comments below!