Five ways custom enterprise software development projects fail, and how to avoid each

Custom enterprise software development fails in five recognisable ways: a scope that was written but never designed, integrations discovered in month three rather than week one, data migration treated as a tail-end task, a cutover with no rehearsed rollback, and a launched system that nobody internally owns. Each pattern has an early symptom and one specific decision that prevents it.

None of these are technology failures. We have watched all five happen on stacks that were entirely reasonable, and we have watched sound programmes survive genuinely awkward technology. What follows is the symptom, the mechanism and the preventive decision for each, with the point in the calendar where the decision has to be made.

Failure one: a requirements document that was never a design

The symptom is a specification of four hundred numbered statements, each individually true, with no process map, no domain glossary and no worked example of a single transaction moving end to end. Every stakeholder recognises their own paragraph and nobody has read the whole thing.

The mechanism is that ambiguity survives signature. Two departments both approve a clause about approval limits while meaning different things, and the disagreement surfaces in the sprint that builds it, by which point it is a change request rather than a conversation. Requirements documents record positions; designs resolve them.

The preventive decision: end discovery with a domain model and a walked-through transaction, not a document. Lock the scope on that artefact, as described in scope lock, and treat any later addition as a trade with something removed rather than as an increment.

Failure two: integrations discovered in month three

The symptom is a plan with a single line item called interfaces. Three months later the team finds that the finance system exports a fixed-width file at 11pm, the CRM belongs to a vendor with a quarterly release train, and one critical feed is a person copying a spreadsheet into a shared drive.

The mechanism is that integration cost lives almost entirely outside the code. Every interface needs an owner on both sides, an environment, a payload contract, an error and retry policy, and agreement about what happens when the other system is down at month end. None of that is visible from a requirements list, and all of it consumes elapsed weeks rather than effort hours.

The preventive decision: build the integration inventory during discovery, with a named owner per interface, and price interfaces separately from features. Where the incumbent has no API, put one in front of it rather than reading its tables, the pattern described in adding an API layer to a legacy monolith.

Failure three: data migration treated as the last task

The symptom is a migration line in the final fortnight of the plan. The first trial load runs four weeks before go-live, twenty per cent of records fail validation, and the choice becomes slipping the date or launching with data the business does not trust.

The mechanism is that migration duration is governed by source data quality, which is unknowable until a load runs. Duplicate customers, missing tax identifiers, dead product codes and three spellings of the same city are normal in a system that has run for a decade. Cleansing them is usually your team's work, not the supplier's, and nobody has been told.

The preventive decision: profile the source data during discovery and run the first trial load by week six, with reconciliation signed off by finance rather than engineering. Our post on cleansing before you move sets out the sequence. Where the legacy code itself is the source of truth for undocumented rules, characterisation tests capture the behaviour before it is reimplemented.

Failure four: a cutover with no rehearsed rollback

The symptom is a go-live plan written as prose, with a rollback section that says revert to the previous system. Nobody has timed the steps, nobody has agreed the point of no return, and the first execution of the plan is the real one on a Saturday night.

The mechanism is that cutover is an operational procedure, and procedures that have never been executed contain undiscovered dependencies. Once transactions have been written into the new system, reverting means reconciling two sets of records rather than flipping a switch, which is why an unrehearsed rollback usually is not one.

The preventive decision: rehearse the runbook at least twice against production-shaped data, time each step, agree the reversal trigger and who may pull it, and phase the go-live by module, region or user group so the blast radius stays small. Define the success and failure conditions numerically before launch; Google's SRE guidance on service level objectives is a useful primary source on why an agreed target beats a subjective judgement of whether things are going well.

Failure five: nobody internal owns the system

The symptom appears six months after launch. Enhancement requests accumulate in an inbox, two teams keep a parallel spreadsheet because the system does not quite fit their exception, and the supplier is asked to answer questions that are really business-policy decisions.

The mechanism is that custom software encodes business policy, and policy needs an owner who triages requests, signs off releases and says no. Without that role, the application stops matching the business within two years and the organisation concludes the build failed, when what failed was the operating model around it. This is the adoption pattern covered in why enterprise software implementations fail on adoption.

The preventive decision: name the owner before the contract is signed, give them a standing enhancement budget, and move the system onto a support contract with defined response times at the end of hypercare rather than leaving it with the build team informally.

The five patterns side by side

Early warning signs worth acting on

• Acceptance decisions take more than 48 hours. Decision latency compounds across every sprint and is the cheapest delay to fix.
• Nobody can name the owner of a given interface. If the answer is a team rather than a person, treat the interface as unscoped.
• The demo is always the same screen. It means slices are not reaching production behaviour, only the user interface.
• Test data is invented rather than extracted. Synthetic data hides exactly the defects a real migration will expose.
• The security review has no date. Unscheduled reviews become four-week delays at the worst possible moment.
• Training is scheduled after acceptance. Users who first see the system during acceptance turn acceptance into a second requirements exercise.
• Change requests are approved without a trade. Scope that only grows is scope that will not land on the committed date.

When the project was never the right thing to do

Some failures are correct outcomes arriving late. If the process being automated is genuinely standard, such as payroll, statutory reporting or GST e-invoicing, a custom build was the wrong call and no amount of delivery discipline rescues it. If two departments fundamentally disagree about what the process is, software will not adjudicate; it will encode whichever version was written down first and be resented by the other side.

And if the transaction volume is low, the arithmetic does not work however well the programme runs. An honest supplier says so during discovery, which is precisely what a paid discovery is for. Our post on build or buy for custom enterprise software covers how to reach that judgement before the money is committed.

What avoiding these costs

Prevention is cheap relative to the programme. A ten-day Sprint Zero at $3,250 or ₹2,00,000, credited against the build, produces the domain model, the integration inventory and the data profile that neutralise the first three patterns. A three-week ProofRun at $6,250 or ₹4,00,000 tests the riskiest interface in isolation. Full custom and enterprise software development starts at $24,500 or ₹16,00,000, with starting prices for every service on the pricing page. Pattern five is prevented by a Care Plan from $1,000 or ₹68,000 a month, which is what turns a launched project into a supported system.

A programme that avoided all five

A university with a fifteen-year-old ERP had every ingredient for a big-bang failure: an academic calendar with no quiet window, undocumented rules embedded in old code, and a business that could not stop. The programme put an API layer in front of the incumbent, moved workflows out in slices, ran both systems in parallel through a term, and phased each go-live into a gap in the calendar. The result is written up as modernising a university ERP without a rewrite.

Related reading

The practical implementation guide sets out the phase sequence these failures interrupt, and how long custom enterprise software development takes explains where the weeks actually go.

Every one of these five failures is decided in the first three weeks of a programme and only becomes visible in the last three.