Executive answer
How can an undocumented process step delay an SAP project?
Experienced users can omit a step because it feels automatic, while the implementation partner builds from the documented sequence. Anita Anello illustrates this with a ten-step sales-order process. Recovery makes the missing business logic explicit, validates the requirement with both parties, and separates necessary functionality from assumptions about customization.
In my episode on overcoming SAP escalations, I described a familiar situation: a business has used its legacy system for twenty or thirty years. The people doing the work know the process so well that part of it has become second nature. When they explain it, they can leave out a step without realizing anything is missing.
The implementation partner does not have those decades of context. It receives a sequence that looks complete. The business expects the new system to reproduce an operation it understands instinctively. Later, both parties discover that they were working from different accounts of the same requirement.
Nobody needed to be careless for that gap to emerge. Deep operational knowledge and deep technical knowledge are different kinds of expertise. A transformation project needs a way to translate between them.
When that translation is missing, a process question can become a customization argument, a testing problem, and eventually a dispute about who failed to deliver. The recovery question is not simply whether the requirement was written down. It is whether both parties understood the business event it was meant to support.
How does a complete-looking process hide an incomplete requirement?
In the episode, I used an illustrative sales-order process with ten steps. Someone documenting that process may skip one because it happens automatically in their mind. The document reflects what they remembered to explain—not necessarily everything that makes the operation work.
This is particularly relevant when a long-established legacy system has been customized around the company’s way of doing business. The user experiences the whole process. The partner sees only what has been described and demonstrated. An undocumented dependency can sit between those two perspectives.
A useful review therefore follows an actual business scenario from beginning to end. What initiates the order? What information is needed? Which handoff happens next? What changes when the normal sequence cannot be followed? These are questions for discovering the requirement, not a generic prescription for how every company should process sales orders.
The goal is to surface the knowledge that experienced employees carry, without treating their familiarity as a fault. That knowledge is an asset. Recovery gives it a form the implementation team can use.
Why can both parties say yes and still mean different things?
In my conversation with Karl Lewis, I described end users and technical specialists using the same words without speaking the same language. The business explains a familiar process. The technical specialist understands a possible build. Agreement at that level can conceal a difference in assumptions.
For the business, “it works” may mean that the whole operation runs correctly, including its exceptions and downstream effects. For a specialist, a discussion may initially focus on whether a particular function can be configured or developed. Both perspectives are necessary. Neither should be assumed to stand for the other.
That is why I describe part of my escalation work as translation. I listen to what each side understands, identify the gap, and help turn it into a shared requirement or decision. Repeating the same explanation more firmly will not resolve a difference in meaning.
Technical issues still need technical remediation. Translation makes the issue sufficiently clear for that remediation to address the business need, rather than merely close the argument.
Does the business need a customization—or a better decision?
The answer depends on the requirement. Some companies have genuinely differentiating processes or obligations that the solution must support. Others are carrying forward a familiar sequence without having tested whether a different process could meet the need. Neither possibility should be decided by assumption.
Karl described a project in which department requests were accumulating without a clear review of their value, cost, or business impact. His intervention brought the executive into discussions about how frequently a task occurred, how long manual execution took, and what automation would cost and save.
That story belongs to Karl. Its lesson for executive oversight is specific: a request needs a decision structure between “I want it” and “build it.” The team must distinguish a requirement for operating the business from an enhancement that can wait.
A clear review protects both parties. The business can explain what matters and why. The partner can make the implications visible. Leadership can authorize a trade-off with the context it needs, rather than leave the working team to settle it through repeated debate.
What should leaders ask when the same process dispute keeps returning?
A recurring disagreement deserves a closer examination of the requirement, not another general request to collaborate. These questions help locate the gap:
- Can the business and partner walk through the same actual scenario together?
- Which steps or exceptions rely on knowledge that is not in the agreed documentation?
- What outcome must the process protect, and what evidence will demonstrate it?
- Which proposed changes are essential for go-live, and which can be considered later?
- Who can approve the cost, scope, and operational trade-offs?
- How will the agreed decision reach the people building, testing, and using the process?
What changes when trust has already broken down?
When a project has been delayed repeatedly, a process question can arrive carrying years of frustration. The customer may hear another request for time or money. The partner may hear another change to something it believed was settled. The underlying issue becomes harder to discuss because each new conversation is interpreted through the history.
In my solo episode, I explained that I begin by assessing both sides: what has happened, what each party understands, what has been accomplished, and where the roadblocks remain. Team members, leadership, or business processes may have changed during a long implementation. The current recovery plan has to reflect the situation now.
Acknowledging completed work does not mean overlooking gaps. Respecting both parties does not mean avoiding accountability. It establishes a basis on which the facts can be discussed without prejudging the explanation.
If contractual obligations or threatened litigation are involved, the company’s legal counsel must handle the legal questions. Independent recovery support focuses on making delivery facts, communication, and decisions usable again. Those roles should remain distinct.
How does understanding become forward movement?
The purpose of translation is action. In the episode, I emphasized helping the business and partner re-engage, realign priorities, and put a plan into motion. A more accurate description of the issue is valuable when it produces a decision the team can execute.
That also means respecting the people who are running the business while implementing SAP. I described the pressure as doing two jobs at once. Recovery should not assume unlimited staff capacity or treat another meeting as progress by itself.
My De-Escalation Breakthrough Formula™ provides the broader structure: Discover, Diagnose, Design, Deploy, Deliver. The process gap must be found, its cause understood, the recovery decision designed, the agreed action put into practice, and the result checked. It is not a substitute for the technical work or a promised timetable.
A credible next step is one that both parties can explain in the same terms: what is changing, who owns it, what it enables, and how they will know it worked. That is when a conversation about a stuck process begins to become a recovery path.
If the same business-process disagreement is still blocking progress after repeated meetings, a confidential private briefing can begin there. Anita can assess whether the project needs independent translation, executive alignment, and a clearer path from unresolved requirements to owned recovery decisions.
The five pillars of Anita’s recovery formula · Restoring delivery when partner trust breaks down
Adapted from Anita Anello’s solo episode “Overcoming Escalations in Your SAP Project” and her conversation with Karl Lewis. The sales-order sequence is an illustrative example, not a named client case. Karl’s customization-review example is attributed to him; executive questions are editorial applications of the discussion.