Three months into an ERP implementation, everyone is busy. Meetings are happening. Tickets are being closed. Consultants are working late. Developers are writing customizations. The project plan is still mostly green.

And yet the go-live date keeps moving.

The strange thing is that everyone may be telling the truth. That is what makes troubled projects so difficult to diagnose.

Software and ERP projects rarely fail because somebody makes one spectacularly bad decision. More often, the project slowly becomes unhealthy. A requirement is left vague. A decision takes two weeks instead of two days. A key business user is never available. An integration is postponed. The data is "almost ready." Another customization is approved because "it's only a small one." Testing gets pushed toward the end.

The status report stays green.

None of these things, by themselves, necessarily kills a project. The problem is what happens when they start accumulating. By the time everyone agrees there is a serious problem, the project has usually become much more expensive and much harder to recover.

After enough years in software and ERP delivery, I have become suspicious of projects that look healthy but nobody is asking uncomfortable questions. The good news is that troubled projects usually leave fingerprints. You can often see the direction they are heading months before the failure becomes obvious.

What Does "Failure" Actually Mean?

Before talking about failure patterns, it helps to define what we mean by failure. A project can fail in several different ways. It can:

• Miss the agreed date
• Exceed its budget
• Deliver the wrong functionality
• Deliver functionality nobody actually uses
• Technically go live while disrupting the business
• Become so heavily customized that future maintenance becomes painful and costly
• Satisfy the contract but fail to deliver the expected business benefits
• Continue indefinitely because nobody wants to formally admit that it has failed

ERP makes this especially complicated. There is a huge difference between "We implemented the system" and "The organization can now operate effectively using the system."

Those are not the same achievement. An ERP implementation changes processes, responsibilities, data, controls, reporting, decision-making and often people's day-to-day behavior. You can therefore have a technically successful implementation and still have an operationally unsuccessful project.

That distinction matters. A system being deployed is not the same thing as a business being ready. And a business being ready is not necessarily the same thing as the business getting the benefits it expected.

The 15 Failure Patterns

1. Everyone Agrees on the Project — But Not on What Success Means

This is one of the oldest problems in the business. At kickoff, everybody nods. The CEO wants better visibility. Finance wants a faster month-end close. Operations wants standardized processes. IT wants one platform. The implementation partner wants a successful go-live.

Everybody appears aligned. Usually, they aren't.

Those statements are intentions. They are not yet definitions of success. The disagreement normally doesn't show up during kickoff. It shows up months later. The project never established the difference between delivering the software and solving the business problem.

What I would do: Ask every senior stakeholder the same question: "Six months after go-live, what must be demonstrably different for you to say this project succeeded?" Put those answers in the same room.

2. Requirements Are Treated as a Workshop Instead of a Discipline

A project schedules a requirements workshop. People attend. Everyone talks. A document is produced afterward. Everyone signs it. Three months later somebody says: "That's not what we meant."

The organization confused having a conversation about requirements with actually engineering the requirements. A requirement isn't simply something somebody said in a meeting. It needs to describe something that can eventually be understood, challenged, built or configured, tested and accepted.

3. The Project Has a Sponsor in the Org Chart but Not in Reality

There is an executive sponsor in the project charter. But when an important decision needs to be made, nobody can get hold of them. That isn't really sponsorship. It is sponsorship on paper.

Eventually, every project reaches decisions that cannot be solved by the project team. Should we use the standard ERP process or preserve the old one? Do we keep the go-live date or delay it? Someone with organizational authority has to make the call. If that person isn't engaged, decisions start accumulating, and unresolved decisions eventually become schedule delays.

4. The Team Chooses the Solution Before Understanding the Problem

Software people naturally gravitate toward solutions. We like architecture. We like features. Business problems are usually much messier. Sometimes the right answer is configuration. Sometimes it is process change. Sometimes it is training.

For every customization request, ask what business outcome it supports, what happens if you don't build it, and whether standard functionality or a process change can achieve it. The best customization is often the one you don't have to maintain for the next seven years.

5. The Schedule Is a Political Commitment Disguised as an Engineering Estimate

"We need to go live on December 1." Why? "Because that's the date management approved." That is a business deadline. It is not an estimate.

You cannot negotiate with arithmetic. If the remaining work exceeds the available capacity, working harder is not a strategy. Something has to change: scope, capacity, sequence, date, solution approach, or risk tolerance.

Keep three numbers visible: Committed date, Forecast date, and Confidence/Risk level. If those three things are drifting apart, the organization needs to know early.

6. Key People Are "Available" on Paper but Unavailable in Practice

Resource plans can be wonderfully optimistic. In knowledge-intensive projects, you don't just have resources. You have critical knowledge. One person's availability is a project risk.

Ask: "If this person disappeared for two weeks, what work would stop?" The answers tell you where your real concentration risks are.

7. Dependencies Are Discovered Only When the Team Reaches Them

