Why implementations slip, and what to plan for

Large technology projects have a well-documented habit of overrunning. In a study of more than 5,400 IT projects by McKinsey and the University of Oxford, published on 1 October 2012, large projects, with initial budgets above $15 million, ran on average 45% over budget and 7% over time, while delivering 56% less value than predicted.¹ In Harvard Business Review in September 2011, Bent Flyvbjerg and Alexander Budzier reported an analysis of 1,471 IT projects: the average cost overrun was 27%, and one project in six overran its budget by an average of 200% and its schedule by almost 70%.²

A later study by Flyvbjerg, Budzier and four co-authors, of 5,392 IT projects, published in the Journal of Management Information Systems in 2022, found that cost overruns follow a power-law distribution: a large number of projects with relatively small overruns, and a fat tail of projects with extreme ones. The authors propose one cause: a problem in one component can set off a chain reaction in the components that depend on it.³

The causes are well known, so they can be planned for. A slip shows at go-live, so plan backwards from that date.

Where the time goes

• Data. Migration is planned as a task near the end, and the data turns out messier than anyone said.
• Integrations. Interfaces are specified late, built against assumptions and tested only when everything else is ready.
• Testing. It’s the phase that gets squeezed when earlier ones run late, so problems are found by users after go-live.
• Decisions. Process questions wait for people who are busy running the business.
• People. The system is ready, but the people who need it haven’t been involved, trained or convinced.
• Ownership. The vendor, the implementation partner and the business each own part of the work, and nobody owns the whole.

What to set up at the start

• Start data and integration on the first day, as streams with their own owners, plans and rehearsals.
• Write test scenarios from the business early, and protect testing time in the plan.
• Name a business owner for each area, with authority to make process decisions within days.
• Bring in key users from each team early. They test, train their colleagues and tell you what’s really happening.
• Keep anything that can wait for a second phase out of the first.

Plan go-live before the build starts.

1. Choose the date around the business. No go-live in peak trading, at a period-end close, or while the people who know the processes are away.
2. Rehearse the cutover. End to end, at least once, with a rollback point at each step. Agree before the rehearsal who decides between going live and rolling back, and on which criteria.
3. Train by role. Each group learns the tasks it will do in the new system, close to go-live, and key users are ready to help their colleagues.
4. Support closely after go-live. For the first weeks, while people are still learning the system: the project team on hand, a quick route for questions, and daily checks on the processes that matter.
5. Measure adoption. After go-live, count who uses the system and for which tasks, check whether the old workarounds have stopped, and compare the process with its measures from before the change.

What successful projects share

The 2012 McKinsey research, drawing on surveys of IT executives, grouped the practices of successful projects into four areas: managing strategy and stakeholders, mastering technology and project content, building effective teams, and excelling at core project-management practices.¹