3.0 Project Planning Basics: Scope, Schedule, Risk

Foundations of Project Planning

Planning is where a project quietly decides whether it is going to work. Not because a plan predicts the future — it does not — but because the act of planning forces four questions into the open early, while the answers are still cheap to change.

Those four questions are: what are we delivering, by when, with whom, and what could go wrong? Everything in this chapter is one of those four, examined properly.

Why the plan decides the outcome before the work starts

There is a well-worn claim that most of a project’s success is settled during planning. Treated as a statistic it is unfalsifiable, but treated as an observation about cost it is obviously true: a misunderstanding caught while you are still writing the scope costs a conversation. The same misunderstanding caught during testing costs a rebuild, a delayed launch, and a difficult meeting with whoever paid for it.

That asymmetry is the whole argument for planning. Not because early decisions are more likely to be right — they are usually made with the least information you will ever have — but because early decisions are the cheapest ones to reverse. Planning is how you buy the option to change your mind while changing your mind is still affordable.

It follows that a plan’s value is not in its accuracy. A plan that turns out to be wrong but told you which assumption was wrong has done its job. A plan that was vague enough to never be wrong has not.

The four pillars — and what a gap in each one costs

Each pillar answers a different question, and each has a characteristic failure mode. The useful thing about knowing the failure modes is that you can recognise them from the inside, weeks before anyone uses the word “late”.

What thin planning actually looks like

Almost nobody skips planning deliberately. It gets compressed — the kickoff is next week, the scope document is “good enough for now”, the risks will be obvious once we start. The damage surfaces later, and rarely under a label that points back at the cause. Watch for these:

• Recurring “quick questions” about what is included. If the same boundary is being renegotiated in Slack every week, the scope was never actually agreed — it was described.
• Estimates given in meetings, by the person who wants the work done. A number produced under social pressure is a wish with a decimal point.
• A task list with no owners, or owners who are whole teams. Work assigned to “design” is work assigned to nobody in particular.
• Progress reported as a percentage that never quite reaches 100. Almost always a sign there was no agreed definition of finished.
• Every problem arriving as a surprise. Not because the problems were unforeseeable — because nobody was ever asked to foresee them.
• Nobody can name the sponsor or say who decides. The plan will stall at the first genuine trade-off, and it will stall for weeks.

None of these read as planning failures in the moment. They read as communication problems, or estimation problems, or people problems. They are usually a decision that was deferred and then forgotten.

How much planning is enough?

The opposite failure is real too. Teams that plan a twelve-month programme to the day spend months producing a document that is wrong by the time it is signed, and then defend it rather than adapt it. Detail is not the same as rigour.

A workable rule: plan in proportion to how expensive it is to be wrong, and in inverse proportion to how much you can learn by starting. Where change is cheap and feedback is fast — an internal tool, a marketing campaign — plan the shape and the first increment properly, and leave the rest coarse. Where change is expensive and irreversible — a building, a regulated release, a data migration with no rollback — the detail earns its keep.

In practice this means planning the near term at fine grain and the far term at coarse grain, then re-planning as the far term approaches. A schedule that shows next month in days and next quarter in milestones is not sloppy. It is honest about what is currently knowable.

The order matters — and so does the loop back

The four pillars are worked in sequence for a reason: each one supplies an input the next one needs. Scope produces the list of work. The schedule sequences that list and gives it duration. Resourcing tests whether the schedule is achievable with the people you can actually get. Risk planning stress-tests the whole thing.

But the sequence is a first pass, not a pipeline. Resourcing regularly proves the schedule impossible, which sends you back to scope to decide what to drop. Risk analysis regularly finds a dependency that reorders the schedule. Going backwards during planning is the process working, not the process failing. Going backwards during execution is what you were trying to avoid.

What this chapter covers

Worked through properly, these four become the project’s decision-making blueprint — the thing the team goes back to when the road gets foggy, and the thing that tells you what actually changed when it does.

How this looks in AB

In AB Project Management the plan is not a document that sits beside the work. Scope becomes the task hierarchy; the schedule emerges from start dates, due dates and estimates on those same tasks; resourcing shows up as assignment and load across the project Calendar; and risks live as tasks with owners so they are reviewed rather than filed. Because all four pillars are the same underlying records, a change to one is immediately visible in the others — which is exactly the interaction this chapter is about.

Terms used on this page

Every term below is defined at more length in the full project management glossary.

Scope

The full definition of what the project will deliver — and, just as importantly, what it will not. The one constraint you control directly at the start. More →

Scope creep

Gradual expansion through small additions that each seem trivial and together consume the schedule. It arrives as “while you’re in there, could you just…” More →

Triple constraint

The interlocking relationship between scope, time and cost, with quality in the middle. Change one and at least one other has to move. More →

Assumption

Something treated as true in order to plan, but not verified. Every unwritten assumption is a risk wearing a disguise. More →

Baseline

The approved version of the plan, frozen so you can measure drift against it. Changing it formally is called re-baselining. More →

Sponsor

The senior person who owns the business case, holds the budget, and can resolve what the project team cannot. If you cannot name yours, fix that first. More →

WBS

Work Breakdown Structure — the decomposition of total scope into work packages small enough to estimate and assign. Everything downstream is built from it. More →

Critical path

The longest chain of dependent tasks through the project. Its length is the minimum possible duration, so it is where your attention is worth the most. More →

Risk vs. issue

A risk might happen; an issue already has. Risks get probability and impact; issues get an owner and a due date. More →

Related reading