The governance logic
The Stage Plan is a contract for delegated authority.
The PID defines the project. The Stage Plan converts that definition into a controlled, time-bound commitment. The Project Board is not authorising daily activity. It is authorising a defined set of products within explicit limits.
Each level sets tolerances for the level below it: the Business layer controls the Project Board, the Board controls the Project Manager, and the Project Manager controls delivery teams. While the forecast stays within tolerance, authority remains delegated. When a breach is forecast, authority moves upward.
Approve a bounded stage, budget, scope and tolerance envelope.
Control work against the authorised plan and forecast the outcome.
Compare what was authorised with what was delivered and accepted.
Continue, correct, replan or stop on current evidence.
Stage purpose and authority scrutiny questions
- Is the stage a bounded period of work with a clear start, finish and decision point?
- Does the plan state exactly what the Project Board is being asked to authorise?
- Are the stage objectives connected to the approved PID and Business Case?
- Will the Board know what must exist at the end of the stage?
- Is responsibility clear at Business, Board, Project Manager and delivery-team level?
- Would authority revert upward before control is lost?
If any answer is no, strengthen the document before it goes to the Board.
Template one
Copyable Stage Plan template
Use this plan to ask the Project Board for authority to deliver one stage. Replace every bracketed prompt with verified project information and remove the guidance before submission.
[Insert project title]
[Insert stage]
[Insert controlled version and date]
[Insert Project Manager]
[Insert Project Board or approving authority]
[Insert proposed start and planned end]
[Insert classification]
[Insert latest approval date]
[State what this stage will achieve and what will exist at its completion that does not exist today.]
[Summarise the principal products, start date, end date and decisive milestones.]
[State the stage budget, principal risks and the limits of the authority requested.]
Approval is requested to authorise Stage [number] from [date] to [date], with a budget of [amount], for the products and tolerances defined in this plan.
[Explain the specific progression or decision this stage enables.]
[Identify the approved project objectives and benefits this stage supports.]
| Objective | Completion measure | Evidence | Owner |
|---|---|---|---|
| [Outcome to achieve] | [Measurable criterion] | [Acceptance evidence] | [Name] |
| [Outcome to achieve] | [Measurable criterion] | [Acceptance evidence] | [Name] |
| Product | Description | Owner | Acceptance criteria | Due |
|---|---|---|---|---|
| [Product] | [Required output] | [Name] | [Objective test] | [Date] |
| [Product] | [Required output] | [Name] | [Objective test] | [Date] |
| [Product] | [Required output] | [Name] | [Objective test] | [Date] |
In scope: [insert]. Out of scope: [insert]. Any change to these boundaries will be controlled through [insert process].
[Describe the in-house, supplier or hybrid model; main workstreams; sequencing; procurement steps; and governance interfaces.]
| Milestone | Planned date | Owner | Dependency | Control point |
|---|---|---|---|---|
| [Milestone] | [Date] | [Name] | [Dependency] | [Review or decision] |
| [Milestone] | [Date] | [Name] | [Dependency] | [Review or decision] |
| [Milestone] | [Date] | [Name] | [Dependency] | [Review or decision] |
[Identify the events that control the end date, the allowance held and the trigger for recovery or escalation.]
| Cost category | Forecast amount | Basis | Owner |
|---|---|---|---|
| Internal resources | [Amount] | [Estimate basis] | [Name] |
| External suppliers | [Amount] | [Estimate basis] | [Name] |
| Change and assurance | [Amount] | [Estimate basis] | [Name] |
| Contingency | [Amount] | [Risk basis] | [Name] |
| Total | [Amount] | [Reconciliation] | [Name] |
[Identify required roles, capacity, critical skills, confirmed availability and any resource gap.]
| Risk | Cause and effect | Exposure | Owner | Response | Tolerance threat |
|---|---|---|---|---|---|
| [Risk] | [Cause and consequence] | [Rating] | [Name] | [Action] | [Yes or no] |
| [Risk] | [Cause and consequence] | [Rating] | [Name] | [Action] | [Yes or no] |
| Item | Type | Owner | Required by | Effect if false or late |
|---|---|---|---|---|
| [Dependency or assumption] | [Type] | [Name] | [Date] | [Forecast effect] |
| [Dependency or assumption] | [Type] | [Name] | [Date] | [Forecast effect] |
Deliverables and acceptance scrutiny questions
- Are tangible products defined rather than merely listing activities?
- Does every product have one accountable owner?
- Are acceptance criteria objective enough to support a decision?
- Is the accepting authority named?
- Are partially complete or deferred products impossible to conceal?
- Does the product set fit within the authorised stage scope?
If any answer is no, strengthen the document before it goes to the Board.
Schedule, resources and dependencies scrutiny questions
- Are milestone dates based on sequencing, capacity and dependencies rather than aspiration?
- Are Board reviews, assurance points and external approvals visible?
- Are resource assumptions explicit and credible?
- Does the cost profile reconcile with the work and resources planned?
- Are material dependencies owned and dated?
- If a critical assumption fails, is the effect on the stage forecast understood?
If any answer is no, strengthen the document before it goes to the Board.
Tolerances are not comfort ranges. They define the boundary of the Project Manager's delegated authority.
| Dimension | Approved baseline | Tolerance | Forecast trigger | Escalation route |
|---|---|---|---|---|
| Time | [Baseline end date] | [Limit] | [Trigger] | [Recipient] |
| Cost | [Stage budget] | [Limit] | [Trigger] | [Recipient] |
| Scope | [Authorised products] | [Permitted variation] | [Trigger] | [Recipient] |
| Quality | [Acceptance standard] | [Permitted variation] | [Trigger] | [Recipient] |
| Risk | [Maximum exposure] | [Threshold] | [Trigger] | [Recipient] |
| Benefits | [Protected contribution] | [Permitted variation] | [Trigger] | [Recipient] |
[Frequency, owner and recipients]
[Frequency and escalation route]
[Reviews, dates and independence]
[Authority and thresholds]
[Timing and owner]
[Report date and Board decision date]
The Project Manager recommends that the Project Board authorise delivery of Stage [number] in accordance with the products, budget, schedule, controls and tolerances set out in this Stage Plan.
Tolerances and control scrutiny questions
- Are tolerances defined for time, cost, scope, quality, risk and benefits where applicable?
- Can the Project Manager tell precisely when escalation becomes mandatory?
- Are tolerance limits consistent with the PID and Business Case?
- Are reporting and review cycles frequent enough to forecast a breach in time?
- Does the change process protect the authorised scope and benefits?
- Is the next formal stage-boundary decision scheduled?
If any answer is no, strengthen the document before it goes to the Board.
Template two
Copyable Stage Accountability Report template
This report closes the control loop. It compares performance with the Stage Plan, confirms whether justification remains intact and gives the Project Board a decision to make. The same structure can support an End Stage Report or, with the focus widened to the PID, an End Project Report.
[Title, stage name and number]
[Approved Stage Plan version and date]
[Actual start and end dates]
[Amount]
Stage [number] delivered [principal products]. The stage completed [inside or outside] authorised tolerances for [dimensions]. Material variance relates to [insert]. The Business Case [remains or does not remain] viable. Approval is requested to [authorise next stage, approve corrective action, approve an Exception Plan or close the project].
| Objective | Planned outcome | Actual outcome | Variance | Conclusion |
|---|---|---|---|---|
| [Objective] | [Planned] | [Actual] | [Variance and cause] | [Achieved or not achieved] |
| [Objective] | [Planned] | [Actual] | [Variance and cause] | [Achieved or not achieved] |
| Product | Planned completion | Actual completion | Acceptance | Commentary |
|---|---|---|---|---|
| [Product] | [Date] | [Date] | [Accepted, partial or deferred] | [Impact] |
| [Product] | [Date] | [Date] | [Accepted, partial or deferred] | [Impact] |
| Dimension | Baseline | Actual | Tolerance | Variance | Conclusion |
|---|---|---|---|---|---|
| Time | [Baseline] | [Actual] | [Limit] | [Variance] | [Within or breached] |
| Cost | [Baseline] | [Actual] | [Limit] | [Variance] | [Within or breached] |
| Scope | [Baseline] | [Actual] | [Limit] | [Variance] | [Within or breached] |
| Quality | [Baseline] | [Actual] | [Limit] | [Variance] | [Within or breached] |
| Risk | [Baseline] | [Actual] | [Limit] | [Variance] | [Within or breached] |
| Benefits | [Baseline] | [Forecast] | [Limit] | [Variance] | [Within or breached] |
[Explain the causes, corrective action, contingency used and impact on the remaining project. Avoid defensive language.]
[State opening exposure, risks closed or escalated, issues resolved, residual exposure and threats carried forward.]
[Confirm reviews completed, acceptance processes followed, defects, rework and unresolved assurance actions.]
[Confirm continuing strategic need, affordability, value for money, benefit achievability and the effect of material changes.]
[State what should be repeated, stopped or changed in the next stage, with an owner for each action.]
It is recommended that the Project Board confirm completion of Stage [number] and [authorise the submitted next Stage Plan, approve corrective action, request an Exception Plan or close the project].
Stage performance and accountability scrutiny questions
- Are planned outcomes compared with actual outcomes?
- Are completion and acceptance reported separately?
- Are schedule and cost variances quantified and explained?
- Is contingency use visible?
- Are risk direction, residual exposure and unresolved issues clear?
- Does the report distinguish unfinished work from approved deferral?
If any answer is no, strengthen the document before it goes to the Board.
Business Case and Board decision scrutiny questions
- Does the review confirm whether the Business Case remains viable?
- Are forecast benefits, value for money and strategic alignment reconsidered?
- Are material changes in cost, time, scope or risk reflected in the justification?
- Are practical lessons carried into the next Stage Plan?
- Is the recommendation supported by the performance evidence?
- Does the report end with a decision rather than a vague update?
If any answer is no, strengthen the document before it goes to the Board.
Template three
Copyable Exception Report and Exception Plan structure
An exception occurs when a tolerance breach is forecast, not after it has happened. It means the authority delegated through the current Stage Plan has been exhausted. The Project Manager must escalate before continuing outside those limits.
[Identify the time, cost, scope, quality, risk or benefit tolerance forecast to be exceeded, including the forecast value and date.]
[Explain why the breach is forecast and the effect on stage products, project objectives, cost, schedule, risk, benefits and Business Case.]
| Option | Effect | Cost and time | Risk | Business Case | Recommendation |
|---|---|---|---|---|---|
| [Corrective option] | [Products and scope] | [Forecast] | [Exposure] | [Viability] | [Assessment] |
| [Replan option] | [Products and scope] | [Forecast] | [Exposure] | [Viability] | [Assessment] |
| [Stop or defer] | [Products and scope] | [Forecast] | [Exposure] | [Viability] | [Assessment] |
Approval is requested to [authorise corrective action within revised limits, commission an Exception Plan, terminate the stage or close the project] by [date].
An Exception Plan replaces the current Stage Plan. It is not an addendum. Use the Stage Plan structure above, then make the following changes explicit.
[Version and approval date]
[Date revised authority begins]
[Scope, products, schedule, cost or approach]
[Cause and evidence]
[Time, cost, scope, quality, risk and benefits]
[New limits requested]
[Confirm whether the revised plan remains desirable, viable and achievable, and identify any approval condition.]
Approval is requested to replace Stage Plan [version] with this Exception Plan and re-authorise delivery under the revised products, budget, schedule, controls and tolerances.
Exception and re-authorisation scrutiny questions
- Is escalation triggered by forecast breach rather than waiting for actual failure?
- Does the Exception Report identify the affected tolerance and underlying cause?
- Are the effect on the project and the available options stated honestly?
- Can corrective action remain inside existing tolerance, or is re-authorisation required?
- If an Exception Plan is needed, does it replace rather than supplement the current Stage Plan?
- Does the revised plan confirm Business Case viability and request new tolerances?
If any answer is no, strengthen the document before it goes to the Board.
Submission gate
Final stage-governance quality check
- Is the exact Board decision required unmistakably clear?
- Are stage objectives linked to the PID and Business Case?
- Are products, owners and acceptance criteria explicit?
- Do the schedule, resources and cost profile reconcile?
- Are dependencies, assumptions and material risks visible?
- Are all six tolerance dimensions addressed where relevant?
- Would a forecast breach trigger escalation before authority is exceeded?
- Does reporting test trajectory rather than merely record activity?
- Does the Stage Accountability Report compare actual performance with the authorised plan?
- Is continuing Business Case viability supported by evidence?
- Are lessons converted into actions for the next stage?
- Does any Exception Plan fully replace the superseded Stage Plan?
- Are revised limits and re-authorisation explicit?
- Could the complete record withstand later audit or assurance?
If any answer is no, the governance package is not ready for decision.
Integrated control record scrutiny questions
- Can a Board member trace the complete control loop from authorisation to the next decision?
- Do the Stage Plan and Stage Accountability Report refer to the same baseline?
- Are all forecasts supported by current delivery, cost and risk evidence?
- Is every recommendation within the decision authority of its recipient?
- Could the documents withstand challenge from finance, assurance and delivery leads?
- Would the governance record show who knew what, when, and what was authorised?
If any answer is no, strengthen the document before it goes to the Board.
Want the editable Word version?
Use the complete Stage Governance and Control guide.
The page above gives you the working structure for a Stage Plan, Stage Accountability Report, Exception Report and Exception Plan. The editable 25-page Word resource adds the governance explanation beneath the PID, detailed reviewer insight, preformatted tables, removable drafting guidance and responsible-AI prompts.
The resource unlocks shortly after the trial period.
Explore Prepare2Lead membershipIncluded with paid Prepare2Lead membership, from $97 a month.Important note
This working template supports stage governance. It does not replace the authority, baselines, reporting cycle, assurance requirements or terminology approved for your project.
Never use artificial intelligence to invent products, dates, costs, resources, forecasts, risks, tolerance positions, acceptance evidence or Board decisions. It can help structure verified material, but accountability remains with the Project Manager and Project Board.