NEW

Project Life Cycle: The 5 Phases Explained

What's eating up your time? Find out
August 2026
Project Life Cycle: The 5 Phases Explained

The project life cycle is the sequence of phases a project moves through from authorisation to closure. Most sources describe five phases: initiating, planning, executing, monitoring and controlling, and closing.

You will also find sources describing four project phases, and others describing six. They are not contradicting each other so much as drawing the boundaries differently, and the reason is easy to explain once you know where the numbering comes from. This guide covers all five phases in detail, settles the four versus five versus six question, and explains what changed in the standard itself as recently as November 2025.

Four, five or six phases? Why sources disagree

The disagreement over how many project phases exist is about whether monitoring and controlling counts as one of them, because unlike the others it does not happen at a point in the timeline. It runs alongside everything else.

That single question produces all three answers you will see:

Count The phases Why it is counted this way
Four phases Initiating, planning, executing, closing Monitoring is treated as part of executing rather than separate, so only the sequential stages are counted
Five phases Initiating, planning, executing, monitoring and controlling, closing The standard answer, and the one used by PMI. Monitoring is named separately because it carries its own work
Six phases The five above plus a concept or handover stage Some industries add a pre-project definition stage, or a post-project review after closing

If you are answering an exam question on the project management life cycle, use five and say that monitoring and controlling runs in parallel with the others rather than after them. That is the distinction examiners are usually testing.

The five phases of the project life cycle

1. Initiating

The initiating phase establishes that the project is worth doing and formally authorises it to begin. Nothing is built here. The output is a decision and the authority to spend money.

The work involves defining the business case, identifying the stakeholders, setting objectives at a high level, and producing a project charter. The charter is what actually matters: it names the project manager, states the objectives, and gives the authority to use organisational resources.

Projects that skip this phase usually get into trouble later over scope, because nobody wrote down what the project was for in terms specific enough to test against.

2. Planning

The planning phase decides how the project will be delivered, and it is normally the longest phase on paper. Scope, schedule, budget, resources, risk, quality and communications all get defined here.

Typical outputs are a work breakdown structure, a schedule with dependencies, a cost baseline, a risk register and a resource plan. The cost baseline matters more than most teams realise, because without it there is nothing to measure actual spend against later.

Planning is also where estimates are made, which is where historical data earns its keep. Estimating from memory produces the same optimistic numbers every time. Estimating from what similar past projects actually took produces numbers you can defend.

3. Executing

The executing phase is where the deliverables get built, and where most of the budget is spent. The project manager’s job shifts from planning to coordinating people, managing quality and keeping stakeholders informed.

The characteristic problem of this phase is that it feels productive while going quietly off track. Work is visibly happening, so nobody asks whether it is happening at the planned rate or cost until a milestone is missed.

4. Monitoring and controlling

Monitoring and controlling compares actual progress against the plan and corrects the difference. It is the phase that does not sit in sequence: it starts when execution starts and runs until closure.

The work is measuring performance against the baselines set in planning, managing change requests, tracking risks and reporting status. Change control belongs here, and it is the single most useful control on a project: a documented process for deciding whether a requested change is accepted, and what it does to schedule and budget if it is.

This is the phase that depends most directly on data. Without recorded hours and costs there is nothing to compare against the plan, and monitoring becomes a status meeting where people describe how they feel the project is going.

5. Closing

The closing phase formally finishes the project: deliverables are handed over and accepted, contracts are closed, resources are released and the work is documented.

The step most often skipped is the lessons learned review, and skipping it is why organisations keep making the same estimating errors. A closed project with recorded actuals becomes the reference data for the next project’s planning phase, which is what turns a life cycle into a cycle rather than a line.

What changed in the PMBOK standard

The five phase view of the project management life cycle comes from PMI’s Process Groups, and the standard has moved twice in recent years, which is part of why online sources disagree.

  • PMBOK Guide 6th edition. Defined the five Process Groups: initiating, planning, executing, monitoring and controlling, and closing. This is the model most articles still describe.
  • PMBOK Guide 7th edition, 2021. Moved away from that structure, replacing process groups and knowledge areas with 12 principles and 8 performance domains. The intent was flexibility across different delivery approaches rather than one prescribed process.
  • PMBOK Guide 8th edition, released November 2025. Brought practical structure back. It consolidates to 6 core principles and 7 performance domains, and adds five Focus Areas containing 40 processes. The Focus Areas are named initiating, planning, executing, monitoring and controlling, and closing.

So the five familiar names are current again under a new label. If you are studying for the PMP, note that the exam update aligned to the 8th edition is expected on 1 July 2026, and that PMI published a separate Process Groups practice guide in 2022 to keep the older framework available alongside the 7th edition.

Why this matters when you read other guides:
An article written between 2021 and 2025 may tell you the process groups were retired, and an article written before 2021 will present them as the standard. Both were accurate when published. The 8th edition brings the five names back as Focus Areas, so a guide describing five phases is once again aligned with the standard.

Predictive, iterative and agile life cycles

The five project phases above describe a predictive life cycle, where scope is defined up front and the phases run largely in sequence. Not every project works that way.

  • Predictive. Scope, schedule and cost are fixed early. Suits construction, manufacturing and regulated work where changing direction late is expensive.
  • Iterative and incremental. The product is built in repeated cycles, each adding function or refining what exists. Planning and executing repeat rather than happening once.
  • Adaptive or agile. Work happens in short timeboxed iterations with scope reprioritised each time. Initiating and closing still exist at the level of the whole project, but planning, executing and monitoring repeat inside every iteration.
  • Hybrid. Common in practice. A predictive frame for budget and milestones, with agile delivery inside the executing phase.

