Enterprise software projects fail for structural reasons, not technical ones: no single accountable owner, a scope that was never written down and so never stopped growing, decisions that took weeks because nobody had the authority to make them, a big-bang launch with no earlier release to learn from, and a vendor managed on price rather than on working software. The projects that succeed share one structure: one owner, a written scope with change control, a steering group that decides within a week, and a release every few months that real users touch.
The post-mortem of a failed enterprise software project rarely blames the technology. It blames the requirements that changed, the stakeholders who did not agree, the vendor who did not deliver, the integration that took three times as long, and the launch that went badly. Each is true and none is the cause. The cause is the structure the project was given at the start, which made every one of those outcomes likely. This post lists the causes, the symptom that shows each one early, and the structural fix, then sets out the governance that works.
What are the causes, and what do they look like early?
| Cause | Early symptom | Structural fix |
|---|---|---|
| No single accountable owner | The project is sponsored by a committee or by IT on behalf of a business unit that did not ask for it. Nobody's objectives change if it fails. | One executive owner from the business whose results depend on the outcome, with the authority to decide scope and the time to use it. |
| Scope never written down | The requirements document has 400 lines and everything is priority one. Nobody can say what release one contains. | A discovery phase that produces a written scope with explicit in and out lists, signed by the owner. |
| Slow decisions | The team raises a question and waits three weeks. The question is answered by a workshop that raises two more. | Named decision rights per topic and a steering group that meets fortnightly and decides within the meeting. |
| Big-bang delivery | The plan has a single go-live date eighteen months out, and nothing reaches users before it. | A release every three to four months that real users work with, starting with the highest-value slice. |
| Integration assumed simple | The plan allows two weeks for connecting to the ERP. Nobody has seen the ERP's API. | Integration mapped in discovery, spikes on the riskiest connections in the first month. |
| Data ignored until migration | Migration is a line at the end of the plan. Nobody has profiled the data. | Data assessed in discovery, cleaning started in parallel with the build, three rehearsal migrations. |
| Vendor managed on price | The lowest bid won. Change requests appear in month two. The relationship is adversarial by month four. | Vendor selected on process and evidence, contract with change control, progress measured in working software. |
| Users meet the system at launch | No prototype was tested. Training is scheduled for the week before go-live. | Prototype tested in discovery, users in every release review, adoption planned from month one. |
| Key people on both sides change | The sponsor moves roles. The vendor's lead is reassigned. Context is lost. | Decisions and scope in writing, a second person in the loop on each side, continuity written into the contract. |
Each symptom is visible in the first two months. Signs your development project is going wrong lists the later ones, by which time the fix is more expensive.
What governance actually works?
Governance is where enterprise projects either become manageable or become theatre. The version that works is small.
- One accountable owner. A senior person from the business side whose own objectives include the outcome. They own the scope, chair the steering group and are the person the vendor escalates to. If the owner cannot give the project four hours a week, the project does not have an owner.
- A steering group of five or fewer. The owner, the IT lead, the finance representative, the vendor's delivery lead and one senior user. It meets every two weeks for an hour, reviews working software, and makes the decisions on the list. Decisions not made in the meeting are made by the owner before the next one.
- Written decision rights. Who decides scope, who decides technical standards, who decides on data, who decides on budget movements under a threshold. Written down once, at the start, so questions go to a person rather than to a meeting.
- A single plan everyone can see. Phases, releases, the open decisions and the risk register, in one place, updated weekly by the delivery lead. Status reports are a summary of it, not a separate document.
- Working software as the measure. Progress is what users can touch in the demo environment, not percent complete. A project that cannot demo is behind, whatever the report says.
Larger programs add a program board above the steering group that meets quarterly and approves phases and budget. It should never make day-to-day decisions, and the steering group should never wait for it.
How do you control scope without freezing it?
Scope will change, because the business learns what it needs by seeing the software. The failure is not change, it is unmanaged change. The structure that handles it has three parts. First, a written scope from discovery, with in and out lists, so that any request can be checked against it. Second, a change process with a form, an impact estimate from the vendor within a week, and a decision by the owner, with a contingency budget of 15 to 25 percent to pay for approved changes. Third, a deferred list, where good ideas go to wait for release two, visibly, so that nobody has to argue them into release one. MSA, SOW and change requests covers how to put this into the contract.
The owner's job is to say no to most changes and yes to the few that matter, in writing, quickly. Projects fail when that job is left to the vendor, who is paid to say yes, or to a committee, which says nothing.
Who should do what between the vendor and your own people?
| Responsibility | Your organization | Vendor |
|---|---|---|
| Business outcome and scope decisions | Owns | Advises, estimates impact |
| Process and user knowledge | Provides, through named people with time allocated | Elicits, documents, designs against |
| Technical standards and security | Sets and reviews | Designs and builds within them |
| Access to systems and data | Provides on a schedule | Requests early, in writing |
| Delivery, quality and demos | Reviews every two weeks | Owns |
| Data cleaning | Owns the decisions, often the work | Profiles, tools, migrates |
| Adoption and training | Owns, with champions in each team | Supports with materials and presence at rollout |
| Running the system afterwards | Decides the model | Supports under an SLA, or hands over |
The common failure is a client who delegates the left column to the vendor, usually because their own people have no time allocated. The vendor cannot own your business outcome, your data decisions or your users' adoption, and a project set up as if they can is set up to fail. Dedicated team vs project-based vs staff augmentation looks at how the engagement model shifts this split.
What does a project that does not fail look like?
- Discovery first. Three to eight weeks producing a written scope, a tested prototype, a system map and an estimate with a range. The discovery phase describes the deliverables.
- The riskiest integration spiked in month one. If the ERP connection is going to be hard, everyone knows in week four, not week forty.
- A release every three to four months. Real users, real data, one slice of the whole. The second release is planned from what the first one taught.
- Data work in parallel. Profiling, cleaning and rehearsal migrations run alongside the build, owned by someone on your side.
- A steering group that decides. Fortnightly, an hour, working software on the screen, decisions in the minutes.
- Adoption planned from the start. Champions named, old system retirement dated, training built into the releases.
- A contract that expects change. Change control, contingency and a deferred list, rather than a fixed scope that both sides know is fiction.
None of this is expensive. All of it is unusual, because it requires the client to allocate senior time before the project is in trouble rather than after. Why software projects go over budget shows what the alternative costs.
Five questions before you approve the project
- Who is the single owner, and how many hours a week have they committed?
- Is there a written scope with an out list, and who signed it?
- When does the first release reach real users?
- What is the contingency, and who can spend it?
- Has anyone looked at the data and the ERP's API yet?
If any answer is missing, the project is not ready to start, however good the vendor.
How 7L approaches this
7L International designs, builds and supports custom software for established organizations from business hubs in New York, London and Athens. We were founded during the Greek financial crisis, have supported more than one hundred organizations since, and have seen projects fail for every reason in the table, sometimes from the inside. Our response is structural: a paid discovery with a written scope, a release every few months, a steering group we insist on, integration spikes in the first weeks, and incremental modernization rather than a single cutover. The enterprise software development guide shows how those fit into a whole program. If you are about to approve a project and some of the five questions above have no answer, talk to us before you sign.
Frequently asked questions
What is the single biggest reason enterprise software projects fail?
The absence of a single accountable owner from the business side with the authority to decide scope and the time to do it. Without that person, decisions take weeks, scope grows unchecked, the vendor is managed on price rather than outcome, and nobody's objectives depend on the system working. Most other causes trace back to this one.
How often do enterprise software projects fail?
Roughly half of large software projects overrun their budget or schedule, and a meaningful share are cancelled or delivered without being adopted. The exact figures vary by study and definition, but the pattern has been stable for decades. What has changed is that the structure of the projects that succeed is now well understood, and it is not technical.
Is a fixed-price contract safer for a large project?
Only after discovery, and only for one phase at a time. A fixed price for an eighteen-month program on a requirements document shifts risk to the vendor, who prices it in or recovers it through change requests, and gives both sides an incentive to argue about scope instead of building. A fixed price for the first release after discovery, with time and materials or a fresh fixed price for each phase after, is safer for both.
How do we stop scope creep without blocking necessary changes?
Write the scope down with an explicit out list, hold a contingency of 15 to 25 percent, and run a change process where the vendor estimates impact within a week and the owner decides. Keep a visible deferred list so good ideas have somewhere to go other than release one. The owner says no to most changes, yes to the few that matter, and does so in writing within days.
Should we pause a project that is showing these symptoms?
Pause and fix the structure rather than cancel. Appoint the owner, run a short re-scoping exercise to produce the written in and out lists, set up the fortnightly steering group, and get a first release to real users within three months. Projects that have burned budget usually still have working software in them. What they lack is a structure that lets it reach users.