What should you do when a software implementation is failing?

What is happening

A failing implementation usually announces itself in a familiar way. Go-live slips. The vendor and the internal team describe the same status differently. Users continue running the old process in parallel. Reporting requires manual assembly. Every meeting produces new requirements rather than closed decisions.

Underneath that, the system is generally doing exactly what it was configured to do. What has broken down is the set of agreements surrounding it: who defines the process, who approves a configuration change, who is accountable for adoption, and what the implementation was supposed to make measurably better.

Why it happens

• Requirements were captured as feature requests rather than as a description of how the work should run.
• The process being automated was never agreed on, so the configuration encodes a process nobody follows.
• Ownership is split — IT owns the platform, a business unit owns the outcome, and no one owns the decisions in between.
• The vendor was asked to lead a change effort that only the organization can lead.
• Success was defined as deployment rather than as a business result.
• Adoption was treated as training rather than as a change to how people are managed and measured.

What to do first

• Freeze new scope. Nothing is added until the current state is understood.
• Write down the current state: contracted scope, configured state, open decisions, open defects, and the business outcome originally expected.
• Build a decision log of everything unresolved, with a named decision owner and a date for each item.
• Separate defects (the system does not do what it should) from design gaps (the system does what it was told, and that was wrong) from adoption gaps (it works and nobody uses it).
• Identify one accountable business owner for the outcome, not just a project manager for the schedule.
• Re-establish a single reporting cadence that both the vendor and internal teams work from.

What not to do

• Do not replace the platform before you understand why the current one is not delivering. A replacement inherits every unresolved process and ownership problem.
• Do not add people to a project that is failing on decisions rather than on capacity.
• Do not escalate without a written statement of what decision you need from the executive you are escalating to.
• Do not let training substitute for process design.
• Do not measure recovery by activity. Measure it by decisions closed and workflows actually in production use.

Questions to ask

• What specific business outcome was this implementation supposed to produce, and who agreed to it?
• Which decisions are currently open, and who owns each one?
• Is the process we configured the process the organization actually follows?
• What percentage of the intended user population is working in the system today, and for what?
• What are people still doing outside the system, and why?
• If we went live tomorrow exactly as configured, what would break?

Warning signs

• Status reports are green until shortly before a milestone slips.
• Requirements documents keep growing and never get signed.
• The same issue is raised in consecutive steering meetings without resolution.
• Users maintain shadow spreadsheets covering the same data as the new system.
• The vendor's issue list and the internal issue list do not match.

When internal teams can handle it

Internal teams are well positioned when the problem is bounded and ownership is clear: a defined defect list, a known process owner with authority, and a sponsor who can close decisions quickly. If you can name the accountable owner and list the open decisions in one page, you likely do not need outside help.

When outside help may be appropriate

Outside help tends to be warranted when the problem crosses departments, when the vendor relationship has become adversarial, when multiple prior attempts have not worked, or when the organization cannot get a straight answer about what state the implementation is actually in. An independent party can establish the facts without carrying a stake in whose earlier decision caused the gap.