Project Management Life Cycle: 5 Phases and How They Work
The team has started work, the deadline is approaching, and everyone seems busy. Yet the sponsor expects a different outcome from the one the team is building, and nobody can explain exactly what finished means. The missing piece isn't another progress meeting. It's an agreed set of decisions about why the project exists, what it will deliver, and who can authorise the next commitment.
The project management life cycle gives those decisions a structure. From an internal software change to a public infrastructure scheme, it helps a team separate permission to investigate, permission to deliver, and evidence that the result works.
Table of Contents
- The Five Phases at a Glance
- Initiation and the Business Case That Gets Approval
- How to Build a Baseline Plan You Can Defend
- Execution and Monitoring Before Costs Drift
- Closure and Why Sign-Off Is Not the Finish
- Where the Textbook Lifecycle Breaks Down
- Choose Your Next Step for Managing Projects
The Five Phases at a Glance
The project management life cycle is commonly explained through initiation, planning, execution, monitoring and control, and closure. Each phase names a management responsibility and the decision attached to it.
The lifecycle runs through approval gates. At a gate, the sponsor checks the evidence and decides whether the project should proceed, change direction, pause or stop. A busy team and a justified budget are different things, so spending continues only when the evidence supports it.
Project life cycle phases, outputs and gate checks
| Phase | Core question | Main outputs | Gate check |
|---|---|---|---|
| Initiation | Should this project exist? | Project charter, stakeholder list, preliminary business case | Sponsor approves go or no-go |
| Planning | How will the team deliver it? | Scope statement, schedule, budget, risk register | Baseline signed off by sponsor |
| Execution | Is the team building it as planned? | Deliverables, progress reports, change requests | Work completed to baseline standard |
| Monitoring and control | Is the project still on track? | Status reports, variance analysis, corrective actions | Variances within agreed tolerance |
| Closure | Did the project deliver its benefits? | Handover documents, lessons learned, final report | Sponsor accepts outcome and ownership |
Gates run on evidence
Building a house offers a familiar comparison. A responsible client waits for design and planning decisions before authorising foundations, and inspects the finished work before accepting the keys. A project gate works the same way: the sponsor's decision follows the evidence rather than the diary.
Monitoring and control runs alongside delivery, rather than waiting until execution finishes. Its checks are recurring decisions about whether work remains authorised and whether intervention is needed.
Ireland's Infrastructure Guidelines define five principal stages, from strategic assessment and preliminary business case through design and procurement preparation, post-tender final business case, implementation, and review or evaluation; they provide two approval stages before implementation for projects below €20 million, while major projects above €200 million require Government consent at the preliminary and final business-case stages.
Those stages map loosely onto the table. Initiation and planning cover the front-end appraisal and procurement decisions, execution and control run during implementation, and closure connects with review. Front-end phases often take longer than delivery itself, because approval waits on the quality of the case rather than the speed of the paperwork. Closure earns its place the same way, requiring the sponsor to confirm benefits and ownership before releasing the project.
As a sponsor, apply one test at any point: ask the project manager to name the current phase, the evidence still missing, and the person authorised to approve the next commitment.
Initiation and the Business Case That Gets Approval
Initiation answers a deceptively simple question: is this worth doing, and who decides? A team that starts with a preferred solution can easily overlook whether it addresses the right problem.
Consider an organisation replacing its customer-request system. Buying software isn't the objective. Resolving requests reliably is.
From a problem to an authorised project
The initiation work should establish the following foundations:
- A clear problem statement. It identifies what's wrong, who experiences it and why action matters now. An example charter line might read: Customer-service staff cannot consistently identify the owner of an unresolved request.
- A sponsor and stakeholder map. The sponsor owns the investment decision, while stakeholders contribute requirements, constraints and operational knowledge. A suitable line is: The operations director sponsors the project; service supervisors and support staff validate the requirements.
- A project charter. This authorises the work and records objectives, success criteria, high-level scope, exclusions and decision rights. For the same scenario: The project introduces request ownership and reporting; replacement of the finance system is excluded.
- A preliminary business case. This compares doing nothing, making a minimum intervention and pursuing the preferred option. A practical decision statement is: The sponsor will compare process changes with system replacement using whole-life cost, operational benefits and transition risk.
The charter and business case aren't interchangeable. The charter establishes authority and boundaries; the business case explains why the proposed investment deserves support. A guide to what a business case contains can help distinguish an attractive idea from a defensible proposal.
Why approval can take longer than expected
The Irish Government's 2025 report on infrastructure engagement and barriers states that typical wind-energy projects spend about 9 years in planning and development before construction, and that a study of seven projects found an average of 55 weeks with a funding department before producing a preliminary business case for external assurance.
Those are infrastructure development and approval timelines, not a suggested duration for an ordinary internal project. They nevertheless show why visible construction isn't a reliable measure of how much project work has already happened.
Appraisal time should test feasibility, affordability and risk. It isn't automatically wasted, although teams should still challenge duplicated reviews and unclear decision ownership.
Charter test: An unfamiliar reader should be able to identify the intended outcome, the exclusions and the decision owner without needing a separate explanation.
The warning sign is a charter that names a solution but offers no way to judge whether it solved the problem.
How to Build a Baseline Plan You Can Defend
A baseline is the authorised reference for scope, schedule and cost, supported by agreed risk controls. It gives later reports a stable comparison point. Without it, a project manager can describe activity but can't reliably explain whether delivery is improving or deteriorating.
Planning should begin with an approved charter and a named sponsor. Detailed estimates shouldn't become a substitute for deciding whether the work belongs in the project.
Building the agreed reference
Confirm scope against the charter. The scope statement should describe the deliverables, their acceptance criteria and explicit exclusions. Missing exclusions make it easier for a reasonable-sounding request to become unapproved work.
Break the work into manageable packages. Each package needs a deliverable, an accountable owner and a clear completion condition. A label such as system setup is too broad if nobody can say whether it includes configuration, testing and training.
Sequence activities and expose dependencies. The schedule should show what must finish before another activity can begin, with duration ranges considered before dates are committed. A common mistake is allowing installation time while forgetting access arrangements, approvals or specialist availability.
Build the budget from the work. Estimates should include the people, purchases and supporting activities needed for each package, with contingency connected to named risks. An unexplained allowance doesn't show what uncertainty the sponsor is accepting.
Create an owned risk register. Each risk needs a cause, possible event, consequence, likelihood, impact, response and owner. Listing supplier delay isn't sufficient unless someone is responsible for checking delivery confidence and preparing an alternative.
Agree tolerances and obtain sign-off. The sponsor should establish which deviations the project manager may handle and which require escalation. Otherwise, teams either seek permission for every minor adjustment or make consequential decisions without authority.
These steps make the plan reviewable. A sponsor can challenge an estimate, a dependency, or an assumption rather than accepting a promised completion date without question.
Checking whether the plan is ready
For the customer-request system, training should trace to the approved rollout scope, and training dates should reflect when a tested system becomes available. If staff availability remains uncertain, that risk needs an owner who has accepted the response.
A practical guide to creating a project plan can support this translation from authorised objectives into scheduled work.
The exit test isn't whether every uncertainty has disappeared. It's whether every deliverable traces to scope, assumptions are visible, risks have accepted owners, and the sponsor has signed an achievable reference plan. The approved version should then be stored with its approval record so later changes remain traceable.
Execution and Monitoring Before Costs Drift
An estimate can look convincing and still be optimistic. In its reference-class forecasting guidelines, Transport Infrastructure Ireland reports international average cost overruns of 26% for roads, 27% for bridges, 37% for tunnels and 38% for rail, alongside approximately six or seven out of ten transport projects experiencing an overrun.
International average cost overruns by transport project type
| Project type | Average cost overrun |
|---|---|
| Roads | 26% |
| Bridges | 27% |
| Tunnels | 37% |
| Rail | 38% |
These are international transport benchmarks, not predictions for every Irish project. Their practical message is that a team's detailed estimate deserves an external challenge before delivery commitments become difficult to reverse.
Reference-class forecasting means comparing the proposal with actual outcomes from comparable completed projects. The comparison should consider relevant characteristics such as complexity, procurement route and technical uncertainty, rather than selecting only successful examples.
A control routine that leads to decisions
During execution, the project manager coordinates people, suppliers and quality checks. Monitoring establishes whether the resulting work still supports the approved commitment.
A weekly control meeting can use a short, consistent agenda:
- Verify completed work. Progress should be supported by accepted deliverables or agreed completion evidence, not merely hours spent.
- Check actual and committed cost. Purchase orders and contractual commitments matter even when invoices haven't arrived.
- Review dependencies and risk responses. An approaching approval or supplier decision may threaten delivery before a milestone is formally missed.
- Assign corrective actions. Each action needs an owner, a due date and a clear test of completion.
Earned-value indicators can make trends easier to discuss where progress can be measured credibly. Cost performance index is earned value divided by actual cost, while schedule performance index is earned value divided by planned value.
Earned value means the budgeted value of completed work. An index below unity signals an unfavourable position against the relevant measure; it calls for investigation rather than an automatic conclusion about the final outcome. Schedule performance also needs checking against dependencies and critical milestones, because an aggregate index doesn't explain every delay.
Changes need authority, not informal agreement
Every proposed change should be logged, assessed for scope, cost, schedule, quality and risk, then approved at the appropriate threshold. A requested reporting feature, for example, may also require additional testing and training.
The escalation route should identify when the project manager acts, when the sponsor decides, and when a wider governance body must approve. Practical project monitoring and control depends on those decision rights being understood before pressure builds.
A deviation should trigger a corrective decision, not merely a retrospective explanation at the next meeting.
The original baseline shouldn't be overwritten to make performance appear healthier. Approved revisions need a decision record explaining what changed and why.
Closure and Why Sign-Off Is Not the Finish
A software rollout passes user testing and receives formal acceptance. The delivery team moves on, but support tickets have no owner, access requests remain unresolved, and operational staff don't know where the maintenance instructions are. The deliverable exists; the service isn't ready.
That distinction matters beyond software. In EirGrid's draft Investment Planning and Delivery Report 2025, approximately 69% of relevant early-stage milestones and about 75% of later gateway targets were achieved, while cumulative energisation performance stood at 63%, below the acceptable threshold, despite 100% performance against capital-approval and planning-approval targets.
Approval activity and operational completion are different measures. A sponsor needs evidence of the latter before treating a project as successfully handed over.
A handover that survives the team's departure
Closure should follow a deliberate sequence:
- Confirm acceptance. Deliverables are checked against agreed criteria, with outstanding defects recorded and assigned.
- Transfer operational ownership. A named owner accepts responsibility on a recorded date, supported by training, instructions and access.
- Settle commercial and resource commitments. Contracts, outstanding obligations, equipment and staff assignments are resolved explicitly.
- Capture useful lessons. The team records what happened, why it happened and what a future project should do differently.
- Archive the evidence. Decisions, approvals, technical documents and final reports remain accessible to the people who will need them.
Unresolved work doesn't have to disappear from view just because the main delivery team disbands. A residual-action register should identify who will complete it and who will verify the result.
Benefits need an operational owner
Acceptance proves that the output meets its specification. Benefits realisation asks whether using that output produces the intended improvement.
For the customer-request system, the operational owner could compare unresolved-request age with the starting position recorded during initiation. The review should happen after normal working patterns have settled, at a date agreed before closure.
Some benefits emerge after the project team has left. The closure report should distinguish benefits already demonstrated from those still awaiting review, with an accountable owner for each outstanding measure.
A practical action is to record the intended handover date and a benefit metric in the charter before delivery begins. That makes operational success part of the commitment, rather than an afterthought.
Where the Textbook Lifecycle Breaks Down
“Can we still approve this, or are we guessing?” That is the sponsor's question when operational staff finally review a nearly configured system and find the access controls missing. The model looks tidy on paper: initiation, planning, execution, closure. Real work behaves more like building a house and discovering, after the walls are up, that a doorway was drawn in the wrong place. Moving it is possible, but it now costs more time, more money and more goodwill.
A planning consent can stall an activity that appeared ready. A tender can show the intended specification is unaffordable. An external dependency, such as an outage window or a supplier delivery date, can force a different sequence. Events like these change what evidence the next gate must examine, and they make the sponsor's approval more rather than less important.
Returning to planning isn't necessarily failure
The failure pattern begins earlier, when a team starts configuration before requirements have been agreed. The earlier planning had been deferred until changes became harder to accommodate. Once review exposes the gap, scope, estimates and testing all have to be reopened under pressure.
Deliberate iteration has a purpose, a time boundary and an authorised decision point. Uncontrolled reversal happens when nobody knows which assumptions remain valid. The sponsor can check the difference by asking three questions: what changed, who approved reopening the decision, and which gate now controls the next commitment.
Tailoring principle: Documentation can be proportionate, but responsibility for approving a commitment must remain explicit.
Matching the controls to the work
| Project situation | Proportionate approach | Decision that remains necessary |
|---|---|---|
| Small internal change | Concise charter, short baseline and focused review | Sponsor accepts the purpose, boundaries and result |
| Iterative or hybrid delivery | Repeated build-and-review cycles within agreed investment limits | Material changes receive appropriate approval |
| Large capital project | Formal staged documentation and independent assurance | Major commitments pass the required gates |
Choosing among project management methodologies should help a team organise delivery while keeping accountability visible. An iterative approach can accommodate learning and still retain investment controls: each cycle ends in a review, each material change returns to an authorised person, and each gate confirms whether the remaining spend is still justified.
The project manager should record which documents can be combined or shortened and which approvals remain mandatory. The sponsor should agree to that tailoring before work starts, including how the team will respond if complexity or risk increases.
A lightweight approach works only when it preserves enough evidence for someone to make a sound decision. If a phase is revisited, the record should show the reason, the revised assumption and the approval that lets work continue.
Choose Your Next Step for Managing Projects
Understanding the phases matters less than applying them to a live decision. A project manager doesn't need a new system or a large template library to begin.
The most useful starting point is the project that currently causes uncertainty: the one with an unclear outcome, a disputed boundary or a handover nobody has accepted.
Practical actions for this week
- Locate the current decision. Apply the phase table to a live project and record its current phase, next gate and approving authority. If colleagues give different answers, that disagreement needs resolving before another commitment.
- Strengthen the charter. Add a measurable success criterion and an explicit exclusion. The success criterion should describe an outcome that can be checked, while the exclusion should settle a likely source of misunderstanding.
- Schedule the benefits review. Put an appropriate post-closure review in the calendar and name the person responsible for bringing operational evidence. An unowned calendar entry isn't a review arrangement.
These actions are deliberately modest. They create a practical basis for the next sponsor conversation without asking the team to rebuild its entire management approach.
The sponsor can then judge whether the immediate problem is missing information, insufficient authority or a genuine delivery constraint. Those problems require different responses, and another progress report won't necessarily resolve them.
Structured study as an option
For deeper study, the European Institute of Leadership and Management offers a Mini-MBA in Project Management, covering the full project management lifecycle from initiation to closure, and a Programme Certificate in Project Management, aimed at current project managers, team leaders and people moving into a project management role.
Prospective learners should compare each curriculum with their actual responsibilities before enrolling. Someone preparing business cases may need a different emphasis from someone coordinating delivery or accepting operational handovers.
The institute is a certified member of CPD Certification Service. That credential is relevant to professional development, but programme selection should still start with the learner's practical knowledge gaps.
The lifecycle works without any course. Applying the gate table, improving the charter and assigning a benefits review are useful first steps regardless of whether formal study follows.
European Institute of Leadership and Management offers project management study options covering the lifecycle from initiation to closure. Professionals seeking a structured way to develop these skills can visit European Institute of Leadership and Management and compare the available curricula with the project decisions they need to manage.