PMO: Templates
Four working templates: the project baseline, the daily prediction card, the intervention record and the dependency acknowledgement.
Markdown. No sign-up, no email.
Four documents, each short by design. A PMO template long enough to feel thorough is one that gets filled in once at kickoff and never again.
1. Project baseline#
Completed once, at kickoff, then frozen.
| Field | Entry |
|---|---|
| Project | |
| Accountable | [One name. Not a team] |
| Scope, in one paragraph | [What is included. Then, separately, what is explicitly not] |
| Out of scope | [The row that prevents the argument in month three] |
| Baseline date | |
| Baseline budget | |
| Success measure | [How we will know it worked, stated so it can be checked] |
| Key dependencies | [With the owning team named, and acknowledged separately] |
| Frozen on | [Date. Not adjusted. Re-baselining is a separate, authorised act] |
2. Daily prediction card#
Generated, not written. Shown here so the shape is agreed and every field carries its basis.
| Project | Project X |
| Complete | 72% (by delivered scope, not tasks closed) |
| Schedule risk | HIGH because 3 of the last 5 milestones slipped and the remaining critical work sits with one person |
| Resource risk | MEDIUM because that person is also on the critical path of one other project |
| Budget variance | +8% driven by contractor hours in weeks 4 to 6 |
| Critical dependency | API integration, owed by another team, acknowledged 12 days ago |
| Predicted delay | 6 days at current throughput |
| Changed since yesterday | [Only this is read on a normal day] |
No risk level ships without its reason. "Schedule risk HIGH" is unactionable on its own, and a level nobody can interrogate is one people learn to scroll past.
3. Intervention record#
One per HIGH risk. Completed within one working day.
| Field | Entry |
|---|---|
| Risk | |
| Raised on | |
| Response | [Act / Accept / Escalate / Reject] |
| If Act | [What changed: scope, sequence, resource or date] |
| If Accept | [Who accepted, and the date it is revisited] |
| If Escalate | [To whom] |
| If Reject | [Why the prediction is wrong. This feeds the engine and must stay easy to say] |
| Decided by | |
| Effect, measured at +14 days | [Did the risk clear, hold, or materialise? This row is the one that gets skipped, and it is the only row that tells you whether interventions work] |
4. Dependency acknowledgement#
| Field | Entry |
|---|---|
| Depending project | |
| Depended-upon team | |
| What is needed | [Specifically. "The API" is not a dependency; "the v2 auth endpoint returning scopes" is] |
| Needed by | |
| Acknowledged by | [A name from the other team. Unacknowledged means it does not exist] |
| Acknowledged on | |
| Fallback if late | [What we do instead. Most dependencies have no answer here, which is itself the finding] |
Using these together#
The charter sets out what the PMO owns, the SOPs say when each is produced, the KPIs define what the intervention record feeds, and the workflows name who receives each output. A baseline filled in without the re-baselining discipline behind it is a document that quietly becomes fiction.