PMO: SOPs
Six procedures for a predicting PMO: baselining, the daily risk review, the intervention protocol, dependency acknowledgement, commitment capture and re-baselining discipline.
Markdown. No sign-up, no email.
Prediction is worthless without a procedure for acting on it. These six exist so a forecast turns into a decision rather than into a slide.
SOP 1: Baseline at kickoff#
Run: once per project, before work starts.
Record scope, date, budget and the named accountable person. Freeze it. Every later measurement is against this, not against the most recent plan.
A project without a frozen baseline cannot be late, which sounds convenient and is exactly the problem: it also cannot be learned from.
SOP 2: Daily risk review#
Run: daily, ten minutes, by the project manager.
The prediction refreshes overnight. The manager reads only what changed:
- Anything newly HIGH, and why the engine says so.
- Anything that moved two levels in one day. That is usually a data problem, not a project problem, and it is worth knowing which.
- Commitments now at risk.
Ten minutes, not an hour. If the review takes longer, the engine is flagging too much and the false-alarm rate needs attention before the projects do.
SOP 3: Intervention protocol#
Run: whenever a risk goes HIGH.
A flag with no action is a report. Within one working day, one of four things is recorded:
| Response | Meaning |
|---|---|
| Act | Something changes: scope, sequence, resource, or the date |
| Accept | The risk is real and we are taking it, with a named accepter and a date |
| Escalate | Beyond this project's authority |
| Reject | The prediction is wrong, and why. This feeds back into the engine |
Rejecting is a legitimate response and must stay easy. A manager who cannot say "the model is wrong here" will instead stop reading it.
SOP 4: Dependency acknowledgement#
Run: on every cross-project dependency.
The team depended upon must acknowledge it in writing. An unacknowledged dependency is not a dependency, it is an assumption, and assumptions fail on the date they were needed.
Reviewed weekly at portfolio level. Anything unacknowledged for a week escalates.
SOP 5: Commitment capture#
Run: after any client conversation.
Anything promised gets recorded the same day: what, to whom, by when. A commitment that lives only in a call is a commitment only one side is tracking, and the other side is tracking it perfectly.
SOP 6: Re-baselining#
Run: only with authority, never quietly.
Re-baselining is sometimes correct. Doing it invisibly is never correct, because it erases the evidence that the original estimate was wrong, which is the only thing that improves the next one.
- State why the original is no longer achievable.
- Name who authorised the change.
- Keep the original. Both are reported from then on: performance against original, and against current.
A project re-baselined more than twice is not a project with a scheduling problem. It is a project with a scoping problem, and rescheduling it again will not help.
Escalation#
| Situation | Goes to |
|---|---|
| Predicted delay affects a contracted client date | COO, same day, before the client hears it elsewhere |
| A person is on the critical path of more than two projects | Resource review. This is a structural risk, not a project one |
| Budget variance beyond 15% | Finance and the CEO |
| A dependency unacknowledged for a week | The other project's manager, then their chief |