Controlling a Stage Process in PRINCE2 2017

Executive summary

Purpose and day-to-day management authority

Controlling a Stage is the process in which the Project Manager performs the day-to-day project-management work for an authorised management stage. Its purpose is to assign work, monitor that work, deal with issues, report progress to the Project Board and take corrective action so the stage remains within tolerance.

The process depends on the manage-by-stages and manage-by-exception principles. The Board authorises the Stage Plan and gives the Project Manager stage tolerance. Within that authority, the Project Manager should be able to manage without constant Board intervention. The Board still receives agreed Highlight Reports and remains available for direction, but operational decisions stay delegated unless the forecast moves beyond tolerance.

The source normally applies this process to delivery stages after project authorisation. It notes that very large or complex projects may also use it during initiation to control production of management products. The deciding factor is whether the work benefits from formal Work Package and stage-control discipline.

Keep the stage centred on authorised products

One objective is to focus attention on requesting and receiving the specialist products agreed for the stage. This protects the project from uncontrolled drift. A stage can become busy while accomplishing little if teams continuously take on attractive tasks that were never part of the authorised product scope.

The Stage Plan provides the management baseline. Product Descriptions define what products are expected and how quality will be judged. Work Packages convert that plan into explicit assignments. The Project Manager monitors movement away from the agreed direction, checks the Business Case remains relevant and ensures risks and issues stay controlled.

The source also reminds readers that management products—reports, registers and plans—are not project outputs. They enable delivery. The practical balance is to maintain enough management information to control the specialist outputs without allowing reporting activity to become a substitute for delivery.

The three tolerance levels in operation

The source sets out three levels of tolerance. Project tolerance is set for the Project Board by the commissioning authority. Stage tolerance is set for the Project Manager by the Board. Work Package tolerance is set for Team Managers by the Project Manager. Each level creates an explicit boundary of delegated authority.

If the Project Manager is also performing Team Manager duties on a small project, the source still recommends using Work Packages. This keeps the product assignment and tolerance visible even when the same person occupies both management perspectives. The team members need to know what is authorised and how progress will be tracked.

Authorise a Work Package

The Project Manager decides which products should be worked on during the stage and authorises Work Packages. A Work Package contains the description of work, relevant Product Descriptions, production constraints and confirmation that the Team Manager or individual agrees the work can be performed within those constraints.

For small projects, the source allows relevant material from the Project Plan or PID to be copied into the Work Package, provided configuration control is maintained when upstream information changes. In larger projects, references to controlled source material may be more manageable than duplicating extensive content.

Before authorisation, agree reporting frequency, Work Package tolerance, interfaces, quality methods, acceptance responsibilities, resource assumptions and constraints. The Team Manager should be able to accept the package as a realistic commitment rather than receive it as a unilateral task instruction.

Review Work Package status and receive completed work

During execution, the Project Manager reviews Work Package status using Checkpoint Reports, Team Plans where used, the Quality Register, risk and issue information and other evidence. Actual performance and forecasts feed the Stage Plan so stage-level decisions are based on current information.

Product status matters more than activity optimism. A team may have consumed most of its planned effort but still lack a review approval or critical input. The Project Manager should therefore examine product completion, quality activity status, remaining effort, risks and forecasts rather than accept a single percentage-complete measure.

When a Work Package is delivered, the Project Manager confirms that the agreed products and approvals have been received and that the package can be accepted as completed. Configuration records and product status should reflect the current state. Any remaining defects or follow-on actions should be controlled rather than hidden by declaring the package complete.

Review management-stage status

The Project Manager routinely assesses whether the stage remains healthy and within tolerance. This requires a consolidated view of Stage Plan actuals and forecasts, Work Package status, quality progress, risk exposure, issues, changes, resource conditions and Business Case implications.

A good stage review is forward-looking. It asks whether the remaining products can still be delivered within the authorised limits, not merely whether last week’s activity matched the schedule. Forecast accuracy becomes increasingly important as tolerance is consumed.

Where performance is drifting but still within authority, the Project Manager can make adjustments and take corrective action. These actions should preserve the agreed objectives and remain within the Project Manager’s authority. If the necessary response itself exceeds authority or the stage is still forecast to exceed tolerance, escalation is required.

Report highlights

The Project Board manages by exception but still needs reassurance that the project is progressing. The Project Manager therefore produces Highlight Reports at a frequency determined by the Board and documented in the Communication Management Approach.

A Highlight Report should be concise enough for governance use while covering the information the Board needs to judge status and emerging concerns. It can summarise product progress, stage/project forecast, key risks and issues, tolerance position and decisions expected. The source treats it as a routine time-driven control, not as an escalation mechanism.

Do not delay material escalation until the next Highlight Report. If a forecast stage exception emerges, the Exception Report is the appropriate event-driven control. Routine reporting and exception escalation serve different purposes.

Capture, examine and escalate issues and risks

Issues and risks arise throughout delivery. The Project Manager records and assesses them using the relevant Change and Risk procedures. An issue that can be resolved within stage tolerance and authority can be managed through corrective action. A risk response may similarly be implemented through a Work Package or other authorised action.

If, despite corrective action, the stage is forecast to exceed tolerance, the Project Manager escalates. The source notes that early escalation can be useful even before a full Exception Plan is prepared because the Board may be able to help resolve the situation and can prepare its decision-making time.

Escalation should explain the forecast, not merely announce a problem. State which tolerance is threatened, why, the consequences for the Business Case and products, actions already taken, options and the recommended next step.

Take corrective action

Corrective action is action the Project Manager can take within delegated stage authority to recover or protect the Stage Plan. The source suggests examining the available information, identifying possible responses, selecting the preferred action and often authorising a Work Package to implement it.

The Change Control Procedure should be used where the action affects issues or baselines. Risk records, issue records, Work Packages, Stage Plan and configuration information should be updated to reflect the decision. This avoids a common control failure in which recovery actions are agreed verbally but the plan and product baseline remain unchanged.

Not every problem can be corrected at Project Manager level. The solution may be external to the project, require more budget than tolerance permits or change an objective beyond authority. In those cases the Project Manager prepares a decision-quality escalation rather than attempting an unauthorised fix.

Practical verification checklist

• Confirm the Stage Plan and tolerances are authorised before controlling delivery.
• Authorise each significant specialist assignment through a Work Package.
• Agree product, quality, reporting and tolerance details with the delivery team.
• Review Work Package status using evidence, not only task-percentage estimates.
• Update Stage Plan actuals and forecasts regularly.
• Review risk, issue, quality and Business Case implications as part of stage health checks.
• Send Highlight Reports at the agreed frequency.
• Use Change and Risk procedures for issues and uncertainty.
• Take corrective action only within delegated authority.
• Raise an Exception Report when stage tolerance is forecast to be exceeded.

Common mistakes to avoid

• Releasing work informally with no agreed Work Package.
• Micromanaging teams instead of controlling products, tolerances and interfaces.
• Using Highlight Reports as a substitute for immediate exception escalation.
• Waiting for an actual tolerance breach before involving the Board.
• Changing baselines as “corrective action” without issue/change control.
• Declaring a Work Package complete without confirming product quality and approval.

Related KEVOS handbook pages