The phases do not disappear on an agile project. They compress and repeat. Every sprint contains planning, execution and a review, which is monitoring and controlling under a different name.

How long each phase takes

There is no fixed split, but the shape is consistent: executing dominates the calendar, and planning is consistently under-allocated relative to how much it determines.

A rough distribution for a predictive project, useful as a sanity check rather than a rule:

Phase Typical share of elapsed time What it usually means if yours differs
Initiating Around 5% Much longer suggests the business case is not convincing anyone
Planning Around 20 to 25% Under 10% usually reappears as rework during execution
Executing Around 60 to 70% Where nearly all the budget goes, and where overruns become visible
Closing Around 5% Frequently near zero, which is why estimating never improves

Monitoring and controlling has no share of its own because it runs across executing rather than after it. If you are measuring it separately, count it as effort rather than elapsed time.

The number worth checking against your own history is planning. Teams that record hours by phase usually discover they planned for less time than they believed, and that the projects which ran over were the ones where planning was compressed. Comparing estimated against actual time across finished projects is the quickest way to find out whether that pattern holds for you.

Phase gates: how you know a phase is finished

A phase gate is a decision point at the end of a phase where the work is reviewed and someone decides whether to continue, change direction, or stop. Without gates, phases blur into each other and a project continues by default rather than by decision.

A gate review asks four questions. Were the deliverables for this phase actually completed. Is the business case still valid. Are the schedule and budget still realistic given what we now know. Do the risks still look acceptable.

The uncomfortable purpose of a gate is that stopping is a legitimate outcome. A project cancelled at the end of planning has cost a fraction of one cancelled during execution, and organisations that never cancel anything at a gate are not really running gates.

The characteristic mistake in each phase

Each phase of the project management life cycle fails in its own predictable way. These are the ones worth watching for.

  1. Initiating: objectives nobody can test.

    A charter that says the project will “improve efficiency” cannot be used to judge whether the project succeeded. Objectives need a number and a date, agreed before anyone starts, or scope arguments later have nothing to resolve against.

  2. Planning: estimating from optimism rather than history.

    Estimates made by asking people how long something should take produce the same shortfall every time. Estimates made from what comparable past work actually took are defensible, which is the practical argument for recording actuals in the first place.

  3. Executing: mistaking activity for progress.

    Work is visibly happening, so nobody checks whether it is happening at the planned rate. The fix is measuring percentage complete separately from percentage of budget spent, because those two figures diverging is the earliest warning you get.

  4. Monitoring and controlling: change without change control.

    Scope added in a conversation and never written down. It is not the change that damages the project, it is that the schedule and budget were never adjusted for it, so the project is now measured against a plan that no longer describes the work.

  5. Closing: skipping the review.

    The team moves to the next project and the actuals are never captured. That is the step that would have fixed the planning phase of the next project, which is why the same estimating error repeats across years.

Tracking a project across its life cycle

Each of the project phases needs a different number, and all of them come from the same underlying record of who worked on what.

Phase The question to answer What you need recorded
Initiating Is this worth doing? Actual costs of comparable past projects
Planning How long and how much? Historical hours per task type, and a cost baseline to measure against
Executing Are we on the planned rate? Hours logged against tasks as the work happens
Monitoring and controlling How far from plan are we? Actual versus estimated time and cost, with budget alerts
Closing What did it really take? Final actuals kept as reference for the next project

The pattern is that closing feeds initiating. Recorded actuals from a finished project are exactly the estimating data the next project needs, which is the practical reason to complete the closure phase properly rather than moving straight on.

actiTIME covers that loop: estimated versus actual time per task, cost and billing budgets at customer, project or task level with a progress bar that turns red on overrun, and reports that keep the final actuals available for the next round of planning.

actiTIME helps us focus on the business

actiTIME is very robust, integrated well into your business process, and most important, helps you focus on your business instead of monkeying around with technology.

Frequently asked questions

What are the 5 phases of a project life cycle?

Initiating, planning, executing, monitoring and controlling, and closing. Initiating authorises the project and produces the charter. Planning defines scope, schedule, budget and risk. Executing produces the deliverables. Monitoring and controlling compares progress against the plan and manages change. Closing hands over the work, releases resources and records what was learned.

What are the four stages of a project life cycle?

Initiating, planning, executing and closing. The four stage version is the five phase model with monitoring and controlling folded into executing rather than named separately. It is not a different life cycle, only a different way of counting, and it is used because monitoring is the one activity that does not occupy its own slot in the timeline.

What are the six stages of the project life cycle?

There is no single six stage standard. Versions with six usually take the standard five and add either a concept or feasibility stage before initiating, or a post-project review and benefits realisation stage after closing. Both additions are common in specific industries rather than universal, so check which one a given source means before quoting it.

What is the difference between a project life cycle and a project phase?

The project life cycle is the whole sequence from start to finish. A phase is one segment within it, ending in a deliverable and usually a decision point. The life cycle is the container; phases are its parts. A project has one life cycle and several phases, and phases in some approaches repeat while the life cycle does not.

Which phase takes the longest?

Executing consumes the most time and the largest share of the budget on most projects. Planning takes the most calendar time relative to its visible output, which is why it is the phase most often cut short under pressure. Cutting planning tends to lengthen execution rather than shorten the project, because unresolved decisions surface later as rework.

From plan to actuals, in one record

Every phase of the life cycle asks a version of the same question: how does reality compare with the plan. Answering it needs hours and costs recorded against tasks while the work happens, not reconstructed afterwards.

actiTIME tracks estimated against actual time, flags budget overruns as they occur, and keeps the final numbers as reference data for planning the next project. Start a free 30 day trial. No credit card required, and the free version covers up to 3 users afterwards.

Are you ready to drive your business growth with actiTIME?

Start Using actiTIME