Project Initiation Document: [Project name]
Project initiation document (PID): the integrated baseline that a
project board approves at the end of initiation, before it authorises
the first delivery stage. It brings together in one place what the
project will deliver and why, how it will be organised and controlled,
the approaches for quality, change, risk, communication and benefits,
the project plan with its stages and tolerances, and how the method
has been tailored. The structure is aligned with the initiation
documentation of a staged, product-focused project method (see the
standard and licence note) and with the initiating guidance of ISO
21502:2020. It suits any sector and any delivery approach, including
agile delivery inside managed stages. Replace every [bracketed] value
and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [PID-PROJECT-001] |
| Project name and code | [Project name], [PRJ-NNNN] |
| Version | [0.1] |
| Status | [Draft / Submitted / Approved / Updated / Closed] |
| Owner | [Project manager] |
| Approver | [Project board: executive, senior user, senior supplier] |
| Built from | [Project brief or charter ID and version, mandate reference] |
| Current stage | [Initiation / Stage N name] |
| Last updated | YYYY-MM-DD |
| Next planned review | [End of stage N, YYYY-MM-DD] |
| Classification | [Internal / Confidential] |
Approvals
| Role | Name | Decision | Reference | Date |
|---|
| Executive (chair of the project board) | [Name] | [Approved / Approved with conditions / Rejected] | [Board minutes ref] | YYYY-MM-DD |
| Senior user | [Name] | [Decision] | [Ref] | YYYY-MM-DD |
| Senior supplier | [Name] | [Decision] | [Ref] | YYYY-MM-DD |
| Project assurance (review) | [Name] | [Reviewed, findings closed] | [Ref] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change | Approved by |
|---|
| 0.1 (Example) | YYYY-MM-DD | [Project manager] | First draft from approved project brief | n/a |
| 1.0 (Example) | YYYY-MM-DD | [Project manager] | Baselined, stage 2 authorised | Project board |
| 1.1 (Example) | YYYY-MM-DD | [Project manager] | End of stage 2 update: plan, business case, risks | Project board |
Contents
1. Project definition
1.1 Background
[Two or three paragraphs: the problem or opportunity, why now, and the
decision that started the project.]
Example: Varrowby Libraries Trust runs 14 branch libraries. Its
library management system reaches the end of vendor support on
YYYY-MM-DD, and staff spend about a quarter of counter time on routine
issue and return. The trustees approved a project brief on YYYY-MM-DD to
replace the system and introduce self-service lending in every branch.
1.2 Objectives
| ID | Objective | Measure | Target | By |
|---|
| OBJ-01 (Example) | Replace the library management system before support ends | New system live in all branches | 14 of 14 branches | Month 11 |
| OBJ-02 (Example) | Move routine lending to self-service | Share of issues and returns made at kiosks | 70% | 3 months after go-live |
| OBJ-03 (Example) | Deliver within the approved budget | Outturn against budget | GBP 1,180,000 within tolerance | Project close |
| [OBJ-NN] | [Objective] | [Measure] | [Target] | [Date] |
1.3 Scope and exclusions
| In scope | Out of scope |
|---|
| Library management system, data migration from the old system (Example) | Replacement of public access computers |
| 42 self-service kiosks and security gates in 14 branches (Example) | Building alterations beyond kiosk power and network points |
| Staff training and revised counter procedures (Example) | Changes to opening hours |
| [Item] | [Item] |
1.4 Constraints, assumptions and interfaces
| ID | Type | Statement | Owner |
|---|
| CON-01 (Example) | Constraint | Go-live must be before vendor support ends on YYYY-MM-DD | Executive |
| CON-02 (Example) | Constraint | No branch may close for more than two working days for installation | Senior user |
| ASM-01 (Example) | Assumption | Borrower records can be migrated without re-registration | Senior supplier |
| INT-01 (Example) | Interface | Regional library consortium catalogue (shared records) | Consortium technical lead |
| [ID] | [Type] | [Statement] | [Owner] |
2. Project approach
| Decision | Options considered | Choice and reason |
|---|
| Sourcing (Example) | Build, buy a hosted system, join the consortium's shared system | Buy a hosted system: lowest risk to the support deadline, shared catalogue still possible through the consortium interface |
| Rollout (Example) | All branches at once, phased by branch group | Three waves (pilot of 2 branches, then 6, then 6): lets the pilot inform training before 12 branches go live |
| Delivery method (Example) | Fully predictive, iterative configuration in sprints inside stages | Configuration and reports in two-week iterations; hardware rollout planned predictively |
| [Decision] | [Options] | [Choice and reason] |
Standards the products must meet: [accessibility standard, data
protection rules, organisational security policy, supplier contract
terms]. Operational and maintenance considerations: [who runs the
system after handover and what they need from the project].
3. Business case summary
| Element | Summary (Example) |
|---|
| Reasons | System support ends; counter time spent on routine lending |
| Preferred option | Hosted system with self-service, three waves |
| Expected benefits | 1.9 FTE of staff time released to reader development; old system support costs avoided (GBP 85,000 a year); longer self-service hours |
| Expected dis-benefits | Fewer staff contacts for some borrowers during the first months |
| Project cost | GBP 1,180,000 (section 9.3) |
| Ongoing cost | Hosting and kiosk maintenance GBP 96,000 a year from year 2 |
| Timescale | 10 months to last branch live, project closed in month 11, benefits measured to month 24 |
| Investment appraisal | [Method and result from the business case] |
| Major risks | Data migration quality, kiosk supply lead times, staff adoption |
| Viability at end of initiation | [Still viable / Viable with conditions / Not viable] |
Full business case: [BC-NNN] (business/business-case).
4. Project organisation
| Role | Name | Responsibilities (summary) | Time commitment |
|---|
| Executive (Example) | [Name] | Owns the business case, chairs the board, final decision maker | 1 day a month |
| Senior user (Example) | [Name] | Represents branches and borrowers, specifies needs, confirms benefits | 2 days a month |
| Senior supplier (Example) | [Name] | Commits supplier resources, accountable for the quality of what is supplied | 1 day a month |
| Project assurance (Example) | [Name] | Independent check on business, user and supplier interests for the board | 2 days a month |
| Change authority (Example) | Project manager up to limits in section 10 | Decides requests for change within delegated limits | As needed |
| Project manager (Example) | [Name] | Day-to-day management within stage tolerances | Full time |
| Team managers (Example) | [Names] | Deliver agreed work packages | Full time |
| Project support (Example) | [Name] | Configuration management, plan and log maintenance | 50% |
Role descriptions: [link to the agreed descriptions]. Responsibility
for each product: business/raci. Stakeholders and their interests:
project/stakeholder-register.
5. Quality management approach
| Item | Approach (Example) |
|---|
| Customer quality expectations | Kiosks work for borrowers with limited sight or mobility; no loss of borrower or loan history |
| Project acceptance criteria | 100% of active borrower records migrated and reconciled; kiosks meet accessibility checks; 95% of test scripts passed with no open severity 1 defects |
| Quality methods | Product descriptions with quality criteria for every major product; peer review of configuration; supplier factory test; user acceptance test per wave |
| Quality records | Quality register maintained by project support |
| Acceptance | Senior user accepts each wave; executive accepts the final product at closure |
| Roles | Quality reviews chaired by team managers; project assurance samples records each stage |
Detailed plan: project/quality-management-plan.
6. Change control approach
| Item | Approach (Example) |
|---|
| Issue types | Request for change, off-specification, problem or concern |
| Procedure | Capture, assess impact on time, cost, quality, scope, benefits and risk, propose, decide, implement |
| Change authority | Project manager: changes up to GBP 5,000 and no milestone move; senior user and executive jointly: up to GBP 25,000; project board: above that |
| Change budget | GBP 30,000 held by the board for approved requests |
| Configuration management | Product baselines and versions recorded in the configuration register; supplier configuration under its own control with monthly status exchange |
| Records | Issue register, change log, daily log for informal issues |
Detailed procedure and forms: project/change-control.
7. Risk management approach
| Item | Approach (Example) |
|---|
| Procedure | Identify, assess, plan responses, implement, communicate; review at every weekly checkpoint |
| Scales | Probability 1 to 5 and impact 1 to 5 on time, cost and service, defined in the risk register |
| Risk tolerance | Any risk scoring 15 or above, or any risk to the support deadline, is escalated to the executive within two working days |
| Risk budget | Included in the plan contingency of GBP 70,000 (section 9.3) |
| Roles | Risk owners named on the board or team; project manager maintains the register |
| Reporting | Top risks in every highlight report; full review at each stage boundary |
| ID | Risk | Probability | Impact | Owner | Response |
|---|
| RSK-01 (Example) | Borrower data quality causes migration rework, delaying wave 1 | 3 | 4 | Senior supplier | Data cleansing sprint before trial migration |
| RSK-02 (Example) | Kiosk lead time exceeds 10 weeks, delaying waves 2 and 3 | 2 | 4 | Senior supplier | Order at end of stage 2, framework supplier as fallback |
| RSK-03 (Example) | Staff resist self-service, low kiosk use | 3 | 3 | Senior user | Branch champions, early involvement in pilot |
| [RSK-NN] | [Risk] | [1 to 5] | [1 to 5] | [Owner] | [Response] |
Register: compliance/risk-register or the RAID log project/raid-log.
For a probabilistic view of schedule and cost risk on a large project,
see project/schedule-risk-analysis.
8. Communication management approach
| Audience | Information | Method | Frequency | Owner |
|---|
| Project board (Example) | Highlight report | Email, board portal | Every two weeks | Project manager |
| Trust leadership team (Example) | Stage summary | Leadership meeting | At each stage boundary | Executive |
| Branch managers (Example) | Rollout schedule, training dates | Briefing call | Monthly, weekly during their wave | Team manager: rollout |
| Branch staff (Example) | What changes, training | Intranet page, drop-in sessions | Monthly | Team manager: training |
| Borrowers (Example) | Kiosk introduction, short closures | Posters, website, newsletter | Four weeks before each wave | Communications officer |
| [Audience] | [Information] | [Method] | [Frequency] | [Owner] |
Full plan: project/communication-plan. Stakeholder analysis:
project/stakeholder-register.
9. Project plan
9.1 Stages and major products
| Stage | Purpose | Major products | Ends with |
|---|
| 1 Initiation (Example) | Plan and baseline | This PID, stage 2 plan | Board authorises stage 2 |
| 2 Design and procurement (Example) | Configure the system, contract kiosks | Configured system (release 1), kiosk contract, data migration design | Board authorises stage 3 |
| 3 Pilot (Example) | Prove in 2 branches | Migrated pilot data, 6 kiosks live, revised procedures | Board authorises stage 4 |
| 4 Rollout (Example) | 12 branches in two waves | 36 kiosks live, trained staff, final migration | Board authorises closure |
| 5 Closure (Example) | Hand over and close | Acceptance, lessons report, end project report | Board closes project |
9.2 Milestones
| ID | Milestone | Baseline date | Owner |
|---|
| MS-01 (Example) | PID approved | Month 1 | Executive |
| MS-02 (Example) | Kiosk contract signed | Month 3 | Senior supplier |
| MS-03 (Example) | Pilot branches live | Month 6 | Senior user |
| MS-04 (Example) | Wave 2 live (6 branches) | Month 8 | Senior user |
| MS-05 (Example) | Wave 3 live (6 branches), old system off | Month 10 | Senior user |
| MS-06 (Example) | Project closed | Month 11 | Executive |
9.3 Budget
| Item | Cost (Example, GBP) |
|---|
| Library management system implementation and first-year hosting | 410,000 |
| 42 kiosks and 14 sets of security gates, installed | 380,000 |
| Data migration and cleansing | 90,000 |
| Internal staff time (project team and backfill) | 160,000 |
| Training and communication | 40,000 |
| Base cost | 1,080,000 |
| Contingency for identified risks (held by the project manager within tolerance) | 70,000 |
| Change budget (held by the board, section 6) | 30,000 |
| Total project budget | 1,180,000 |
Planning assumptions: [resource availability, supplier lead times,
calendar, rates]. Detailed schedule: project/project-schedule.
Resources: project/resource-plan. Work breakdown:
project/work-breakdown-structure.
10. Project controls and tolerances
| Tolerance | Project level (set by corporate) | Stage level (set by the board) | Work package (set by the project manager) |
|---|
| Time (Example) | +4 weeks on MS-05, none on the support deadline | +2 weeks per stage | +5 working days |
| Cost (Example) | +5% of total budget | +8% of stage budget, within project tolerance | +10% of package cost |
| Scope (Example) | Must-have requirements: none | Should-have: may defer up to 3 with senior user consent | As in the work package |
| Quality (Example) | Acceptance criteria in section 5: none | Severity 2 defects open at stage end: up to 5 | As in product descriptions |
| Benefits (Example) | Self-service share at least 60% (target 70%) | n/a | n/a |
| Risk (Example) | No risk with score 20 or above unescalated | Score 15 or above escalated | Report any new risk at checkpoint |
| Control | When | Content | To |
|---|
| Stage boundary review (Example) | End of each stage | End stage report, next stage plan, updated PID | Project board |
| Highlight report (Example) | Every two weeks | Progress against stage plan and tolerances | Project board |
| Checkpoint report (Example) | Weekly | Work package progress | Project manager |
| Exception report (Example) | When a forecast breaches stage tolerance | Cause, options, recommendation | Project board |
| End project report (Example) | Closure | Performance against PID, benefits status | Project board |
Templates: highlight report project/highlight-report, exception
report project/exception-report, end stage report
project/end-stage-report, work package project/work-package,
closure project/project-closure-report, cost and schedule performance
project/earned-value-report.
11. Tailoring
| Element | Standard practice in the organisation | Tailoring for this project | Reason |
|---|
| Stage count (Example) | Initiation plus at least two delivery stages | Initiation, three delivery stages, closure | Rollout waves need board go or no-go decisions |
| Reports (Example) | Monthly highlight report | Every two weeks during stages 3 and 4 | Short waves |
| Configuration delivery (Example) | Predictive work packages | Two-week iterations with a product backlog inside stage 2 | Configuration needs fast user feedback |
| Senior supplier (Example) | Single person | Shared by Head of Digital and the supplier account director | External supplier delivers most of the system |
| Logs (Example) | Separate issue, risk and quality registers | Single RAID log plus quality register | Project size |
| [Element] | [Practice] | [Tailoring] | [Reason] |
12. Benefits management approach
| ID | Benefit | Measure | Baseline | Target | When measured | Accountable |
|---|
| BEN-01 (Example) | Staff time released from routine lending | FTE equivalent from counter time study | 0 | 1.9 FTE | Months 3 and 12 after last wave | Senior user |
| BEN-02 (Example) | Support cost avoided | Annual support cost | GBP 85,000 a year | 0 | Year 1 after closure | Executive |
| BEN-03 (Example) | Self-service use | Share of issues and returns at kiosks | 0% | 70% | Monthly from go-live to month 12 | Senior user |
| [BEN-NN] | [Benefit] | [Measure] | [Baseline] | [Target] | [When] | [Owner] |
Full plan: project/benefits-realization-plan. Post-project review:
project/post-implementation-review.
13. Further approaches
| Approach | Needed | Summary or link |
|---|
| Commercial management (procurement, supplier contracts) (Example) | Yes | Two contracts (system, kiosks), monthly supplier reviews; project/procurement-plan |
| Sustainability (Example) | Yes | Kiosk energy rating criterion in tender; old hardware sent to certified reuse partner |
| Digital and data (Example) | Yes | Borrower data handled under the Trust's data protection policy; data protection impact assessment before trial migration |
| Health and safety (Example) | Yes | Supplier installation method statements approved by facilities before each wave |
| [Approach] | [Yes / No] | [Summary or link] |
14. Initiation exit criteria and authorisation
| Check | Answer (Example) |
|---|
| Business case viable and consistent with the plan costs | Yes, BC v1.1 matches section 9.3 |
| Every role in section 4 filled by a named person who has agreed | Yes |
| Tolerances set at every level | Yes, section 10 |
| Next stage plan ready for approval | Yes, stage 2 plan v1.0 |
| Top risks owned with responses | Yes, section 7 |
| Approaches agreed by the people who must apply them | Yes, team managers and supplier signed off |
| Tailoring recorded | Yes, section 11 |
| Decision | Detail |
|---|
| Project board decision | [Approve PID and authorise stage 2 / Approve with conditions / Ask for changes / Close the project] |
| Conditions | [Conditions, owners, dates] |
| Stage 2 budget and tolerance released | [Amount, tolerance] |
| Signed | [Executive], YYYY-MM-DD |
15. Glossary and references
| Term | Meaning in this document |
|---|
| Project board | The group with authority to direct the project: executive, senior user, senior supplier |
| Executive | Board member accountable for the business case and the project's success |
| Senior user | Board member representing those who will use the products and realise the benefits |
| Senior supplier | Board member representing those who design and build the products |
| Stage | A section of the project the board authorises one at a time |
| Tolerance | Permitted deviation from a plan target before escalation |
| Product description | Specification of a product with its quality criteria and acceptance method |
| Change authority | Person or group delegated to decide requests for change within limits |
| Tailoring | Adapting the method to the project's context, recorded with reasons |
| Reference | Title | Use |
|---|
| [Doc ID] | Project brief or charter (project/project-brief, project/project-charter) | Input to initiation |
| BC-NNN | Business case (business/business-case) | Section 3 |
| [Doc ID] | Project management plan (project/project-management-plan) | Alternative format for organisations that use a single plan document |
| [Doc ID] | RAID log (project/raid-log) | Section 7 |
| [Doc ID] | Communication plan (project/communication-plan) | Section 8 |
| [Doc ID] | Kickoff meeting (meetings/kickoff) | Start of stage 2 |
| PRINCE2 7 | Managing Successful Projects with PRINCE2, 7th edition (PeopleCert) | Structure aligned only (cited) |
| ISO 21502:2020 | Project, programme and portfolio management, guidance on project management | Clause 6.5 initiating a project (cited only) |
Standard and licence note
Structure aligned with the project initiation documentation of PRINCE2
7 (Managing Successful Projects with PRINCE2, 7th edition, PeopleCert;
the current version of the method, launched in 2023) and with ISO
21502:2020, Project, programme and portfolio management: Guidance on
project management (first edition, December 2020, currently under
revision), clause 6.5 (initiating a project). This template is original
text written for this collection. It uses generic role and product names
and reproduces no text, tables, figures or product descriptions from
either publication. The section order follows common practice for an
initiation document and is not a copy of the method's product outline.
PRINCE2 is a registered trademark of the PeopleCert group; this template
is not endorsed by or affiliated with PeopleCert, and the name is used
only to identify the source. Check the current editions before relying
on them.