What is a project initiation document (PID)?

A PID is the agreement between the people funding a project and the person running it. It states what will be delivered, by whom, how it will be controlled, and within what limits of time and cost. Once approved it becomes the baseline: the version of the plan that later performance is measured against.

What is the difference between a project brief and a PID?

The project brief is written before approval, and contains just enough to decide whether the project is worth starting. The PID is written after the decision to go ahead, is fuller, and becomes the baseline the project is controlled against. The brief asks 'should we do this?'; the PID answers 'here is exactly how, and here are the limits I am working within.'

How long should a PID be?

As long as it needs to be and no longer. Tailoring means shrinking the paperwork, not the thinking: a small project can answer every section in a paragraph. A PID nobody reads controls nothing, so length is a risk, not a virtue.

Does the PID get updated during the project?

The approved PID is a baseline and should be preserved — the whole point is to compare where you are against what was agreed. Change it only through an agreed change or re-baselining decision, and keep the original. If you quietly overwrite the plan every time it slips, you destroy the only evidence of variance you had.

Home · Templates · PID

Project Initiation Document (PID) template

A free, editable Word template for the document that turns an approved idea into a controlled project — with an explanation of what each section is actually for, and how to tailor it down without quietly losing control.

PID template — Word (.docx)

Stage plan and organisation tables, quality, risk and communication approaches, controls and tolerances, with guidance notes in every section. No email wall.

Download the template

What a PID is really for

Strip away the formality and a PID is a contract between the people paying for a project and the person running it. It answers four questions, and everything in it serves one of them:

What are we getting? — objectives, scope, and pointedly what is out of scope.
Who is accountable? — named people, not job titles with nobody in them.
How will it be run? — stages, and how risk, quality and change get handled.
When do I need to be told? — tolerances. The most important section, and the one most often left blank.

Approval is the moment that matters. Before it, the PID is a proposal. After it, it is a baseline — the agreed version that everything later gets measured against.

Brief or PID? The distinction people get wrong

Project brief	PID
Written before the decision to go ahead.	Written after it, once you are committed.
Answers: should we do this at all?	Answers: here is exactly how, and the limits I will work within.
Enough detail to decide. Deliberately thin.	Enough detail to control. The baseline.
Outline business case.	Full business case, plus how benefits will be measured and by whom.

The practical consequence: you cannot write a good PID from a bad brief. If nobody ever decided what problem this project solves, no amount of tabulation at initiation stage will supply it. Start with the brief if you are earlier than you think you are.

Section by section

1. Project definition

Background, objectives, deliverables, and — the part that earns its place — what is explicitly out of scope. An in-scope list is a wish. An out-of-scope list is a decision, and it is the only thing that will protect you in month three when someone says "I just assumed that was included."

2. Business case

Why this is worth doing, in money and in benefit. Summarised here, held in full in the business case. It is not a formality: it is the thing the board returns to at every stage boundary to ask "is this still worth finishing?"

3. Project organisation

Who decides, who uses, who supplies, who runs it day to day. Named people. A role with nobody in it is not a role, it is a gap you have written down and stopped worrying about.

Role	The question they answer
Executive	Is this still worth the money? Owns the business case; has the final say.
Senior user	Will the people who have to live with this actually use it? Speaks for them.
Senior supplier	Can it actually be built as described, with the resources we have?
Project manager	Is it on track, and if not, do I need to escalate?

4. The plan — in stages

Break the work into stages that end at a decision point, not at a convenient date. The end of a stage is where the board gets to ask "carry on, change, or stop?" — so a stage boundary should fall where that question is genuinely worth asking. Each stage carries its own dates and its own budget.

5. Controls and tolerances

This is the section that makes a PID a governance document rather than a description, and it is routinely left as a blank table.

A tolerance is permission. It says: within these limits, get on with it — don't ask me. Outside them, stop and tell me. Without it, a project manager has to escalate everything or nothing, and both are failures.

Worked example. Stage 2 is planned at 6 weeks and £14,000, with tolerance +2 weeks / +£1,500. Forecast to finish 8 days late and £900 over? Inside tolerance — the PM absorbs it and carries on. Forecast 3 weeks late? That is an exception: stop, tell the board, and let them decide. Nobody is in trouble; the system worked exactly as designed.

6. Risk, quality and change approaches

Not the risks themselves — how you will handle them. Who scores risks and against what scale (see the risk register); what "done" means and who gets to say so; and who is allowed to approve a change, and up to what value. Answer the change question at initiation and you will avoid the most common source of project conflict — a scope change approved by someone who had no authority to approve it.

7. Communication

Who needs to know what, how often, in what form. One table. It takes ten minutes and prevents the most tedious category of project failure: the one where everything was fine and nobody was told.

Tailoring: how small can a PID be?

Very. Tailoring means shrinking the paperwork, not the thinking. A PID nobody reads controls nothing, so length is a risk rather than a virtue.

On a small project you can legitimately answer several sections in a single paragraph, fold the business case into the definition, and run two stages instead of six. What you may not drop, at any size:

Named people against the four roles.
Explicit out-of-scope.
Tolerances, and what happens when they are breached.

Everything else is negotiable. Those three are the governance.

Why PIDs fail

Written to be approved, not used. Forty pages that satisfy a gate and are never opened again. The tell: nobody can say what the tolerances are without looking.
Tolerances left blank. So every slip is either hidden or escalated, and the board learns about problems too late to do anything but be angry.
Roles as job titles. "Executive: Finance" is not a person and will not make a decision.
Quietly overwritten when it slips. This one is subtle and it is fatal. The approved PID is your baseline — the evidence of what was agreed. Rewrite the dates every time reality diverges and you destroy the only record of variance you had. Re-baseline deliberately, with the board, and keep the original.

A template is a snapshot. A project moves.

The moment you approve a PID it starts going stale. In Guddle the PID is a living view of the project — plan, organisation, risk and quality approaches, all current — exportable to a branded PDF whenever someone asks for "the document", with tolerance breaches raised as exceptions automatically rather than discovered at the stage boundary.

Start free — first project on us

Or paste a plain-English brief and Guddle drafts the stages, budget, risks, roles and business case for you to review.

The other templates

Project briefComes before the PID Business caseThe justification, in full Risk registerWith 5×5 scoring built in

Common questions

Who approves the PID?

The project board — in practice, whoever is funding the work and whoever has to live with the result. Approval turns a proposal into a baseline, and it is also the moment the board accepts the tolerances inside which you may act without asking them again.

Does the PID get updated as the project runs?

Only deliberately. It is a baseline; change it through an agreed change or a conscious re-baselining, and preserve the original either way. Silent updates feel tidy and cost you the ability to prove anything.

Is this an official PRINCE2 template?

No. It is an independent template written from scratch, aligned with the method's approach to initiation. It is not affiliated with, endorsed by, or copied from PeopleCert or AXELOS materials.