Project control

Manage by Stages

Use stages as practical control periods with clear authority, tolerances, evidence, and active continuation decisions.

What this helps you do

Managing by stages helps you avoid uncontrolled drift. It gives the PM authority to manage within an agreed stage, while giving the sponsor regular decision points to continue, adjust, pause, recover, or stop based on evidence.

Use this when

• Designing the project approach during initiation.
• Creating the governance calendar and reporting rhythm.
• Planning delivery where later work is uncertain and should not be over-planned too early.
• Supplier, funding, assurance, or operational dependencies create natural decision points.
• The project is in recovery and needs shorter control periods with faster sponsor decisions.
• Agile or hybrid teams need governance stages that sit above iterative delivery cycles.

What good looks like

• Each stage has a clear control purpose, not just a date range. The purpose might be discovery, mobilisation, pilot, build, transition, recovery, or closure.
• The current stage is planned in useful detail, while later stages are held at a higher level until evidence improves.
• Stage tolerances for time, cost, scope, quality, risk, and benefits are explicit enough to know when escalation is required.
• Stage boundaries are real decision points with evidence, options, and recommendation, not routine status updates.
• Weekly control links progress, RAID, decisions, change pressure, and benefit confidence back to stage tolerance.
• The sponsor knows what authority the PM has within the stage and what choices must come back to governance.

Minimum viable version

• A stage objective written in plain English: what must be true by the end of this stage.
• A stage plan with key products, milestones, owners, dependencies, and current assumptions.
• Agreed tolerances for the stage and a simple rule for when the PM must escalate.
• A boundary decision date with enough preparation time for evidence, options, and sponsor review.
• A weekly control rhythm to review progress, RAID movement, decisions, and change pressure.
• A short stage boundary pack before moving to the next stage.

Stronger version

• Assurance checkpoints timed around risk, spend, supplier commitments, policy, privacy, or operational readiness.
• Supplier checkpoints with evidence requirements, acceptance criteria, and escalation routes.
• Benefit confidence updates at each boundary so continuation decisions include value, not just delivery progress.
• Rolling-wave planning with firm detail for the current stage and controlled assumptions for later stages.
• Scenario planning for continue, reduce scope, extend, pause, reset, or stop decisions.

Step-by-step

1. Define the project lifecycle in control terms. Identify where the sponsor will need meaningful continuation decisions.
2. Set the purpose of the next stage. A good stage purpose explains the decision it enables, not only the work it contains.
3. Plan the current stage in detail: outputs, milestones, acceptance evidence, dependencies, resources, and reporting rhythm.
4. Agree tolerances with the sponsor. Make sure the team understands what can be managed locally and what must be escalated.
5. Run weekly control against the stage plan. Review forecast, RAID, decisions, changes, benefits, and supplier movement together.
6. Update the stage forecast when evidence changes. Do not wait for the boundary to reveal problems.
7. Prepare the stage boundary pack early enough to include actuals, forecast, lessons, business justification, and options.
8. Ask for an explicit boundary decision: continue as planned, adjust next stage, recover, pause, or stop. Record the rationale and conditions.

Inputs needed

• PID Lite or initiation baseline.
• Business case lite and current benefit confidence.
• Project product description and acceptance expectations.
• Current RAID, decision, issue, and change logs.
• Supplier plans, dependency dates, funding constraints, and assurance requirements.
• Lessons from previous stages or similar projects.

Outputs produced

• Stage plan with objectives, products, milestones, tolerances, and controls.
• Weekly highlight reports and updated RAID/decision logs.
• Exception report if tolerance is forecast to be exceeded.
• Stage boundary pack with actuals, forecast, lessons, options, and recommendation.
• Recorded continuation decision and updated plan for the next stage.

Common mistakes

• Making stages mirror calendar quarters without any control logic or decision purpose.
• Planning every stage in false detail at initiation, then spending the project explaining why it changed.
• Skipping boundary decisions because the team is busy and assuming continuation is automatic.
• Setting tolerances so vaguely that nobody knows when escalation is required.
• Reporting progress without saying whether stage tolerance and business justification still hold.
• Starting the next stage before boundary conditions, funding, or acceptance evidence are clear.

Tailoring notes

• For Lite projects, stages may be short and simple, but still need a purpose, tolerance, and continuation decision.
• For Standard projects, align stage boundaries to funding, product acceptance, supplier commitments, or governance decisions.
• For Enhanced projects, add assurance checkpoints, detailed boundary packs, and benefit confidence updates.
• For Recovery projects, shorten stages sharply. Use two-to-four week reset stages where decisions need to move quickly.
• For agile or hybrid delivery, use governance stages above sprints or increments. Do not force stage boundaries to equal sprint boundaries.
• For public-sector projects, preserve the audit trail for boundary decisions, conditions, and rationale.

Questions PMs usually ask

Related templates

Related tools

PRINCE2 mapping

Maps to the PRINCE2 principle of manage by stages and connects directly to plans, progress, business case, risk, issue, and change practices. Operationally, stages are the management contract between sponsor and PM.