A project plan can look beautifully organized while hiding dependency chaos. The application is ready, but the API isn't. The migration script works, but nobody knows which source system is authoritative. For every important dependency, require: Dependency → owner → required-by date → evidence of readiness → consequence of delay → fallback.

8. ERP Customization Becomes the Default Answer

Six months later, the organization has effectively bought a new ERP and paid someone to rebuild the old ERP inside it. That isn't transformation. It's expensive nostalgia.

9. Data Migration Is Treated as a Technical Task Instead of a Business Responsibility

Data migration is partly software engineering, but it is also business governance. Only the business can decide which customer record is correct, which product is obsolete, and what constitutes a valid opening balance. A developer can transform data, but they cannot decide what the business means by "correct."

10. Testing Starts When Everyone Says Development Is Finished

Testing is not what happens after software development. Testing is one of the ways you discover whether what you built is actually correct. Teams often test features instead of business processes. An ERP can pass hundreds of individual functional tests and still fail the process that matters. Test the chain. Not just the pieces.

11. The Project Reports Activity Instead of Evidence

"127 tickets closed" sounds impressive but tells me almost nothing. The question I want answered is: What evidence do we have that the project is becoming more ready for production? Good evidence looks like: 85% of critical end-to-end scenarios passed, all opening balances reconciled, or production integration credentials validated.

12. Nobody Wants to Make the Hard Trade-Offs

Every project has limited capacity. Whenever new work enters the project, ask: "What are we moving, removing, funding, or accepting as additional risk to make room for this?" If the answer is "nothing," then the request isn't free. Someone is paying for it, usually the project team.

13. Architecture and Technical Debt Are Deferred Because "We Need to Deliver"

Technical debt isn't automatically bad. Sometimes a deliberate shortcut is exactly the right decision. The problem is unpriced debt. Someone says, "We'll fix that later," but nobody records what "later" will cost or who owns it. Eventually, the workaround becomes architecture.

14. Change Management Is Postponed Until Training

Training teaches someone how to perform a task. Change management deals with whether the organization is actually willing and able to work differently. When users say, "But we've always done it this way," that isn't automatically a training problem. It could be a process-design or leadership problem.

15. The Project Is Afraid to Tell the Truth

Everyone knows something is wrong. Nobody says it clearly. This is how projects die politely. Organizations develop a vocabulary for avoiding reality: "challenging," "being monitored," "resource optimization." Create an environment where bad news is valuable when it arrives early.

The Patterns Are Connected

The fifteen patterns above aren't independent. They often form a chain. People often argue about which individual item "caused" the failure. That's usually the wrong question. The project failed because the organization allowed a series of warning signs to accumulate unchecked.

A common ERP sequence demonstrates how a project can maintain a "green" status on paper while underlying risks slowly drag the actual project health down into a crisis at go-live.

A Practical Early-Warning Framework

When I look at a project, I tend to think about seven things. Together, these form a complete picture of project health that goes beyond what a standard PMO status report can tell you.

A Simple Project Health Scorecard

Spot early warning signs before they become serious problems. Use these questions to start an honest conversation about project health, challenge optimistic assumptions, and identify where closer investigation is needed.

From Quick Assessment to Detailed Diagnosis

These questions provide a starting point, not a complete project audit. When the warning signs point to deeper problems, use a structured health check to assess the evidence, score key risk areas, and agree on corrective actions.

How to Recover a Project

If you inherit the mess, resist the temptation to produce a recovery plan containing 147 actions. First establish reality.

1. Stop pretending the original plan is still authoritative. Create a factual snapshot: delivered, accepted, blocked, unknown.
2. Identify the critical business flows. Determine which flows are genuinely required for go-live.
3. Separate must-have from preferred. Treating all requirements as equally urgent is the fastest way to lose control of a recovery.
4. Rebuild the forecast. Estimate the remaining work from the evidence you have today.
5. Attack the biggest risks first. Work on the things that can actually change the outcome (e.g., critical unproven integrations).
6. Establish a short recovery horizon. Create the next meaningful checkpoint: "Within the next 3 weeks, we will demonstrate 5 critical end-to-end processes using migrated data."

Key Takeaways

• Projects usually fail gradually, not suddenly.
• Requirements problems are often symptoms of deeper alignment problems.
• A deadline isn't an estimate.
• Data quality is a business responsibility as much as a technical one.
• Technical debt is manageable when it is visible, owned and consciously accepted.
• Agile doesn't eliminate the need for governance, architecture, planning or accountability.
• Status reports should communicate evidence, not optimism.

Final Thought

After years in this business, I've learned that the most dangerous sentence in a project isn't: "We have a problem."

It's: "It's probably fine."

Problems are manageable once they're exposed. But a project that has learned to hide its problems from itself becomes extraordinarily difficult to recover. The job of a good delivery leader isn't to make the project look healthy. It's to know whether it is healthy.