Start an ERP Recovery Conversation With Facts

An ERP recovery conversation earns trust when the discussion begins with the operating problem and the decisions holding work up. A missed milestone has many possible causes. Process ownership might be weak. Finance might hold an unresolved policy choice. A supplier dependency might block a build. Status reporting might hide the actual issue. A director needs confirmed facts before offering diagnosis, rescue, replacement, or a new plan.

Ask the executive to describe impact in operational terms. Which team cannot complete work? Which date matters? What happens when the date moves? Which decision would release the blocked work? Avoid starting with a question about software features. The people on the call often already have strong views about tools. Your role is to establish the work, evidence, and authority behind those views.

Ask how the program describes progress today. Some groups report percentage complete. Others report completed scenarios, signed decisions, or tested transactions. Those measures tell different stories. A ninety percent complete status report means little when a single unresolved finance decision prevents testing. Ask for the last steering committee pack and the latest milestone plan. Read the stated reason for delay, then ask who agrees with such reason.

In a fictional first call, COO Priya says, “We are two milestones behind, and every meeting turns into an argument between Finance and the technology group.” Director Marcus replies, “I hear a delivery issue and a question about decision authority. Which milestone is blocked today, and what decision does progress require?” Priya says user acceptance testing cannot begin because Finance has not agreed whether a redesigned approval process belongs in the current phase. Marcus asks who owns the phase decision. Priya names the program sponsor, the finance director, and the chief information officer.

Marcus follows with a practical question. “What evidence has each leader seen?” Priya says Finance received a process map, the technology group received a technical impact note, and the sponsor received a slide with no recommendation. The gap is clear. Leaders are reviewing different materials. Marcus says, “A shared decision needs a shared fact base. I would ask those leaders to review the documented scope, the process impact, and the date impact in one session.” Priya agrees because the request connects directly to the blockage.

Do not assume the current systems integrator caused the problem. Ask what work the provider owns, what work client teams own, and which decisions depend on third parties. Ask when the current contract ends, what notices apply, and whether any supplier dispute exists. A buyer sometimes wants an outside firm to validate a decision already made. A director should know the motive before proposing work.

In a fictional example, Priya says the integrator keeps missing estimates. Marcus asks for two recent examples. The first involves a late interface build after a business rule changed. The second involves a test environment delay owned by an internal infrastructure team. Marcus reflects the distinction. “One issue concerns change control. One concerns internal readiness. Both affect delivery, yet each has a different owner.” Priya sees why replacing a provider alone would not resolve every delay.

Prepare for a diagnostic meeting with a short, factual agenda. Begin with the current milestone and the outcome expected at such point. Review the last approved scope. List decisions awaiting approval. Identify evidence supporting each decision. Name dependencies, owners, and dates. End with the next decision required from the sponsor. This structure gives people a way to discuss difficult issues without turning the meeting into a debate about blame.

Ask each attendee to bring one source document. The sponsor brings the approved business case or phase charter. Finance brings process decisions or policy constraints. The technology group brings the delivery plan and technical dependencies. The program lead brings the risk and issue log. The systems integrator brings current work status and open requests. No one needs to prepare a polished presentation. The session needs source material, clear explanations, and people with authority to confirm facts.

During the meeting, separate facts from interpretations. “Testing has not started” is a fact. “The technology group does not care about Finance” is an interpretation. Write both when necessary, then ask for evidence behind the interpretation. A finance leader might say approvals arrive late. Ask for the last three decisions, the requested date, and the final date. A delivery leader might say scope changes too often. Ask which changes entered after design approval and who authorized those changes. Specific examples calm a room faster than general accusations.

Use a decision log. For each unresolved decision, record the question, the choices under review, the evidence needed, the accountable leader, and the deadline. A fictional log entry might read as follows. Phase scope for redesigned approval workflow. Choices include current phase or later phase. Process impact and test estimate required. Finance director accountable. Decision due Friday. The wording does not settle the issue. The wording makes ownership visible.

Pay attention to the decision path. A program sponsor might own an escalation, while Finance owns policy approval and the technology group owns a build estimate. Do not label one person as owner when three separate approvals exist. Map each approval separately. This prevents a future meeting where everyone assumes somebody else had authority.

When a buyer asks for an immediate recovery plan, tie the answer to the evidence. In a fictional follow up, Priya says, “Send a plan for getting us back on track.” Marcus replies, “The next plan should follow confirmed scope and decisions. First, the sponsor, Finance, and the technology group need to settle the approval workflow. Then the delivery team needs an estimate based on the resulting choice. I will propose a diagnostic session built around those steps.” Priya accepts because Marcus has named a route from the present issue to a plan.

After the session, send a plain record within one business day. State the milestone at risk, the confirmed blockers, the open decisions, the decision owners, and the evidence each owner promised. Avoid a polished narrative which blends facts and assumptions. Ask attendees to correct the record by a stated date. Their corrections often reveal a hidden dependency before further work begins.

Review your own call notes. Every proposed activity should connect to a stated problem, a source of evidence, and an accountable owner. Remove activities built only on a general request for help. A diagnostic engagement earns value when leaders see how each conversation moves an unresolved decision toward closure.

Practice with a fictional program. Ask a colleague to play a COO who blames the integrator for every delay. Prepare three hidden facts for the colleague: one delay belongs to a client decision, one belongs to a technical dependency, and one has no evidence yet. Ask questions until you sort all three. Finish by proposing attendees and documents for a single diagnostic session. Listen to the recording. Check whether your words separated confirmed facts from assumptions and whether every next action has an owner.