Opening with an uncomfortable truth
If you are about to invest in a software project—whether it is an ERP system, a customer-facing application, or an internal back-office platform—there is one number you should know before signing the contract:
83.9% of IT projects fail partially or completely
This figure comes from the Standish Group, which has tracked IT projects since 1994. Their latest findings still confirm the same pattern: only 31% of projects succeed in meeting goals for schedule, budget, and scope. Another 50% are completed but run over, and 19% are canceled altogether.
McKinsey, together with the University of Oxford, studied more than 5,400 IT projects and found that large projects (with budgets over $15 million) exceed budgets by an average of 45%, miss deadlines by 7%, and deliver 56% less value than expected.
But what is more alarming than the numbers is the reason behind them. Software projects rarely fail because of some highly technical, hard-to-understand issue. They fail because of basic problems that happen again and again—as if we never learn from them.
This article brings together 7 real causes our team has seen repeatedly in actual projects, not classroom theory. Each one includes a real example (with names changed to protect confidentiality), research-backed statistics, and prevention methods you can use right away.
Cause #1 — Scope Creep: “Just one more thing” never ends
Real story: from 20 features to 67 features
A manufacturing company in Thailand’s Eastern region (let’s call it “ManuTech”) wanted a warehouse management system. The initial scope was clearly defined: 20 essential core features, a budget of 2.8 million baht, and a timeline of 4 months.
The first month went well. But once the team started demoing the system to real users, everything changed.
“Can we add barcode scanning? Just simple scan-in, scan-out.”
“It would be great to have a real-time dashboard showing stock levels.”
“Right now we use Excel to calculate reorder points. If the system could do that too, it would save a lot of time.”
Every request sounded reasonable. Each one seemed “not that difficult.” But taken together, the scope exploded—from 20 features to 67 features in just 3 months. The budget rose from 2.8 million to 6.2 million baht. The timeline stretched from 4 months to 11 months.
Worse, these added features were never designed to work together from the start. The result was a system that became unnecessarily complex, full of bugs, and difficult to maintain.
Mr. Somchai (pseudonym), Production Manager at ManuTech: “Every time I asked for another feature, I thought it was just a small change. I had no idea that, once combined, they would completely transform the project.”
The data: Scope creep is one of the top problems in every project
- PMI Pulse of the Profession 2025 states that projects without a formal change management process are 35% more likely to go over budget or schedule.
- Standish Group found that clear requirements are one of the top three factors behind project success.
- Organizations that invest in PM soft skills can reduce scope creep by 12%.
How to prevent it
- Create a formal Change Request process — Every added feature should be evaluated for impact on timeline and budget, and approved by the right authority. It should not be settled casually in a meeting.
- Split the work into clear phases — Launch phase 1 with the 20 core features first, then collect feedback and improve in phase 2. Launching early and improving is better than trying to launch everything late.
- Show executives the real numbers — Every time a new feature is requested, make the impact visible: “This feature adds X baht and pushes the deadline by Y weeks.” Decisions should be based on data, not feeling.
Cause #2 — Unclear Requirements: “Make it like Facebook, but better”
Real story: 15 meetings and still no agreement
A mid-sized retail company (let’s call it “ShopPlus”) wanted a customer loyalty app. The project started with a simple direction: “Make it like the big-brand apps, but tailored to us.”
The problem was: what exactly did “tailored to us” mean?
Marketing wanted a gamified points system. Sales wanted push notifications based on customer location. Accounting wanted integration with the existing POS system. The CEO wanted a social feed where customers could post product reviews.
All four departments had completely different visions, and each believed that their own vision was what “everyone had already agreed on.”
The result: 15 meetings in the first 2 months, but no requirements document signed off by all stakeholders. The development team started building based on what they “thought they understood.” Then demo day came—and every department was disappointed, because what they saw did not match what they had imagined.
Ms. Rattana (pseudonym), Marketing Manager at ShopPlus: “At every meeting, everyone nodded. I thought we were aligned. It was only when we saw the actual product that we realized we had been talking about different things the whole time.”
The data: unclear requirements are the #1 project killer
- For over three decades, Standish Group has consistently identified “clear statement of requirements” as one of the top three drivers of project success.
- Studies show that 37% of failed projects are caused by unclear objectives.
- PMI continues to confirm that weak stakeholder engagement and poor communication are among the leading causes of project failure every year.
How to prevent it
- Run intensive requirement workshops — Do not just ask, “What do you want?” Make sure everyone sees the same picture through wireframes or simple prototypes. When people can actually see the same thing, alignment improves dramatically.
- Create a requirements document that everyone signs off on — It does not need to be a 200-page document, but it must clearly state what the system will do and what it will not do, with sign-off from all key stakeholders.
- Prioritize using MoSCoW — Classify requirements into Must have, Should have, Could have, and Won’t have so everyone agrees on what comes first, what can wait, and what is out of scope.
Cause #3 — The sponsor disappears halfway through
Real story: the CEO approved it, then never joined another meeting
A large logistics company (let’s call it “FastShip”) had a CEO who believed the company needed digital transformation, so he approved a smart transportation management project with a budget of 12 million baht.
In the first week, the CEO personally attended the kickoff meeting. Everyone was excited. Everyone was fully committed.
After that—the CEO never attended another project meeting.
Problems started to pile up. Operations and IT disagreed on workflow design. No one felt comfortable making decisions because “we need to ask the CEO first.” But the CEO was always in meetings and impossible to pin down. Issues sat unresolved for weeks.
The IT team tried to solve this by guessing what the CEO probably wanted and moving forward. Four months later, when they finally demoed the result, the CEO was unhappy. Nearly 40% of the work had to be redone.
Mr. Pichai (pseudonym), CTO of FastShip: “I understand that the CEO is busy. But a 12-million-baht project is not something you can leave entirely to middle management. Some decisions need someone with authority to set the direction.”
The impact: the team becomes afraid to decide, and everything slows down
When a project sponsor disappears, this is what usually happens:
- Decision-making stalls — Issues that require authority, such as changing workflow or cutting features, sit unresolved.
- The team starts working by guesswork — And guesswork is usually wrong, which leads to rework.
- Morale drops — The team feels the project is not truly important if even the approver is not paying attention.
- Other departments stop cooperating — If the CEO is not visibly backing the project, teams being asked to change have little motivation to participate.
How to prevent it
- Define the sponsor role clearly — The sponsor is not just “the person who approves the budget.” They must also be “the person who attends the steering committee at least once a month” and “the person who answers critical questions within 48 hours.”
- Delegate authority clearly — If the CEO is too busy, appoint another executive as Deputy Sponsor with defined decision-making authority.
- Use short executive summaries — Executives do not read 20-page status reports. Send a 1-page summary with 3 things: status, key risks, and decisions required.
Cause #4 — Choosing the wrong technology: using a cannon to shoot a bird
Real story: a 30-person SME using an ERP built for a 5,000-person company
A construction materials company (let’s call it “BuildMax”) had 30 employees, 2 branches, and annual revenue of around 80 million baht. They wanted an ERP system to manage inventory, sales, and accounting.
A consultant recommended an enterprise-grade ERP platform designed for companies with thousands of employees, with hundreds of modules to choose from. The reasoning was: “Invest once, use it for life, and you will not need to change systems as the company grows.”
It sounded convincing. But the reality was this:
- License costs were far higher than what a company of this size should reasonably pay.
- Implementation complexity pushed the timeline to 14 months instead of 3–4 months.
- The IT team had one person managing a system designed for a 20-person IT department.
- Customization required hiring the vendor for everything, because the system was too complex for the internal team to adjust on their own.
Six months after go-live, the sales staff at both branches were still recording sales in separate Excel sheets because “the new system is 3 times slower than the old way.”
The ERP system became an expensive decoration that no one actually used.
Mr. Natee (pseudonym), owner of BuildMax: “I paid for a luxury car, but all I got was a car sitting in the garage because nobody knew how to drive it.”
The data: ERP projects have one of the highest failure rates in the industry
- Gartner estimates that 70% of ERP projects fail to achieve their intended objectives.
- Panorama Consulting reports ERP failure rates in the range of 55–75%.
- In manufacturing, the rate goes as high as 73%, with average cost overruns of 215%.
- More than 50% of organizations are dissatisfied with their ERP implementation.
How to prevent it
- Choose technology that fits your size — The best system is the one that fits your organization, internal team, and budget—not the biggest or most feature-rich one.
- Run a proof of concept first — Before committing to any platform, test it with real company data and real workflows for at least 2–4 weeks.
- Think about actual users — Good technology must be practical for the people who use it daily, not just impressive on a presentation slide.
Cause #5 — No change management: “Just use it, it’s a great system”
Real story: the new system was ready, but people refused to change and went back to spreadsheets
A financial services company (let’s call it “FinPro”) invested 8 million baht in a new CRM system to replace one they had used for 7 years. The new platform was better in every way—faster, more complete, and equipped with automation to reduce repetitive work.
On go-live day, the IT team announced: “Starting today, everyone must use the new system only. The old system will be shut down in 2 weeks.”
Week 1: 60% of employees had not even logged into the new system.
Week 2: people who tried it complained that “it’s hard to find things” and “it feels slower than the old system.”
Month 2: 80% of the sales team had gone back to using spreadsheets to record customer data, copying information from the new system into their own files.
The 8-million-baht CRM ended up holding incomplete data because people were not entering information. That meant the automation did not work. That meant executives did not get accurate dashboards. And the cycle continued.
Mr. Arun (pseudonym), Sales Director at FinPro: “The new system really is better. I believe that. But frontline people do not care whether the system is objectively better. They care whether they can get their work done today. If the new system slows them down in the first two weeks, they will go right back to the old way.”
The data: 70% of change initiatives fail
- McKinsey found that 70% of transformation initiatives fail, mainly because employees resist change and leadership does not invest enough in preparing people.
- 72% of organizations with failed transformations say that employee resistance or management behavior was the main obstacle.
- Organizations where leaders define roles clearly and communicate progress consistently are 8 times more likely to succeed.
How to prevent it
- Prepare people before building the system — Do not wait until the system is finished. Involve real users from the design stage. When people feel included, they feel ownership instead of being forced.
- Provide hands-on training — Do not just send a 50-page manual. Run real training sessions using real data, and assign support champions in each department during the first 2–4 weeks.
- Allow a transition period — Do not shut down the old system immediately. Let the old and new systems run in parallel for a while, then gradually reduce reliance on the old one. Build the new bridge before demolishing the old one.
- Measure adoption, not just go-live — Success is not the date the system launches. Success is the percentage of people actually using it after 1 month, 3 months, and 6 months.
Cause #6 — Unrealistic timelines: “It should take about 3 months”
Real story: estimated at 3 months, actually took 14
A healthcare company (let’s call it “MedLink”) wanted to develop an appointment and patient data management system. The IT team estimated that “it should probably take 3 months.” The CEO approved it immediately because that sounded reasonable.
Month 1: once work began, they discovered the legacy system used data formats that “nobody remembers why they were designed this way,” which made data migration much more complex than expected.
Month 2: the system had to integrate with 4 health insurance providers, each with a different data standard, none of which had been included in the original scope.
Month 3: the legal team informed them that the system would need to comply with health data security standards, requiring an additional 2-month audit.
Month 5: one-third of the development team resigned. A replacement had to be hired and onboarded, costing another month.
In the end, the project that was supposed to take 3 months actually took 14 months, exceeded its budget by 180%, and still had bugs to fix after go-live.
Ms. Wipa (pseudonym), CTO of MedLink: “When I estimated 3 months, I was only thinking about coding the system. I was not thinking about data migration, integrations, security audits, or even the risk of people leaving mid-project. Every single thing I forgot to consider kept adding more time.”
The data: overruns are normal in large IT projects
- McKinsey and the University of Oxford studied more than 5,400 IT projects and found average overruns of 45% in budget and 7% in schedule.
- The longer the project, the greater the risk—every additional year increases cost overruns by another 15%.
- 17% of IT projects become “black swans,” with cost overruns above 200%, serious enough to threaten the company itself.
- Software projects carry the highest risk of going over budget and schedule compared with other IT project types.
How to prevent it
- Use the “multiply by 2.5–3x” rule — If the team estimates 3 months, tell executives to expect 8–9 months. It sounds conservative, but the data shows teams often underestimate by 2–3 times.
- Separate visible work from invisible work — Actual development may only account for 40% of the total project effort. The other 60% is data migration, integration, testing, security, training, and unexpected issue resolution.
- Build in a risk buffer — Reserve 20–30% extra time for unforeseen problems, because every project includes “unknown unknowns.”
- Use a milestone-based approach — Instead of saying “done in 14 months,” break it into smaller checkpoints such as “prototype in 6 weeks,” “MVP in 4 months,” and “full version in 10 months” so progress can be reviewed along the way.
Cause #7 — The wrong vendor or partner: cheapest does not mean best
Real story: they chose the cheapest vendor, but the vendor did not understand the business
A real estate company (let’s call it “HomePrime”) wanted to develop an online property sales platform and invited 5 vendors to submit proposals.
| Vendor |
Proposed Price |
Timeline |
Industry Experience |
| A |
4.5 million |
6 months |
Yes |
| B |
3.8 million |
5 months |
Partial |
| C |
2.1 million |
4 months |
None |
| D |
5.2 million |
7 months |
Extensive |
| E |
3.2 million |
5 months |
Partial |
Procurement selected Vendor C because it was “the cheapest and the fastest.”
Problems appeared from the very first month. Vendor C did not understand the real estate sales workflow. They did not know the difference between a reservation and a contract. They did not understand common fees, transfer costs, or taxes. The client had to teach the vendor the business from scratch.
By month 4—the promised delivery date—Vendor C delivered a system that could not actually be used. Almost everything needed rework.
By month 8, HomePrime terminated the contract and hired Vendor A to rebuild the system from the ground up.
Final total cost: 2.1 million baht paid to Vendor C for a system that was never used, plus 4.5 million baht paid to Vendor A to rebuild it = 6.6 million baht.
That was more expensive than the most expensive option from the start—and they also lost 8 months with nothing to show for it.
Mr. Theerayut (pseudonym), CEO of HomePrime: “That 2.1-million-baht lesson taught me this: the cheapest option is often the most expensive in the long run, because you end up paying in lost opportunity, rework, and damaged team confidence.”
The data: choosing the wrong partner can be devastating
- An NTT DATA report found that 80% of organizations admit that unsuitable technology is holding back progress and innovation.
- The true cost of selecting the wrong vendor is not just the money paid—it also includes lost time + opportunity cost + the cost of hiring a new vendor, which often exceeds the price of the “most expensive” option from the beginning.
- In failed ERP projects, the top 3 causes—poor change management, failed data migration, and inexperienced teams—account for 75% of failures, and all three are directly linked to vendor quality.
How to prevent it
- Do not use price as the only criterion — Create a scoring matrix that gives weight to industry experience, the actual delivery team, customer references, and methodology—not just cost.
- Meet the actual team who will do the work — Do not evaluate only the sales team doing the pitch. Meet the project manager and developers who will actually work with you. They are the ones who determine success, not the salesperson.
- Start with a pilot project — Before signing a large contract, ask the vendor to do a small pilot project first, such as 1–2 months, so you can evaluate how they work, communicate, and deliver.
- Check references seriously — Do not just look at logos in a portfolio. Call or meet previous clients and ask about their real experience.
So what do successful projects have in common?
After looking at 7 reasons projects fail, the key question is: what do successful projects do differently?
Based on research from Standish Group, PMI, and McKinsey, successful projects consistently share 5 characteristics:
1. User involvement from day one
Successful projects do not wait until the system is finished before showing it to users. Real users are involved from the design stage, test prototypes throughout the process, and give feedback that can be applied immediately.
Standish Group has identified user involvement as the #1 factor behind project success for over 30 years.
2. Real executive support, not just budget approval
In successful projects, executives do more than approve the budget and disappear. They stay involved, make key decisions on time, communicate clearly to the organization that “this project matters,” and remove obstacles the team cannot solve on its own.
Organizations where leaders define roles clearly and communicate consistently are 8 times more likely to succeed.
3. Controlled scope and the courage to cut
Successful projects are willing to cut unnecessary features. They are willing to say “no” to unreasonable requests. And they have a formal process for handling change requests.
A system with 10 features done well is better than a system with 50 features done halfway.
4. Start small, launch fast, then grow
Small projects have success rates of up to 90%, while large projects succeed less than 10% of the time (Standish Group).
That is why successful projects are usually broken into smaller phases. Teams launch one part at a time, collect feedback, improve, and then move forward—instead of trying to build everything and launch all at once.
5. A partner who understands the business, not just the technology
The difference between successful and failed projects often comes down to people, not technology. A partner who understands your business, understands user pain points, and can recommend the right practical solution is far more valuable than a partner with cutting-edge technology who does not understand how your business actually works.
Conclusion: projects do not fail because of technology, but because of mindset
If you read through all 7 causes, one thing becomes clear: none of them are purely technical problems.
- Scope creep → a management problem
- Unclear requirements → a communication problem
- Missing sponsor → a leadership problem
- Wrong technology → a decision-making problem
- No change management → a people problem
- Unrealistic timelines → a planning problem
- Wrong vendor → a selection problem
All of these are preventable if you approach the project with the right mindset, the right process, and the right people who understand both business and technology.
Note: All examples in this article use fictional names to protect the confidentiality of real organizations, but the situations and figures are based on real industry experience.
Talk to Enersys before starting your project
If your organization is planning a software project—whether it is an ERP system, a customer platform, or an internal back-office system—and you do not want to become part of the 83.9% that fail,
we can help from the very beginning: requirement analysis, realistic scope planning, choosing technology that fits your organization, implementation, and change management.
Talk to the Enersys team
References
