Project Management guide · Planning and scope
Project Initiation Document (PID): Contents and Example
A project initiation document (PID) is the set of information that defines a project, explains how it will be managed and forms the baseline the project board approves before delivery starts. It comes from PRINCE2, where the project manager assembles it during initiation, but many organisations use PIDs whatever their method. This guide explains what a PID contains, how to write one, a worked example and how it differs from a charter.
Key takeaways
- A PID defines what the project will deliver, why, how it will be managed and within which limits.
- In PRINCE2 the project manager assembles it during Initiating a Project and the project board approves it.
- Once approved, the PID is baselined and changes go through change control, often reviewed at stage boundaries.
- Tolerances in the PID let the project manager act without escalating every small deviation (management by exception).
- Scale it to the project: a small or Agile project needs a short PID, a large programme much more.
What is a project initiation document?
A project initiation document (PID) is a collection of information that defines a project and sets out how it will be managed. It brings together the project definition, business case, team structure, project plan, management approaches, controls and tailoring. Once the project board approves it, the PID becomes the baseline for running and judging the project.
PRINCE2 formally calls it project initiation documentation, because it does not have to be one file. It can be a single document, a set of linked documents or a page in a project management tool, as long as everything is approved and controlled together.
The PID answers the questions a decision-maker needs to answer before committing money and people:
- What exactly are we doing, and what are we not doing?
- Why is it worth doing, and what benefits do we expect?
- Who is responsible for what, and who decides?
- How long will it take and how much will it cost?
- How will we manage quality, risk, issues, change and communication?
- How much can things move before the project manager must escalate?
Although the term comes from PRINCE2, PIDs are widely used in UK public-sector bodies, health services and companies that do not follow PRINCE2 strictly.
Why the PID matters
PRINCE2 describes the PID as a contract between the project manager and the project board: it records what the board has agreed to and what the project manager has committed to deliver. In practice, a good PID gives you:
- A clear go or no-go decision: the board authorises the project on the basis of a complete picture, not a rough idea.
- A baseline: progress, cost, scope and benefits are measured against what was approved.
- Management by exception: agreed tolerances let the project manager run the project day to day and escalate only when limits are forecast to be exceeded.
- Clear governance: roles, decision rights and reporting lines are agreed before problems arise; see project governance.
- Continuity: new team members, suppliers and board members can understand the project from one place.
- A reference at closure: at the end, the board compares what was delivered with what the PID promised.
Where the PID fits in PRINCE2
The PID is produced in the second stage of a PRINCE2 project, the initiation stage, and is then used throughout. The table follows it through the PRINCE2 processes.
| PRINCE2 process | What happens to the PID |
|---|---|
| Starting up a project | Before the PID exists, a short project brief and outline business case are prepared so the board can decide whether initiation is worthwhile. |
| Directing a project (authorise initiation) | The project board agrees to invest in the initiation stage. |
| Initiating a project | The project manager develops the management approaches, project plan, controls and detailed business case and assembles them into the PID. |
| Directing a project (authorise the project) | The project board reviews and approves the PID. It is then baselined. |
| Managing a stage boundary | The project manager updates the PID where needed (for example the business case and project plan) for the board to review before the next stage. |
| Closing a project | The PID is used to compare the final outcome with the original baseline and approved changes. |
PRINCE2 7, published by PeopleCert in 2023, renamed the seven themes as practices: business case, organising, plans, quality, risk, issues and progress. It also added management approaches for commercial, sustainability, and digital and data, and introduced a new chapter on people. The PID still sits at the centre of initiation.
If you are comparing frameworks, see PMBOK vs PRINCE2.
What a project initiation document contains
PRINCE2 guidance describes the PID as bringing together the following parts. Outside PRINCE2, most PID templates follow a similar structure under different headings.
| PID section | What it contains |
|---|---|
| Project definition | Background, objectives, desired outcomes, scope and exclusions, deliverables, constraints, assumptions, users and interfaces |
| Business case | Reasons, options considered, expected benefits and dis-benefits, costs, timescales, investment appraisal and major risks |
| Project management team structure | The project board, project manager, assurance and support roles, often as an organisation chart |
| Role descriptions | Responsibilities and authority for each role |
| Management approaches | How quality, risk, issues and change, communication and other areas will be managed |
| Project plan | Stages, major products, milestones, resources, costs and timescales |
| Project controls | Stage boundaries, tolerances, reporting (for example highlight reports) and escalation |
| Tailoring | How the method has been adapted to suit the project and why |
Project definition
This is the heart of the PID. Write measurable project objectives, a scope statement with explicit exclusions, a list of deliverables with acceptance criteria, and the constraints and assumptions you are working within. Many disputes later in a project trace back to a vague definition here.
Management approaches in PRINCE2 7
Management approaches (called strategies in older editions) explain how a particular area will be handled on this project. PRINCE2 7 describes approaches for areas such as:
- Quality: standards, quality methods, responsibilities and records.
- Risk: how risks are identified, assessed and managed, with scales, owners and review frequency. See project risk management.
- Issues and change control: how issues and change requests are captured, assessed and decided.
- Communication: what information goes to whom, when and how. See communication plan.
- Commercial: how suppliers and contracts are managed (new in PRINCE2 7).
- Sustainability: how the project will meet its sustainability targets (new in PRINCE2 7).
- Digital and data: how data and digital technology will be handled (new in PRINCE2 7).
PRINCE2 also uses a benefits management approach, which describes how and when benefits will be measured, often after the project has closed.
Project controls and tolerances
Controls explain how the board will stay in charge without managing the detail: how the project is divided into management stages, what tolerances apply, what reports the project manager produces and how often, and when an exception must be raised. Tolerances are covered in more detail below.
PID vs project charter, business case and plan
Several start-up documents overlap. The table shows where each one fits.
| Document | Purpose | When | Approved by |
|---|---|---|---|
| Project brief (PRINCE2) | Short outline used to decide whether to start initiation | Starting up | Project board |
| Business case | Justifies the investment; kept up to date throughout | Outline at start-up, detailed in initiation | Executive or sponsor |
| Project charter | Formally authorises the project and the project manager (PMBOK-style) | Initiation | Sponsor |
| Project initiation document | Complete baseline for authorising and managing the project (PRINCE2) | Initiation | Project board |
| Project management plan | How the project will be executed, monitored, controlled and closed (PMBOK-style) | Planning | Sponsor |
| Statement of work | Contractual description of work a supplier will do | Procurement | Buyer and supplier |
The simplest way to remember the difference: a charter is short and says the project is authorised; a PID is longer and says exactly what has been authorised and how it will be run. The PID contains the project plan, but it also includes the business case, team structure and management approaches, which a plan alone does not.
A statement of work is different again: it governs a contract with an external supplier, while the PID governs the project internally.
How to write a project initiation document in 9 steps
The order below works for most projects. In PRINCE2 these steps happen in the Initiating a Project process; outside PRINCE2 they form your initiation phase.
- Review the project brief or mandate. Confirm the background, objectives, outline business case and any decisions the sponsor has already made. Check that any feasibility study findings are reflected.
- Agree the tailoring. Decide how formal the project needs to be given its size, risk and complexity, and record those decisions.
- Write the project definition. Set objectives, scope, exclusions, deliverables, acceptance criteria, constraints, assumptions and interfaces with other projects or systems.
- Define the management approaches. Agree how quality, risk, issues and change, communication and any other relevant areas will be managed. Start the risk register at this point.
- Set up the project management team. Name the executive or sponsor, senior user, senior supplier and project manager, with role descriptions. A RACI matrix makes responsibilities clear.
- Build the project plan. Break the work into products or deliverables, define stages, estimate effort, cost and duration, and identify milestones and dependencies.
- Refine the business case. Update costs, timescales, benefits and risks using the detailed plan. Use cost-benefit analysis where it helps.
- Set controls and tolerances. Agree stage boundaries, reporting frequency, tolerances for time, cost, scope and other areas, and how exceptions will be escalated.
- Assemble, review and submit for approval. Check the parts are consistent, ask project assurance to review, then submit the PID to the project board with a plan for the next stage.
Project initiation document example
The example below is illustrative and simplified. It shows how each part of a PID might read for a mid-sized organisation replacing its customer relationship management (CRM) system.
| PID section | Example entry |
|---|---|
| Background | The current CRM is no longer supported by its vendor and cannot integrate with the new finance system. |
| Objectives | Replace the CRM by 30 June; migrate all active customer records; train all 85 sales and service staff before go-live. |
| Scope | Includes selection support, configuration, data migration, finance integration and training. Excludes the website and marketing automation. |
| Deliverables | Configured CRM; migrated and validated data; finance integration; training materials; support handover. |
| Constraints and assumptions | Budget fixed at £250,000; go-live must avoid the year-end period. Assumes the finance system API is available by March. |
| Business case summary | Avoids the risk of running unsupported software; expected benefits are less manual re-keying and better reporting for sales managers. |
| Project management team | Executive: Sales Director. Senior user: Head of Customer Service. Senior supplier: CRM vendor account lead. Project manager: internal. |
| Management approaches | Quality: user acceptance testing signed off by the senior user. Risk: monthly risk review. Change: changes over £5,000 go to the board. |
| Project plan | Four stages: initiation; configuration and integration; migration and testing; training and go-live. |
| Tolerances | Time: plus or minus two weeks. Cost: plus or minus 5%. Scope: must-have requirements cannot be dropped without board approval. |
| Reporting | Fortnightly highlight report to the board; end stage report at each stage boundary. |
| Tailoring | Board meets monthly rather than at every decision; a single combined risk and issue log is used. |
Each entry is specific enough for the board to approve or challenge. Vague entries such as "improve customer data" give the board nothing to hold the project to.
Tolerances and management by exception
Tolerances are one of the most useful parts of a PID and one of the most often skipped. They are the agreed limits within which the project manager can make decisions without going back to the board.
PRINCE2 sets tolerances for areas such as time, cost, scope, quality, risk and benefits. Typical examples:
| Area | Example tolerance |
|---|---|
| Time | Plus or minus two weeks on the go-live date |
| Cost | Plus or minus 5% of the approved budget |
| Scope | Could-have features may be dropped; must-haves may not |
| Quality | Defined defect levels allowed at go-live |
| Risk | No single risk above an agreed impact score without board review |
| Benefits | Expected benefits may vary by an agreed percentage |
When the project manager forecasts that a tolerance will be exceeded, they raise an exception to the board rather than waiting for it to happen. This keeps board meetings focused on decisions that need them, and gives the project manager clear authority for everything else. Our project status report guide shows how to report against these limits.
Tailoring the PID for small and Agile projects
PRINCE2 expects the method to be tailored, and that applies to the PID too. A short internal project does not need a 40-page document.
- Small projects: combine sections, use a single page for the definition and plan, and reference standard organisational approaches for quality, risk and communication rather than rewriting them.
- Agile projects: PRINCE2 Agile still uses a PID, but it focuses on goals, outcomes, tolerances and ways of working. Detailed scope sits in a prioritised backlog, and tolerances usually allow scope to flex while time and cost stay fixed.
- Large or high-risk projects: keep the PID as the controlling summary and link to separate documents for the detailed plan, registers and approaches.
For more on combining PRINCE2 governance with Agile delivery, read PRINCE2 vs Agile.
Common PID mistakes and how to avoid them
| Mistake | What to do instead |
|---|---|
| Copying a long template and filling every section | Tailor the structure and record why sections were shortened or removed |
| Vague objectives and scope | Use measurable objectives and list exclusions explicitly |
| No tolerances, or tolerances of zero | Agree realistic limits so management by exception can work |
| Business case written once and forgotten | Update it at each stage boundary and check the project is still worthwhile |
| Roles named but not explained | Write short role descriptions with decision rights |
| Treating the PID as paperwork for approval only | Use it in board meetings, highlight reports and stage reviews |
| Changing it informally | Change the baselined PID only through change control |
| Duplicating content from other documents | Reference the risk register, plan or contracts rather than copying them |
Templates to build your PID
We do not offer a single PID template, because most of the content already lives in documents you will create anyway. These free templates cover the main sections, and you can assemble or link them into your PID:
- Project brief template for the starting-up summary.
- Business case template for the reasons, options, costs and benefits.
- Project charter template for objectives, scope, milestones and roles in one place.
- Project plan template for stages, tasks and milestones.
- RACI matrix template for the project management team and responsibilities.
- Risk register template and communication plan template for two of the core management approaches.
Once your PID is approved, the next step is running the first delivery stage against it.
Free templates for this topic
Frequently asked questions
What is a project initiation document?
A project initiation document (PID) is the collection of information that defines a project and how it will be managed: project definition, business case, team structure, plan, management approaches, controls and tailoring. In PRINCE2 it is approved by the project board and becomes the baseline for the project.
What does PID stand for in project management?
PID stands for project initiation document. PRINCE2 calls it project initiation documentation, because it can be one document or a set of linked documents.
Who writes the PID?
The project manager assembles it, with input from the team, users, suppliers and specialists. The executive or sponsor is responsible for the business case, and project assurance often reviews the PID before it goes to the board.
Who approves the PID?
In PRINCE2, the project board approves the PID when it authorises the project in the Directing a Project process. Outside PRINCE2, approval usually comes from the sponsor or a steering committee.
When is a PID written?
During the initiation stage, after the board has agreed to invest in initiation and before the main delivery work begins.
Is a PID only used in PRINCE2?
No. The term comes from PRINCE2, but many organisations, especially in the UK public sector, use PIDs regardless of the method they follow.
What is the difference between a PID and a project charter?
A project charter is a short, high-level document that authorises a project and its project manager. A PID is more detailed: it adds the business case, management approaches, controls, tolerances and the project plan, and acts as the full baseline for the project.
What is the difference between a PID and a project plan?
The project plan covers stages, products, milestones, resources, costs and timescales. The PID contains the project plan, plus the project definition, business case, team structure, management approaches and controls.
How long should a PID be?
There is no set length. A small, low-risk project may need a few pages, while a large programme may need a substantial document that links to separate plans and registers. Tailor it to the project's size and risk.
Can the PID change after approval?
Yes, but only through change control. In PRINCE2, the project manager typically updates the PID at stage boundaries for the board to review, and any change to the baseline needs board approval.
Do Agile projects need a PID?
PRINCE2 Agile still uses a PID, usually shorter and focused on goals, tolerances and ways of working. Detailed scope lives in a prioritised backlog rather than in the PID itself.
What are tolerances in a PID?
Tolerances are agreed limits for areas such as time, cost, scope, quality, risk and benefits. Within them, the project manager can act without escalating; if a tolerance is forecast to be exceeded, they raise an exception to the project board.
How is a PID different from a statement of work?
A PID governs a project internally and is approved by the project board or sponsor. A statement of work describes work an external supplier will deliver under a contract.