The Planning Phase
Planning is not an attempt to predict the future. It is the act of making your assumptions explicit enough that reality can contradict them early — which is the only reason a plan is worth writing down.
In short
- Planning turns an approved idea into something you can be measured against: scope, schedule, people, cost, risks.
- Estimates are built from the bottom up and summed. A number decided first and divided downward is a target, not an estimate.
- The plan’s value is mostly in the disagreements it surfaces while they are still cheap.
- Stop planning when further detail stops changing any decision — not when the document looks complete.
What the phase actually produces
Initiation left you with a purpose, a sponsor and an order of magnitude. Planning converts that into six things. Not all six need to be documents — on a small project several of them are a single shared list — but all six need answers.
| Output | The question it settles | Covered in |
|---|---|---|
| Scope | What are we producing — and pointedly, what are we not? | 3.1 Defining Project Scope |
| Work breakdown | What are the pieces, small enough to estimate honestly? | WBS in the glossary |
| Schedule | In what order, by when, and what can’t slip? | 3.2 Creating a Project Schedule |
| Resources | Who does it, how much of their time do we really have? | 3.3 Resource Allocation |
| Risks | What could go wrong, and what would we do about it? | 3.4 Risk Management |
| Communication | Who needs to know what, how often, in what form? | 4.3 Communication Planning |
Together these form the baseline: the agreed version of the plan that actual progress is compared against later. Without one, “on track” is a mood.
Estimates are built upward
This is the single most consequential habit in the phase, so it’s worth being blunt about it. There are two ways to arrive at “this project takes 42 days”:
- Bottom-up. Break the deliverable into pieces small enough that someone who would do the work can estimate them, then add them up. The total is a consequence.
- Top-down. Start with the date somebody wants, then divide the work to fit. The total is an input.
Only the first is an estimate. The second is a target — which is a legitimate thing to have, but it must be labelled as one, because it carries no information about whether the work fits.
How small is small enough? A common rule is that no task should be longer than about two weeks, and ideally a few days. Not because short tasks are virtuous, but because a three-week task reports “in progress” for three weeks and tells you nothing, whereas five three-day tasks tell you on day four that something is wrong.
Order matters more than duration
Once you have pieces and estimates, the schedule comes from putting them in order and finding which chain is longest. That chain is the critical path, and it’s the only part of the plan where a one-day slip costs a project day. Everything else has float.
This is why “we’re 60% done” is such a weak statement. Sixty percent of the tasks, or sixty percent of the critical path? The two can differ by months. 3.2 Creating a Project Schedule walks through calculating this properly.
What the plan is really for
Three uses, in descending order of how often people notice them:
A baseline to measure against
The obvious one. Progress is meaningless without something to compare it to, and re-planning is only visible if there was a previous version.
A shared picture
Six people with the same mental model coordinate themselves. The plan is how that model gets synchronised without a meeting for every handoff.
A disagreement detector
The most valuable and least celebrated. Writing the plan is when you find out that two people meant different things — while it still costs a conversation.
That third use explains something otherwise puzzling: teams whose plan turned out to be wrong still, on average, do better than teams who didn’t plan. The plan was never the point. The argument you had while writing it was.
When to stop planning
Planning has a clear point of diminishing returns, and it arrives earlier than most plan documents suggest. Some signals you’ve passed it:
- The next level of detail wouldn’t change a decision. If knowing whether task 14 takes three or four days doesn’t change what you do next, stop estimating it.
- You’re planning work six months out at the same detail as next week. Distant work is genuinely less knowable; planning it precisely produces false confidence, not information. Plan the near term in detail and the far term in blocks — this is called rolling wave planning.
- You’re re-deriving the same numbers in a different format. A second view of the same data is presentation, not planning.
- The team could start and would learn faster by starting. On genuinely novel work, a two-day spike often answers a question that two weeks of estimating cannot.
The opposite failure is real too, and more common on small teams: skipping straight to execution because planning “isn’t real work”. That trades a week of thinking for a month of rework, and the trade is invisible until the rework starts.
Watch-outs specific to this phase
- Estimating in ideal hours. A task estimated at “two days of focused work” and scheduled as two calendar days will be late for reasons unrelated to the estimate. Convert with a realistic availability figure — see 3.3.
- Padding silently. Everyone adds a private buffer, so the project carries a hidden contingency nobody can manage. Better to estimate honestly and hold one visible buffer at project level.
- Planning around the people you wish you had. A plan that requires a specialist who is on another project isn’t a plan, it’s a request.
- Treating the baseline as immutable. Baselines change — that’s normal. What matters is that the change is a decision with a record, not a quiet edit.
How this looks in AB
Most planning artefacts have a direct home in AB Projects:
- Work breakdown → parent tasks with subtasks. The “has subtasks” flag and progress roll-up make decomposition visible at every level, which is the same shape as the diagram above.
- Schedule → due dates and dependencies on tasks, viewed as a Gantt timeline or on the Calendar to spot where work bunches up before you commit.
- Resources → the assignee field plus a per-task estimate. The estimate defaults to a real value (1h, not 0) so unedited tasks aren’t invisibly weightless in the totals.
- Risks → a Risks page in the project Wiki, or a tagged set of tasks with type “Risk” so each one has its own thread and owner.
- Communication → Adaptive Cards in the linked Teams or Slack channel, plus mentions on tasks for direct asks.
- Quality → review checklists captured as subtasks; the definition of done lives in the project Wiki where it can be pointed at.
The plan isn’t a document you write once and file. It is the structure of the project, visible to everyone with access — which also means an out-of-date plan is publicly out of date, and that turns out to be a feature.
Terms used on this page
- Work breakdown structure (WBS)
- A hierarchical decomposition of a deliverable into progressively smaller pieces, down to tasks small enough to estimate and assign. Its purpose is estimability, not tidiness. More →
- Baseline
- The approved version of scope, schedule and cost that progress is measured against. Changing it is normal; changing it without a record is how projects lose track of their own history. More →
- Bottom-up estimating
- Estimating each small piece of work and summing upward, so the total is a consequence of the parts rather than a number the parts were forced to fit. More →
- Critical path
- The longest chain of dependent tasks through the schedule. A day lost on it is a day lost by the project; a day lost elsewhere may cost nothing. More →
- Float
- The amount a task can slip before it starts delaying something else. Tasks on the critical path have none, by definition. More →
- Rolling wave planning
- Planning near-term work in detail and distant work in coarse blocks, refining as it approaches. An honest response to the fact that distant work is less knowable. More →
- Work package
- The lowest level of a work breakdown structure that is still managed as a unit — assignable, estimable and trackable on its own. More →
- Contingency
- Time or budget deliberately held in reserve for known uncertainty. Effective when it is visible and owned; useless when it is hidden inside individual estimates. More →
Related reading
3.0 Project Planning Basics
The four planning pillars as one connected system — and the symptom each produces when it’s thin.
3.2 Creating a Project Schedule
Sequencing, dependencies, the critical path, and estimating a range instead of a number.
2.3 The Execution Phase
What happens to the plan once contact with reality begins.