Everything a One-Page Project Plan Actually Needs

Most project plans we inherit run between eight and twenty pages. Almost none of them answer the six questions that decide whether the project lands on its date. That is the argument here: the page limit is not a style preference, it is a forcing function. A plan that cannot fit on one page has usually not been decided yet, only described.

What is a one page project plan?

A one page project plan is the shortest written document that still carries every commitment the project cannot run without. It is not a summary of something longer. There is nothing behind it.

The working definition we use with clients: a one page project plan names the outcome, the owner, the dates, the decisions, the risks and the exclusions, in language anyone on the project can check against reality in under two minutes.

That last clause does the work. A plan you cannot check is a plan nobody argues with, and a plan nobody argues with is a plan nobody is bound by. Three things it is not. Not a status report, which looks backwards. Not a schedule, which lists tasks rather than commitments. Not an executive summary, which exists to be read once and filed.

In practice the page is six headings with a few lines under each. Printed, it fits on a sheet. On screen, it does not scroll. Both tests are deliberate.

The page limit is the mechanism rather than the point. On one page every field competes for space with every other field, so you are forced to decide what the project actually depends on. A fourteen page plan never makes you choose. It can carry every commitment and still hide which ones matter, because nothing had to earn its line.

We run delivery for founder led SMEs across APAC and Australia. The plans we inherit are almost never too short. They are long, detailed, and silent on the few things that decide the date.

Why do long plans deliver worse than short ones?

Because length hides the absence of commitment, and delivery fails on missing commitments rather than missing detail.

The numbers have not improved in the way a decade of better project software would predict. PMI's Pulse of the Profession 2021: Beyond Agility found 58 percent of projects completed on time, 33 percent experiencing scope creep, and 12 percent deemed outright failures. Closer to our market, the KPMG and AIPM Project Management Survey 2020: Project Delivery Performance in Australia, covering 464 Australian respondents, puts it lower again: 48 percent of projects likely to be delivered on time, 42 percent on budget, and 51 percent likely to meet the original goal and business intent. Two years before that, PMI's Pulse of the Profession 2018, the 10th Global Project Management Survey, found 52 percent of projects completed in the previous twelve months had experienced scope creep, and that when a project fails, 32 percent of its budget goes with it. That same survey put the running waste at 9.9 percent of every dollar spent on projects, which PMI then scaled to roughly USD 1 million lost every 20 seconds worldwide. The global figure is a headline. The 9.9 percent is the one to apply to your own project budget this quarter.

Read those four failure modes again. Late. Over budget. Off intent. Scope that grew. Not one of them is caused by insufficient documentation.

Scope creep is not a documentation gap. It is the absence of a written exclusion and the absence of a price on every yes. A missed date is not a planning gap. It is a date that no single person owned. Drift off the original intent is not a detail problem. It is an outcome nobody could verify, so nobody noticed the direction change until it was expensive.

One figure from the Australian survey is worth sitting with. 61 percent of projects had actively engaged sponsors, and the report flags a strong correlation between sponsor engagement and delivery success. Sponsorship is a person, not a paragraph. You cannot document your way to it, and no quantity of extra plan pages substitutes for a name.

What six fields does a one page plan have to carry?

Six, and we call them the Delivery Spine, because every one of them is load bearing. Remove a single field and the page stops holding the project up.

The order matters, because each field answers a question the previous one creates. The outcome tells you what finished looks like, which raises the question of who is accountable for reaching it. Ownership raises the question of what you can show along the way. Visible milestones raise the question of what you have agreed not to do. Exclusions raise the question of who adjudicates the next request. The decision path raises the question of what could stop you anyway.

Exhibit 1: The Delivery Spine, six fields and the question each one answers

Field	The question it answers	What a hollow version looks like
1. Outcome	What is true at the end that is not true now?	"Improve client onboarding." No end state anyone can mark true or false.
2. Owner, date and budget	Who personally owns the end date and the spend?	A function, a committee or a vendor. Nobody can say the name in three seconds.
3. Shipping line	What can we demonstrate, and when?	Phases and workstreams. Nothing a sceptic could inspect on a Friday.
4. Exclusions	What are we explicitly not doing?	Blank. Every new request arrives free of charge.
5. Decision path	Who decides what, and inside how long?	"Escalate to steering." Steering meets fortnightly.
6. Top three risks	What would most likely stop us, and who acts?	A twelve row register with no owners and no triggers.

