Why IT projects start fast and slow down
Project leaders in IT face a persistent dilemma. “Think slow, act fast” has become our mantra, emphasising careful upfront thinking before execution. At the same time, Agile promotes a competing instinct: “show me the thing,” prioritising early delivery and learning through iteration. Both cannot be right at the same time. Oxford Global Projects have published a white paper on it. Download below.
IT projects can make rapid early progress and still finish late. Working software gives stakeholders something tangible to see, while unresolved questions about how the organisation will use it remain hidden. As those questions surface, development gives way to redesign and rework. The leadership challenge is recognising when the project understands enough to commit.
What the data shows
OGP’s whitepaper examines evidence from more than 6,000 IT projects. Around 10% of total project spend goes into development. Most is absorbed by design, testing, coordination and management: the work of making the software fit the organisation.
The median project appears to be on time and on budget, but a small number of extreme overruns pull the averages substantially higher. It’s those undesirable outcomes which make it important to identify unresolved issues before they become expensive to correct.
Why early progress can be misleading
Different teams can agree on a set of systems requirements in principle while carrying different assumptions about what they should do. Those differences may only surface during development, when features have already been built into the software.
Interfaces also involve organisational agreements. Teams must agree how work passes between them, how information is structured and who takes responsibility. An integration problem can expose an agreement that was never properly settled.
The people who understand their own processes are often only consulted around their existing silos. As a result, the team may discover late that the system does not fit the way the business operates.
When planning stops helping
The whitepaper describes convergence as reaching a sufficiently stable understanding of the system, its interfaces and the organisation’s readiness to use it. Both premature development and prolonged analysis can delay that point.
Higher spending on feasibility and design is often associated with greater schedule delays. The authors interpret extended planning as a possible sign of unresolved uncertainty. Spending longer on design does not establish that the thinking is better.
Across the datasets examined, projects allocating roughly 20–30% of effort upfront tended to have the lowest schedule slippage and cost overrun. That is an observed pattern, not a universal planning allowance. Leaders still need to judge what their own project has resolved.
What useful iteration achieves
Some Agile practices can help teams test important assumptions before committing. A prototype can reveal whether a proposed workflow makes sense to users or whether information can pass reliably between functions.
Each iteration should therefore answer a consequential question. Producing more features can create an impression of progress while uncertainties about integration and organisational fit remain untouched. Faster development tools make that distinction increasingly important.
What leaders should check
Before committing to delivery, ask whether the assumptions that could change the design have been tested and agreed. Check that responsibilities at interfaces are clear, and that the necessary experts have time allocated to the project.
Repeated changes to assumptions, late integration problems and unavailable experts are warning signs. The practical task is to resolve the uncertainties that would otherwise force the team to change course during execution. That gives the project a firmer basis for moving at pace.
Talk to us about IT project planning and delivery
Source: Budzier, A., Meyerson, B.. (October 2026). Fast starts, slow finishes: What the data really say about “Think slow, act fast” and “Show me the thing”. Oxford Global Projects, version one.