Signs the project is in trouble
Warning signs usually appear well before a failure is declared. Look for repeated schedule resets without a changed plan, requirements that keep changing or were never signed off, test cycles that reveal the same defects again, data that will not reconcile, and users who stop attending sessions. After go-live, the signals are workarounds, shadow spreadsheets, and a month-end close that takes longer than before.
- Milestones move but the end date is declared unchanged.
- No one can say which requirements are done and which are not.
- Customizations keep growing to mimic the old system.
- Executives stop attending steering meetings.
Run an independent assessment
Before deciding anything, establish the facts. An assessment looks at five areas: scope and requirements, configuration and customization quality, data and integrations, testing and training, and governance and team. Interview the people doing the work and the people affected by it. Review documentation, the state of customizations, open defects, and the data migration reconciliation. A neutral party, not the team that built the system, should lead it, so findings are credible.
Consulting and advisory services →Diagnose the root cause
Most troubled projects share a few root causes: unclear scope and ownership, a team without the right skills or capacity, poor data, weak governance, or a mismatch between the product and the requirements. Distinguishing among them matters, because each calls for a different remedy. A governance problem is not fixed by adding developers, and a data problem is not fixed by retraining users.
Choose a path: repair, relaunch or re-implement
There are three broad options. Repair keeps the existing system and fixes specific problems, which suits a foundation that is sound but incomplete. Relaunch resets scope and plan on the current build, keeping what works and rebuilding selected parts, such as integrations or reporting. Re-implementation starts over on a clean design, which is justified when the structure is so compromised that fixing it costs more than rebuilding. Decide using the assessment, not frustration.
Implementation and integration services →Reset governance and rebuild trust
Whatever path you choose, reset how the project is run. Appoint an accountable sponsor, define a smaller scope that delivers value early, and set a regular cadence of steering meetings with honest status. Show progress with working software and reconciled data, not slide decks. Rebuilding the confidence of the business is as important as fixing the technical problems, since users who have been disappointed will not return unless they see something that works.
Change management and adoption →Decisions to settle at the start of a rescue
- Sponsor and decision rights. Name who decides scope and priority and has the authority to say no.
- Scope reset. Define the smallest set of capabilities that makes the system useful and deliver those first.
- What to keep. List the configuration, data, and customizations worth preserving, and those to retire.
- Commercial arrangement. Agree how the new work is estimated and paid for, with clear milestones.
A realistic first 90 days of recovery
- Days 1 to 30. Complete the assessment, agree the root causes, and choose repair, relaunch, or re-implementation.
- Days 31 to 60. Reset the plan and governance, stabilize data and critical processes, and deliver a first visible fix.
- Days 61 to 90. Deliver the first increment to real users, measure adoption, and plan the next increments from evidence.
Pitfalls to avoid
- Replacing the partner without diagnosis. A new team facing the same unclear scope will reproduce the same problems.
- Adding people to a late project. More people without a clearer plan adds coordination cost and rarely speeds things up.
- Hiding the status. Optimistic reporting delays hard decisions. Insist on honest assessments.
- Ignoring users. A technically fixed system that people avoid has still failed. Involve users throughout.