Two of the six are worth a sentence beyond the table. The outcome field fails most often by being written as an activity. "Migrate the client onboarding process" is an activity. "A new client is live and invoiced within five working days of signature, with no founder touching the file" is an outcome, because somebody can check it and say no. The exclusions field fails by being left empty out of politeness. There is nothing impolite about writing "this project does not touch the pricing model or the CRM". It is the one field that lets you say yes to the next request with a number attached to it.

The sixth field is standard practice almost everywhere. The fifth is the one almost nobody writes down, and it is the field we find missing most often when we take over a stalled project. "Escalate to the steering committee" is not a decision path when the steering committee meets fortnightly. That one sentence is how a project loses a month without a single person making a mistake.

What does one missing field actually cost?

Enough to fund the operator who would have written it. Here is the arithmetic on one missing field, the decision path. The company below is illustrative and not a client. The assumptions are stated so you can substitute your own.

Assume a Singapore based B2B services firm: 70 people, USD 14M revenue, USD 1.6M operating profit. It is opening an Australian office. The project runs 22 weeks with 9 people attached. The plan is fourteen pages and carries an outcome, a schedule, a risk register and a budget. It has no decision path, so every question the team cannot answer itself queues for the fortnightly steering meeting.

Assume the team raises 4 such questions a week. Assume the median wait from question to answer is 6 working days, of which 2 days is the honest time needed to decide and 4 days is pure queue. Assume each blocked question stalls half a person rather than a whole one, because people find other work while they wait.

4 questions a week x 4 avoidable queue days x 22 weeks = 352 days of avoidable waiting. At half a person each, that is 176 person days. At a fully loaded USD 310 per person day, that is USD 54,560.

Call it USD 55k of capacity, against USD 1.6M of operating profit. Roughly 3.4 percent, and it shows up on no report, because it looks like people being busy.

The schedule cost is larger and harder to see. If one in ten of those 352 queue days falls on the critical path, the Australian launch moves 35 working days, or seven weeks, on a 22 week project. Illustrative, using the assumptions stated above.

Now price the fix. It is one line on the page. Decisions under USD 20,000 and inside agreed scope are called by the project owner within 48 hours and logged. Anything above that threshold goes to the sponsor, who answers inside three working days. Writing that sentence costs nothing. Not writing it cost seven weeks and 3.4 percent of operating profit.

The same page has a second field worth pricing. Assume the project absorbs 6 unbudgeted requests across the 22 weeks, each averaging 3 person days of work, because there was no written exclusion to point at and no change process to route them through. 6 requests x 3 person days = 18 person days, or USD 5,580 of direct effort at the same day rate. The direct cost is small. The compounding cost is that all 18 days came out of critical path work, and that the team learned requests are free. PMI found 52 percent of projects experience scope creep. This is the mechanism, one polite yes at a time.

What do you do on Monday?

Write the page yourself, before you ask anyone to review it. Forty minutes, six headings, one page.

1. Write the outcome as a sentence a sceptic could mark true or false in six months. If it needs two sentences, you have two projects.

2. Put one name against the date and one name against the budget. If the same name appears twice, check that the person holds the authority and not only the job title.

3. List the milestones you could demonstrate rather than report. "Pricing signed off by the Australian GM" is a demonstration. "Phase 2 complete" is not.

4. Write three things the project is not doing. This is the hardest field and the one that pays back fastest. Write them as sentences and not as labels. "We are not migrating historical client data" beats "data migration: out of scope", because the sentence is harder to reinterpret in month four.

5. Write the decision path with a clock on it. Who decides below the threshold, inside how long, and who decides above it.

6. Name the three risks most likely to stop you, each with one owner and one trigger. Three, not twelve.

Then test it. Hand the page to someone who is not on the project and ask two questions: who owns the date, and what is out of scope. If they cannot answer both inside two minutes, the page is not finished. This is not a proofreading exercise. A reader who cannot find the owner is telling you the project does not have one.

After that, keep it alive. By week ten, the dates and the risks on a working page should look different from week one. The outcome and the exclusions should look identical. If they do not, someone changed the project without telling anyone, and the page is short enough that you can see it happen.

If you would rather have a senior operator run the delivery than hand you a plan to run yourself, that is what we do. You can read how our Fractional PM engagements work at rem-up.com, or book a 30 minute call and we will walk your current plan against the six fields while we talk.

Innovate. Optimize. Grow.