Why software projects run late: what eight years taught us
Late projects rarely have slow developers. Looking back, most of the lost time was spent waiting: for a decision, an access credential, a piece of content, an approval. Coding time usually lands close to the estimate; everything around it does not.
1. Decision latency
If “which fields are mandatory on this screen?” takes a week to answer, that week goes straight into the schedule. Name the decision-maker at the start and put a deadline on each decision. Agreeing in writing that development proceeds with a default when no answer arrives is far cheaper than waiting.
2. Scope growing quietly
Scope rarely grows through big requests; it grows through “let’s add this too, it’s half an hour”. Each addition really is small — the sum is not. The only method that works is making every addition immediately visible: added, cost in days, new delivery date. Banning scope change is unrealistic; keeping it from being invisible is not.
3. Integration surprises
Third-party integrations almost always take longer than estimated, not because they are hard but because access and documentation are missing: no sandbox, the right person is away, the docs are stale. Leaving integration to the end is therefore the most expensive decision available. Make one end-to-end call in the first week.
4. Underestimating data migration
Legacy data is never as clean as expected. Migration is usually planned as a single line item and then takes weeks. Run a trial migration with real data in the middle of the project — not at the end.
5. No time reserved for testing
Testing gets squeezed into the final two days and those two days are never enough. Writing acceptance criteria at the start prevents this: when “done” is defined up front, testing becomes a continuous check rather than a phase.
What we do
We write these five items down at project start: who decides, how scope changes are recorded, when the first integration call happens, the trial migration date, and the acceptance criteria. The list is not magic, but it turns delay from a surprise into a known risk — and known risks can be managed.