ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A project initiation document is the artefact that turns an approved idea into a
project with a baseline. It is also the document most often written badly — assembled the week
before delivery starts, signed by people who have not read it, and never referred to again. Done
properly it is the single most useful thing a project manager produces, because everything that
follows is measured against it.
The PID is PRINCE2’s term. It is a composite document, assembled at the end of initiation, that
brings together everything agreed about the project so it can be authorised and later controlled
against. It is not a plan, and it is not a business case — it contains both, alongside the
governance and control arrangements that make them enforceable.
The distinction that confuses newcomers is between the PID and the project charter.
They serve the same purpose and come from different traditions. PMI’s PMBOK Guide works with
a charter that authorises the project and appoints the project manager; PRINCE2 assembles a fuller
PID as the baseline. Both are the answer to the same question: what did we agree, and who agreed it?
Whichever term your organisation uses, the failure mode is identical. A project without an agreed
baseline cannot demonstrate scope creep, because there is nothing to have crept from.
Contents vary by method and by organisation, but a PID that actually works as a control document
covers this ground.
| Section | The question it settles |
|---|---|
| Background and objectives | Why are we doing this, and what does done look like? |
| Business case | What is the investment, and what returns justify it? |
| Scope and exclusions | What is in, and — more usefully — what is explicitly out? |
| Deliverables and acceptance criteria | What will be handed over, and how will it be judged acceptable? |
| Organisation and roles | Who decides what, and who is accountable when it goes wrong? |
| Schedule and milestones | What is the baseline you will be measured against? |
| Budget and tolerances | How much, and how far can it move before somebody must be told? |
| Risks, assumptions, issues, dependencies | What could derail it, and what are we taking on trust? |
| Controls and reporting | Who is told what, how often, and what triggers escalation? |
Two of those rows do most of the work. Exclusions prevent more disputes than any
other paragraph in the document, because they make the boundary explicit rather than implied. And
tolerances are what stop the project manager escalating everything or nothing —
a stated variance in time and cost that can be absorbed without a board decision.
Acceptance criteria. It is genuinely hard to write down how a deliverable will be judged before it
exists, so teams write “fit for purpose” and move on. Then at handover the customer
applies criteria nobody agreed and the project cannot prove it delivered. If you write only one
section of the project initiation document carefully, write this one.
If you need an authority to point at, ISO 21502:2020
is the international guidance standard for project management — a 52-page first edition
published in December 2020 by ISO/TC 258, currently at the review stage, which replaced the withdrawn
ISO 21500:2012. It is deliberately method-neutral, so it describes the practices without mandating
PRINCE2’s artefacts or PMI’s.
On the method side, the PMBOK Guide
moved to its Eighth Edition in November 2025, built on six core principles and seven
performance domains, with expanded coverage of AI, PMOs and procurement. PRINCE2 7
has been available worldwide since 4 September 2023 and is structured as seven principles, seven
practices and seven processes, with people added as a fifth integrated element and sustainability
raised to a performance target alongside time, cost, risk, benefits, scope and quality.
Thirty initiation templates, including the PID and the one-pager.
The Project Management Toolkit ships 390+ editable MS Office templates. Initiation alone covers the project initiation documentation template and a worked sample, a PID-on-a-page deck, project brief, project charter, business case, options analysis, initiation checklist, kick-off agendas and a success criteria sheet — so the document is a fill-in rather than a blank page.
Teams routinely collapse these into one file and then cannot answer basic questions from it. They
are sequential, and each has a distinct decision attached.
The project brief comes first and is deliberately thin. It exists to get agreement
that the project is worth initiating at all — the outline of the problem, a rough shape of the
solution, and enough sizing to decide whether to spend money working it up. If a brief takes three
weeks to write, it is not a brief.
The business case carries the investment argument: options considered, costs,
benefits, timescales, and the recommendation with its reasoning. It is a living document, not a
one-off — when the numbers move, it should be revisited, and a project whose business case no
longer stands up should stop.
The project initiation document then wraps the approved business case together
with the plan, the governance and the controls into the baseline the project is run against. That is
why it comes last and why it contains the other two rather than replacing them.
The practical consequence: if somebody asks “why are we doing this?” the answer is in
the business case; “what did we agree to deliver?” is in the PID. Keeping them separable
inside the document, even when bound together, is what makes both questions answerable a year later.
Counter-intuitively, drafting the summary before the full document produces a better document. If
you cannot state the objective, the scope boundary, the key dates, the budget and the top three risks
on one page, the thinking is not finished — and forty pages will hide that rather than fix it.
It also means that when the sponsor asks for “just the headlines” the day before the
board, you already have them.
Every one of those makes the same underlying mistake: treating the PID as a deliverable to be
produced rather than a control to be used. The test is simple — if nobody has opened it since
authorisation, it is not doing its job.
Is a project initiation document the same as a project charter?
They serve the same purpose from different traditions. The PID is PRINCE2’s composite baseline
document; the charter is PMI’s authorising document. Use whichever your organisation recognises, but
do not maintain both.
How long should a PID be?
As long as the project’s risk justifies, and no longer. A small internal project may need six pages;
a regulated programme may need sixty. Always produce a one-page summary regardless.
Who signs it?
The sponsor or project board, as the body authorising the spend. It is worth also getting explicit
agreement from whoever will receive the deliverables, because they are the ones who will apply the
acceptance criteria.
Can the project initiation document change?
Yes, through change control. That is what makes it a baseline rather than a wish list. Uncontrolled
edits defeat the purpose.
Do agile projects need one?
They need the same decisions recorded — objectives, scope boundary, roles, tolerances,
acceptance — even where delivery is iterative. What changes is the level of up-front detail in
the plan, not whether the project is authorised against something.
All of these are covered by the Project Management Toolkit, or start with the free ISO templates.
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026