How to Create a Project Plan That Survives Contact

Search for this and you will be handed templates — thirty-field documents with sections for governance, communication strategy and stakeholder matrices. They get filled in once, sent round for approval, and never opened again.

That is not a planning failure. It is a misunderstanding of what a plan is for. A plan is an instrument for making decisions later. Its value is realised in week five, when something has gone wrong and you need to know what that costs and what moves. A document that cannot help you in that moment was never a plan, whatever it was called.

Which means a useful plan is much shorter than the templates suggest, and answers six questions.

1. What does done look like?

Written specifically enough that two people could independently agree whether it has happened.

"Redesign the website" is not a definition of done. "Every page on the new template, the old CMS switched off, and the team able to publish without us" is — because on the last day somebody can check each clause.

Then, in the same breath and more importantly: what is deliberately not in scope. Write it down. This is the single cheapest thing in project management and it prevents the most expensive argument, the one that starts "I assumed that was included."

A plan with an explicit out-of-scope list is worth more than one with a beautiful schedule.

2. What has to happen, in what order?

Not a list of tasks. A list of the things that cannot start until something else finishes.

Most work in a project is not sequenced at all — it can happen whenever someone has time. The sequenced part is usually small, often four or five links, and it is the entire reason planning exists. Copy cannot be written until the structure is agreed. Testing cannot start until the build is deployed. The launch email cannot go until legal has signed off.

Write only that chain. It is your critical path, and it tells you the one thing you most need to know: which delays matter and which do not. A task slipping three days on the chain moves your end date. A task slipping three days off it costs nothing, and treating those two the same is how teams exhaust themselves chasing irrelevant delays.

3. Who owns each part?

One name per piece of work. Not a team, not two people, not "marketing".

Shared ownership is the most reliable way to make something not happen, because everyone involved has a defensible reason to believe someone else was handling it. This is not about blame — it is about there being a single person who notices when the thing is drifting.

Where a piece genuinely needs several people, name the one who is accountable for it being finished and list the others as contributors. The distinction feels bureaucratic and takes ten seconds, and it converts "we thought you had it" into a question with an answer.

4. What could sink this?

Three to five things, honestly stated, each with what you would do about it.

Most risk registers are theatre — long lists of generic risks with a colour-coded likelihood nobody derived from anything. Useful risk identification is narrower and more specific: what is the thing that, if it goes wrong, means this project fails rather than slips?

Usually it is one of four. A dependency on someone outside your control. A piece of work nobody on the team has done before. A person whose absence would stop everything. A decision that has not been made yet and is being treated as if it had.

That last one is worth searching for deliberately. Projects far more often fail on unmade decisions than on unforeseen events.

5. Which of scope, time and cost is actually fixed?

Something has to give when reality arrives, and the plan should say in advance what it will be.

If the date is fixed — an event, a season, a regulatory deadline — then scope is the variable, and you should know now which parts you would drop. Decide the drop order while you are calm. You will not be calm in week seven.

If the scope is fixed — a compliance requirement, a contract — then the date is the variable and you should stop pretending otherwise the moment it becomes clear.

If both are fixed, you have a cost problem, and the honest response is to say so at the start rather than to discover it through overtime.

Getting this on paper before work starts is the highest-leverage thing in this whole guide. It converts a future crisis into a decision that has already been made.

6. When will you look at this again?

A date. In the calendar. With whoever needs to be there.

A plan nobody reopens is a document, and documents do not manage anything. Fortnightly is right for most projects; weekly if the whole thing is under two months.

The review has three questions and takes fifteen minutes: has anything on the critical path moved, has any risk become real, and does the definition of done still describe what we are building?

Estimating, briefly and honestly

Split the work in two, because the halves behave completely differently.

Work you have done before can be estimated from experience, and your estimates will be roughly right. Use what it took last time, not what you hope it will take.

Work nobody on the team has done before cannot be estimated meaningfully, and pretending otherwise is where schedules break. Do not put a number on it. Timebox it instead: allocate two weeks to find out how hard it is, and re-plan afterwards with the answer. A plan that admits it does not know something yet is more credible, not less.

Then add contingency openly rather than by padding individual tasks. Padding hides where the uncertainty is; a visible contingency line lets you spend it deliberately.

The whole plan, on a page

• Done means: two or three specific, checkable clauses.
• Not doing: the explicit out-of-scope list.
• The chain: the four or five things that must happen in order.
• Owners: one name against each part.
• Risks: three to five, each with a response.
• Fixed: which of scope, time or cost cannot move, and what gives instead.
• Review: the recurring date.

If that fits on a page, you have a better plan than most twenty-page documents, because every line of it is a decision rather than a description.

Where software fits

Not at the start. Write the page first — in a shared document, in a meeting, on a whiteboard. Tools are excellent at holding a plan and poor at helping you make one, and starting in the tool tends to produce a task list rather than a set of decisions.

Software earns its place when the chain in step two is long enough that keeping the dates consistent by hand becomes its own job. That is what dependency tracking is for, and it is the main reason to pay for a tool like Asana rather than run a board. If your work has no real chain, a board is genuinely sufficient and cheaper — that comparison is here.

For projects that are continuous rather than discrete — support, maintenance, a stream of client requests — a plan is the wrong instrument entirely and flow-based methods are what you want. And when you do need a tool, the shortlist with current pricing is in the best project management software for small teams.