Most big system rollouts fail because of people and process, not tech. Large IT projects run 45% over budget on average and deliver less value than promised. The top causes are weak work with key players, vague goals and poor change management. The project managers who beat those odds plan around people first. They roll out in stages and stay close to users long after go-live.
That pattern shows up in the research. It shows up in public failures that cost firms billions. And it shows up in the careers of the people who quietly get these projects done. For leaders about to replace an ERP, a point-of-sale platform or a scheduling system, the lessons are practical and well known.
The Numbers Behind Failed System Rollouts
The most cited study on the subject comes from McKinsey and the University of Oxford. The two groups looked at more than 5,400 IT projects and focused on those with budgets above $15 million. On average, large IT projects ran 45% over budget and 7% over schedule while delivering 56% less value than predicted. About 17% went so badly that they put the firm itself at risk.
Time made it all worse. In the same data, each extra year a project ran added about 15% to its cost overrun. Long programs give needs time to drift, sponsors time to leave and vendors time to change their products.
Newer research points the same way. Gartner predicts that by 2027, more than 70% of recent ERP projects will not fully meet their first business goals. Panorama Consulting’s 2026 ERP report found that more than a quarter of firms went over their ERP budgets. Most often, that was because they found extra tech needs halfway through.
Why the Software Is Rarely the Real Problem
McKinsey sorted the causes of overruns. About half traced back to weak strategy and weak work with key players, plus gaps in tech and subject know-how. Another 40% came from team problems and weak core project management. Bad code was not the main story.
Public failures show how this plays out.
- Target Canada. The retailer had to load about 75,000 products into a new SAP system before it opened stores. Canadian Business later found that the product data was right only about 30% of the time. In Target’s U.S. business, it was right 98% to 99% of the time. Empty shelves followed. Target Canada filed for creditor protection in January 2015 and closed all 133 stores.
- Lidl. The German grocer dropped its SAP-based stock project in 2018 after about seven years. Lidl valued stock at the price it paid, while the retail software assumed the price it sold at. Rather than change the process, the firm changed the software. Press reports put the loss at around €500 million, a figure neither firm confirmed.
- The NHS National Programme for IT. The U.K. launched the program in 2002 and took it apart in 2011. A committee of Parliament reported forecast costs of £9.8 billion. One of its members called it one of the worst contract fiascos in the history of the public sector.
In each case, the system did what it was built to do. The business processes, data and choices around it did not keep up.
What Change Management Actually Changes
Change management sounds soft until you see the numbers. Prosci has studied the topic for more than two decades. It reports that 88% of projects with excellent change management met their objectives, compared with 13% of projects with poor change management. That is about a sevenfold gap.
Prosci’s research also ranks one factor above all others: an active, visible executive sponsor. In its best practices research, projects with very strong sponsors met their goals 79% of the time. Those with very weak sponsors met them 27% of the time. Yet fewer than half of those who do this work say they have a strong sponsor.
The Project Management Institute makes the same point in a new way. Its 2025 Pulse of the Profession found that only 18% of project pros show strong business sense. Those who do report more projects that meet business goals, more projects on budget and fewer flat-out failures. Senior leaders now rank people skills, shared leadership and big-picture thinking almost as high as tech skill.
Five Habits of Project Managers Who Deliver
The people who land hard rollouts tend to share a set of habits. Many of them, like operations analysts who grew into senior project managers, learned the business before they learned the method. That background shapes how they work.
1. They fix the process and the data before go-live
Target Canada’s failure started with data entry, not software. Seasoned project managers treat data cleanup as its own track, with its own owner and deadline. They also push back on changing software just to keep old processes. That was the trap Lidl fell into.
2. They release in stages
The U.S. Government Accountability Office found that delivering technology in smaller increments improves the odds of meeting cost, schedule and performance goals. Federal rules ask agencies to deliver usable features at least every six months. Pilots at one store, one plant or one team bring out problems while they are still cheap to fix.
3. They get a sponsor who shows up
A sponsor who signs the budget and then vanishes is not enough. Good sponsors attend key meetings. They explain the reasons for the change to staff, and they make fast calls when tradeoffs come up.
4. They build a network of super users
Super users are front-line staff trained early who help their peers after launch. They answer questions on the floor in real time. That keeps small gripes from turning into workarounds that weaken the new system.
5. They plan for hypercare
Go-live is the start of the hardest phase, not the end of the project. Experts advise several weeks of hypercare. That means a daily review of issues, visible on-site help and exit rules agreed on before launch. Teams leave hypercare when the system is stable, not when the calendar says so.
Why Hands-On Experience Matters So Much
The research keeps coming back to one idea. Rollouts fail when the people in charge do not know how work really gets done. That is why project managers who came up through operations often do better than peers hired just for their degrees and titles.
The same theme runs through Business Insiders’ coverage of project and operations leaders. A capital project manager who started as a ride operator built his on-time record by knowing how a park really runs. A project manager with three decades in manufacturing has said how much of the job is talking with people. The fields differ, but the lesson is the same.
A Short Checklist Before Your Next Rollout
- Name an executive sponsor and agree on how often they will speak to staff.
- Pick an owner for data cleanup and check how accurate the data is before launch.
- Change the process before you change the software.
- Pilot with one site or team, then grow in waves.
- Train super users first and give them time away from their normal work.
- Set the rules for ending hypercare before go-live.
- Track how many people use the system, not just uptime, for the first 90 days.
Frequently Asked Questions
What percentage of system rollouts fail?
It depends on how you define failure. McKinsey and Oxford found large IT projects average 45% over budget and 56% short of expected value. Gartner predicts more than 70% of recent ERP projects will miss some of their first business goals by 2027.
What is the most common reason ERP projects fail?
People and process problems lead the list. Weak sponsors, vague goals, poor data and little change management cause more trouble than the software itself.
How long should hypercare last after go-live?
Most teams plan for several weeks. The better way is to set clear exit rules, such as steady ticket counts and user goals. Teams should leave hypercare only when those are met.
The Bottom Line
System rollouts are people projects with software attached. The firms that succeed invest early in sponsors, clean data, staged releases and support after launch. They also put the work in the hands of project managers who know the business they are changing.
