Project Management: Delivering Without Pretending You Knew Everything Upfront

Most software projects are late. The reasons are consistent enough to be worth naming, and most of them are not about the estimate being wrong.

Projects are late because scope was never bounded, because dependencies on other teams were assumed rather than confirmed, because decisions waited weeks for someone unavailable, and because problems were visible to the team long before they were visible to anyone who could act.

Estimation gets the blame because it is the number people can point at.

Why estimates fail#

They are for work nobody has done before. If it were routine you would not need a project. The estimate is a forecast about unfamiliar territory.

They exclude everything that is not building. Code review, testing, deployment, documentation, the meeting to clarify a requirement, the two days waiting for access. These are real and they are routinely omitted.

They assume nobody is interrupted. Someone allocated to three projects is not spending a third of their time on each — context switching takes a real toll, and the arithmetic quietly does not work.

They get negotiated. An estimate challenged downward without changing scope is not an estimate any more. It is a wish with a date.

The practical response is not better estimating. It is smaller pieces — a two-week estimate is far more likely to be right than a six-month one — and ranges over points: "four to seven weeks, and here is what makes the difference" is honest and more useful than a single number everyone knows is fiction.

Predictive or adaptive#

The choice matters less than matching it to the situation.

Predictive — plan the whole thing, then execute. Works when requirements are genuinely stable and known: a regulatory change with a fixed specification, a migration where the destination is defined. Its failure mode is discovering in month five that the plan from month one was wrong, with five months of work built on it.

Adaptive — work in short cycles, show something, adjust. Works when requirements will be discovered as you go, which describes most software. Its failure mode is endless iteration with no boundary — "we're agile" used to avoid ever committing to anything.

Most real projects are neither purely: a fixed outer boundary of budget and date, with adaptive delivery inside it. That is a coherent position, not a compromise, and it is worth stating openly rather than pretending to run a pure process.

What actually causes delay#

In rough order of frequency:

Unbounded scope. Not one big change — twenty small ones nobody logged. The cure is an explicit out-of-scope list and a change log where every addition names what it displaces.

Waiting for decisions. A team blocked for a week because the person who can decide is unavailable. Name a decision-maker per area, with a deputy, and agree a response time.

Unconfirmed dependencies. "Team B will provide the API in March" — did Team B agree, in writing, to March? An unconfirmed dependency is an assumption wearing a plan's clothing.

Late integration. Components built separately and joined at the end. Everything works alone and nothing works together, discovered when there is no time left.

Undiscussed quality debt. Corners cut to hit a date, then paid for during testing at a worse exchange rate.

Nobody wanting to deliver bad news. Status stays green until it is unrecoverably red. This is a culture problem, and the fix is a project manager who treats early warnings as valuable rather than as failure.

The controls worth having#

Not a governance framework — six things that repay their cost:

A one-sentence definition of done. If you cannot write it, the project is not ready to start.

An explicit out-of-scope list. Cheapest scope control available.

Milestones with exit criteria. A milestone without criteria is a date, not a checkpoint. "Design complete" means nothing; "design reviewed and signed by X, with these three questions answered" means something.

A dependency register with confirmations. Who owes what, by when, and did they agree.

A decision log. What was decided, by whom, why, and what was rejected. This is the artefact people are most grateful for six months later.

A risk register that gets reviewed. A risk without an owner and a review date is a worry.

Our Project Plan template contains all six.

Status reporting that is worth reading#

Most status reports are theatre: green, green, green, then a surprise.

A useful report answers four questions honestly:

1. What did we complete since last time? (Completed, not "worked on".)
2. What is next?
3. What is blocked, and who can unblock it?
4. What has changed about our confidence in the date, and why?

That fourth question is the one that matters and the one usually missing. Confidence changing is information; a status that never moves until it collapses is not a status.

Make it safe to report amber. If amber is punished, everything is green until it is a crisis.

Change control without bureaucracy#

Change is not the enemy — unmanaged change is. A workable rule: any change must name what it displaces.

"Add this feature" is a request. "Add this feature, and either the date moves by two weeks, or this other item comes out" is a decision someone can make. This single reframing converts most scope arguments into ordinary prioritisation, because it makes the cost visible at the moment of asking.

FAQ#

Should we use Scrum?#

Scrum is one framework and it suits some teams. Its value is the cadence and the feedback loop, not the ceremonies. Teams that adopt the meetings without the feedback loop get the overhead and none of the benefit.

How do we estimate better?#

Break work smaller, estimate in ranges, and track how your estimates compare to reality so you learn your own bias. Most teams are optimistic by a consistent factor — knowing yours is more useful than any technique.

What if the deadline is fixed?#

Then scope is the variable, and that has to be said out loud early. A fixed date, fixed scope and fixed team is a plan to deliver late or to deliver poor quality — which is the same thing arriving in a different order.

How much documentation does a project need?#

Enough that the project survives someone leaving. In practice: the scope boundary, the decision log, the dependency register, and acceptance criteria. Most other project documentation is written once and read never.

Who should be the project manager?#

Someone with authority to escalate and enough technical understanding to tell a real blocker from a comfortable one. A PM who only collects status is an overhead; one who removes obstacles is the most valuable person on the project.

How do we handle a project that is clearly failing?#

Say so early, in writing, with options: reduce scope, extend, add capability, or stop. Presenting options makes it a decision rather than a confession. Projects rarely fail suddenly — they fail slowly while everyone hopes.

What is the single highest-value practice?#

Small increments delivered frequently to someone who can say whether they are right. Almost every other problem — bad estimates, wrong requirements, late integration — surfaces earlier and cheaper when the feedback loop is short.

What else is coming for Project Management