What a PID must control
A delivery agreement, not an administrative form.
A Project Initiation Document defines what the project is, how it will be managed, what authority has been delegated and how deviation will be controlled. Once approved, it becomes the baseline against which delivery performance is judged.
Definition
What exactly is being delivered, and what is excluded?Authority
Who can decide, approve, change and escalate?Tolerance
How much deviation is permitted before escalation?Control
Where will risk, delay and overspend first become visible?Assurance
Who confirms that outputs are acceptable and controls work?The Business Case answers whether the organisation should proceed. The PID answers how the approved project will remain under control while proceeding. Reference the investment decision. Do not duplicate or quietly alter it.
A PID prepared only for approval is dead on arrival. Keep it controlled, revisit it when material assumptions or arrangements change, and use it as the reference point for exception, change and stage decisions.
Copyable Project Initiation Document template
Start with the control decision.
Copy this structure into Word or your organisation's approved template. Replace every prompt with project-specific evidence, remove drafting guidance, and make every authority, threshold and owner explicit.
Document details
[Insert project title]
[Insert organisation]
[Insert name and role]
[Insert name and role]
[Insert version and date]
[Insert decision or meeting reference]
[Insert security classification]
[Insert effective date]
Document control and approval
Record every material change so reviewers can distinguish the approved baseline from later updates.
| Version | Date | Author | Change made | Approved by |
|---|---|---|---|---|
| [Version] | [Date] | [Name] | [Describe the change] | [Approver] |
[Name, decision, date and reference]
[Decision, date and reference]
Executive Summary
Write this section last. A Board member reading only this page must understand what is being delivered, how it will be controlled and the authority being requested.
[Reference the approved Business Case and summarise the authorised objective and intended outcome.]
[Summarise the principal outputs, boundaries and exclusions.]
[Summarise the stages, governance, tolerances, reporting rhythm and principal risks.]
[State the exact authority requested to proceed within the defined scope, budget, tolerances and governance parameters.]
1. Project definition
Draw the line around the project.
Weak definition creates later arguments about what was agreed. Define the approved project in operational terms, with visible boundaries, outputs, assumptions and constraints.
[Reference the approved Business Case, decision date and selected option. Summarise only the context needed to control delivery.]
[State measurable outcomes aligned with the approved Business Case. Avoid objectives that merely describe activity.]
[List the products, capabilities, services or changes the project is required to deliver.]
Scope boundaries
| Boundary | Item | Reason | Owner of clarification |
|---|---|---|---|
| In scope | [Output, service, location or group] | [Why it is included] | [Named role] |
| Out of scope | [Explicit exclusion] | [Why it is excluded] | [Named role] |
Assumptions and constraints
[List the conditions treated as true for planning. State how and when each material assumption will be validated.]
[Record fixed time, funding, regulatory, operational, technical or commercial limits.]
[Identify external decisions, projects, suppliers, resources or events on which delivery depends.]
[Identify teams, programmes, services or organisations with which the project must coordinate.]
Project definition scrutiny questions
- Does the PID reference the approved Business Case without reopening the investment argument?
- Are the objectives measurable outcomes rather than delivery activities?
- Are the scope boundaries and exclusions explicit?
- Are assumptions visible and testable?
- Are constraints distinguished from assumptions?
- Are the required products or outputs clearly defined?
- Would an unauthorised expansion of scope be recognisable immediately?
3. Delivery plan
Make sequencing, dependency and contingency visible.
Reviewers are testing the logic of the plan, not the software used to draw it. The PID should show how delivery will be divided, where control decisions occur and what could prevent progress.
[Describe the phased, iterative, sequential or hybrid approach and explain why it fits the project’s uncertainty, risk, product and governance needs.]
[State the estimating method, scheduling assumptions, calendar, confidence level and location of the detailed plan.]
Stages, milestones and control points
| Stage or milestone | Required output | Target date | Owner | Dependency | Decision or control point |
|---|---|---|---|---|---|
| [Stage or milestone] | [Output] | [Date] | [Named role] | [Dependency] | [Decision or review] |
[State where contingency is held, which risks it addresses and who may use it.]
Resource plan
| Role or capability | Source | Required from | Availability confirmed by | Risk or dependency |
|---|---|---|---|---|
| [Role or specialist capability] | [Internal, supplier or recruitment] | [Date] | [Named owner] | [Constraint or dependency] |
Delivery plan scrutiny questions
- Does the delivery approach match the project’s risk, complexity and uncertainty?
- Are stages and control points linked to real decisions?
- Are dependencies, resource constraints and critical skills visible?
- Is contingency explicit rather than hidden inside optimistic dates?
- Are the people required to deliver the plan actually available?
- Does the plan show where delay would first become visible?
- Can the Project Board distinguish progress from activity?
4. Risk, issue and change control
Connect uncertainty to decisions.
Separate risks, issues and changes, but control them as one system. Each must influence the plan, forecast, tolerances and decisions rather than exist as an isolated log.
[State the identification method, scoring scale, review frequency, risk appetite, ownership model and escalation thresholds.]
[State how issues are recorded, prioritised, assigned, resolved and escalated.]
[State how requests are raised, analysed, recommended, approved, rejected and incorporated into the baseline.]
[State where decisions, rationale, conditions and delegated approvals are recorded.]
Top project risks
| Risk | Cause and consequence | Exposure | Owner | Response | Plan or tolerance effect |
|---|---|---|---|---|---|
| [Risk event] | [Cause and consequence] | [Rating] | [Named owner] | [Response and action] | [Adjustment or trigger] |
Change authority
| Change level | Impact range | Required analysis | Decision authority | Escalation condition |
|---|---|---|---|---|
| [Delegated, Board or external] | [Scope, cost, time, quality, risk or benefits] | [Evidence required] | [Named role or body] | [Tolerance or policy trigger] |
Risk, issue and change control scrutiny questions
- Are risks influencing the plan, tolerances and contingency?
- Does every material risk have a named owner and current response?
- Are issues separated from risks and escalated through a defined route?
- Is change impact assessed across scope, cost, time, quality, risk and benefits?
- Does change authority align with the agreed tolerances?
- Are decisions and approved changes recorded against the baseline?
- If a top risk materialised tomorrow, is the required response clear?
5. Financial control
Control the expected outturn, not only spend to date.
The PID must establish the authorised financial baseline, responsibility for forecasting and the point at which variance becomes an exception.
Budget baseline
| Cost category | Approved baseline | Current forecast | Contingency | Budget owner |
|---|---|---|---|---|
| Capital expenditure | [Currency amount] | [Currency amount] | [Currency amount or not applicable] | [Named owner] |
| Revenue expenditure | [Currency amount] | [Currency amount] | [Currency amount or not applicable] | [Named owner] |
| Internal resources | [Currency amount] | [Currency amount] | [Currency amount or not applicable] | [Named owner] |
| Supplier or commercial costs | [Currency amount] | [Currency amount] | [Currency amount or not applicable] | [Named owner] |
| Change and transition | [Currency amount] | [Currency amount] | [Currency amount or not applicable] | [Named owner] |
[Reference the approved funding source, conditions and budget period.]
[Explain how actuals, commitments, accruals, estimates to complete and expected outturn are calculated.]
[State when forecasts are updated, reconciled and reviewed.]
[State the thresholds, early warnings, exception route and authority to use contingency.]
Financial control scrutiny questions
- Does the baseline reconcile with the approved funding envelope?
- Are capital, revenue, internal resource and contingency visible?
- Is the forecast based on expected outturn rather than spend to date?
- Are variance thresholds aligned with the cost tolerance?
- Is contingency controlled and linked to risk?
- Is there a named budget owner and a defined reporting rhythm?
- Would a likely overspend be visible early enough to act?
6. Quality and assurance
Define acceptance before delivery claims success.
Completion is not acceptance. State the standards each output must meet, the evidence required and who has authority to approve or reject it.
Product quality and acceptance
| Product or output | Quality or acceptance criteria | Review method | Reviewer | Acceptance authority |
|---|---|---|---|---|
| [Product or output] | [Measurable criteria or standard] | [Test, review, inspection or audit] | [Named role] | [Named approver] |
[State how quality will be planned, controlled, recorded and reported.]
[State the independent, technical, commercial or governance assurance required and when it occurs.]
[State where evidence, decisions, defects and conditions of acceptance are retained.]
[State how non-conformance is corrected, escalated and reflected in the plan and forecast.]
Quality and assurance scrutiny questions
- Does every major output have measurable acceptance criteria?
- Are review, approval and acceptance treated as distinct activities?
- Are quality responsibilities assigned to named roles?
- Is independent assurance proportionate to project risk?
- Are quality activities integrated into the delivery plan?
- Is the response to a failed quality check defined?
- Can the project prove acceptance rather than merely completion?
7. Benefits realisation alignment
Protect the reason the project was approved.
The PID does not recreate the benefits case. It confirms how delivery remains connected to the approved benefits, who owns them and how changes will be assessed against them.
Benefits control
| Benefit or dis-benefit | Baseline and target | Owner | Measurement source | Review timing | Delivery dependency |
|---|---|---|---|---|---|
| [Approved benefit or dis-benefit] | [Baseline and target] | [Named owner] | [Evidence source] | [Date or frequency] | [Output, change or dependency] |
[Reference the approved benefits profile and explain how scope, plan and quality controls protect it.]
[State who measures and acts on benefits after project closure.]
Benefits realisation alignment scrutiny questions
- Do the benefits remain aligned with the approved Business Case?
- Does every material benefit have a named owner?
- Are baselines, targets and measurement sources defined?
- Are delivery outputs clearly connected to benefit-enabling changes?
- Are dis-benefits and negative operational impacts visible?
- Is responsibility clear after the project closes?
- Could the project complete successfully while the benefits still fail?
8. Reporting and control rhythm
Make reporting trigger action.
Every report should support a decision, escalation or control action. Define who receives it, what it contains and what happens when performance moves outside expectation.
Reporting and review schedule
| Report or control | Frequency or trigger | Prepared by | Audience | Decision or action supported |
|---|---|---|---|---|
| Highlight report | [Frequency or trigger] | [Named role] | [Recipient or body] | [Decision, approval or escalation] |
| Project Board review | [Frequency or trigger] | [Named role] | [Recipient or body] | [Decision, approval or escalation] |
| Stage boundary review | [Frequency or trigger] | [Named role] | [Recipient or body] | [Decision, approval or escalation] |
| Exception report | [Frequency or trigger] | [Named role] | [Recipient or body] | [Decision, approval or escalation] |
| Risk and issue review | [Frequency or trigger] | [Named role] | [Recipient or body] | [Decision, approval or escalation] |
| Financial forecast | [Frequency or trigger] | [Named role] | [Recipient or body] | [Decision, approval or escalation] |
| Quality or assurance review | [Frequency or trigger] | [Named role] | [Recipient or body] | [Decision, approval or escalation] |
[State the evidence required before the next stage is authorised.]
[State how a forecast tolerance breach is analysed, reported and decided.]
[State where approved versions, logs, plans and change decisions are maintained.]
[State the events that require this PID and the Business Case to be reviewed.]
Reporting and control rhythm scrutiny questions
- Does each report support a decision, escalation or control action?
- Is the reporting frequency proportionate to project risk?
- Are stage boundaries tied to approval of the next commitment?
- Is exception reporting triggered by forecast breaches, not only actual breaches?
- Are the baseline, logs and approved changes controlled consistently?
- Can the Board see cost, time, scope, risk, quality and benefits together?
- Will this PID remain a live control document during delivery?
Final approval statement
State exactly what approval establishes.
[Approval of this Project Initiation Document confirms that scope is defined, authority is assigned, tolerances are agreed and control mechanisms are established. Authority is granted to proceed within the parameters defined in this document. Any forecast material deviation beyond agreed tolerances requires formal escalation.]
[List any actions, evidence or restrictions attached to the decision.]
[List any specific authority granted through this approval.]
Final PID quality check
- Is the approved project clearly identifiable?
- Are scope boundaries and exclusions explicit?
- Are delivery objectives measurable?
- Are named people accountable for decisions and results?
- Are decision rights and escalation routes unambiguous?
- Are tolerances justified and linked to risk?
- Is the delivery plan credible and dependency aware?
- Are resources and critical skills actually available?
- Do risks change the plan, forecast or tolerances?
- Does change authority align with delegated tolerances?
- Does the financial forecast reconcile with the baseline?
- Are quality and acceptance criteria measurable?
- Does every material benefit have a named owner?
- Does reporting support decisions rather than bureaucracy?
- Is the approval and authority requested unmistakably clear?
If any answer is no, the PID is not ready to become the control baseline.
Want the editable Word version?
Use the full working PID guide.
The page above gives you a complete structure you can use immediately. The editable 27-page Word guide goes further with practitioner guidance, reviewer focus notes, common failure warnings, removable drafting prompts and a responsible AI drafting annex.
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 structured drafting. It does not replace your organisation's approved project documentation, governance requirements, assurance process or professional judgement.
Never use artificial intelligence to invent roles, authority, tolerances, budgets, risks, plans or approval. It can help organise verified material, but accountability remains with the Project Manager, Senior Responsible Owner and approving body.