8.1 Planning Under Uncertainty

Project planning is often mistaken for writing the future into a table. Real software projects change: requirements shift, technical limits appear, external dependencies slip, and the team learns new information.

Good planning does not pretend the future is certain. It arranges learning, exposes risk, and preserves room to adjust.

Planning Is A Learning System

The higher the uncertainty, the less useful it is to commit to exact scope and date on day one. A stronger plan separates the unknowns:

• What do users actually need?
• Is the technical approach feasible?
• Can external teams deliver in time?
• Is the data quality good enough?
• Are there hidden compliance, security, or performance constraints?

Each unknown should have a learning action: a technical spike, prototype, interview, data sample, release rehearsal, or architecture review.

Buffer Is Not Laziness

Buffer is an admission of reality. A plan with no buffer hides all risk in the final week. Buffer can live in time, scope, staffing, technical approach, or release strategy.

But buffer should not be a vague excuse. Mature buffer states:

• Which risk does it protect?
• Who can use it?
• What replanning does it trigger?
• If unused, can it turn into earlier delivery or more validation?

Milestones Should Include Decisions

A weak milestone only says a date: "backend complete by June 30." A stronger milestone says evidence and decision: "By June 30, complete SSO spikes with two customer IdPs and decide whether generic configuration is safe or scope must narrow."

A useful milestone answers:

• What must we know by this point?
• If the result is bad, how will scope, solution, or timeline change?
• Who owns the decision?
• What evidence is enough to continue?

A plan is not a one-time document. It is the team's workbench for learning and correcting course in an uncertain world.