The Quality Problem Is Not a Software Problem

SAP implementation failures are well documented, and the recurring pattern is consistent enough to be usefully instructive to SAP consultancies and individual consultants.

When organizations conduct a post-mortem on an SAP project failure the reasons often point to governance that existed officially but not in practice, including scope that expanded without adequate controls, data migration that was underestimated, and a consultancy relationship that either lacked the seniority to hold the client to standard processes or the commercial position to try. The software is not usually the essential problem, but rather the organizational system around implementing and running it.

What distinguishes the practices that consistently deliver is the degree to which quality disciplines are truly operational: built into the project structure, team composition, contractual commitments, and governance from the first week of engagement.

Methodology Discipline

SAP Activate gives every consultancy the same structural foundation, phased delivery, fit-to-standard workshops, quality gates, SAP Cloud ALM as the governance instrument.

The gap between SAP practices is what they do with that basic framework. In strong engagements, quality gates are binary “go/no” decisions backed by documented evidence. In weaker ones, they are merely milestone sign-offs that record completion.

SAP’s RISE with SAP Validated Partner program represents the current standard for distinguishing methodology adherence from methodology performance. Partners must adopt the RISE with SAP Methodology globally across all delivery teams, document clean core quality gates in SAP Cloud ALM, maintain current certifications across key delivery roles, and satisfy bi-annual performance checks.

KPMG’s validation in spring 2025 required a six-month review of their full delivery methodology before SAP confirmed alignment. The program then enrolls validated partners in SAP’s Global Customer Adoption Program, providing continuous project health monitoring throughout delivery, a second layer of quality oversight that operates independently of the partner’s own reporting.

Fit-to-standard workshops are the first test of a consultancy’s methodology discipline. In quality engagements they function as process governance events: every requirement is documented, assessed, and tagged in SAP Cloud ALM, creating traceability from the Explore phase through to production deployment. The workshop is where the consultancy’s business process expertise either earns its credibility or reveals its limits. 

Practices that treat these sessions as client satisfaction exercises, capturing requirements without challenging those that drive unnecessary customization, are accumulating issues like technical debt from the first substantive project interaction.

Clean Core and Integration Governance

Clean core governance requires strong practices to establish a Solution Standardization Board in the Prepare phase and apply SAP’s A–D extension classification framework to every custom development decision from that point forward.

Level A extensions use only released APIs, are fully upgrade-safe, and represent the target for all new development. Level B uses classic but documented SAP APIs, acceptable with governance sign-off and monitoring in place. Level C accesses SAP internal objects, carries meaningful upgrade risk, and belongs on a remediation roadmap rather than in the permanent architecture. Level D (modifications, implicit enhancements, and direct writes to SAP-delivered tables) creates severe upgrade exposure and requires a retirement timeline wherever it exists. Every development request is classified before design work begins, and that classification is recorded in SAP Cloud ALM.

The two-question test that quality practices apply before any customization proceeds to design is straightforward: can standard SAP functionality meet this requirement, and if not, can a Level A or B extension cover it?

Only when both answers are no should deeper customization enter the conversation, and even then it requires governance approval. Business process owners must participate in that assessment, understanding that a customization request carries a long-term maintenance cost and an upgrade risk.

Integration decisions require the same degree of discipline. Strong practices build on released OData and SOAP APIs, favor side-by-side extensibility via SAP BTP over tight coupling to the core, and implement event-driven design where processes cross system boundaries. Error monitoring and resolution capability through SAP Application Interface Framework (specifically for interface and message monitoring) is configured before go-live. Legacy integration patterns, RFC-heavy, point-to-point IDoc connections, are not refused categorically, but they require the same governance sign-off as Level B and C extensions.

Strong practices have a documented position on what they will and will not build, and that position is known to their delivery teams and communicated to clients at the start of an engagement.

When a client overrules a recommendation against a Level D modification, the consultancy documents the client’s decision, records the upgrade risk in SAP Cloud ALM, and does not present the outcome as a quality-governed deliverable. A consultancy that succumbs to client customization pressure, because the relationship is valued or the commercial stakes feel high, has delivered a potential problem, and not a quality SAP implementation.

Project Governance and Scope

Scope expansion is the most consistently cited driver of SAP project overruns, and it is almost always preventable.

The blueprint that gets revised rather than governed after sign-off, the requirements session that functions as an open wish-list, the change request approved commercially before its quality impact is assessed, are all governance failures, and they occur in the Explore and early Realize phases. Go-live is where they become visible and expensive.

Strong practices establish a steering committee with genuine decision-making authority. The business case produced at project inception stays live throughout delivery as the reference point for every scope decision, because the moment it is overlooked scope will drift, leaving no shared standard against which to measure proposed additions.

In quality engagements the risk register is reviewed and updated at every governance cadence, with owners named, mitigations tracked, and escalation paths defined. A risk register that grows without review is not risk management, it is risk documentation, which is a different activity with a much lower value. The project manager on a quality engagement has the seniority and mandate to hold the consultancy’s own delivery teams to methodology standards, not only to manage the client relationship. That internal accountability is as important as the external one.

Early warning signals of governance drift are readable from the Explore phase if anyone is looking for them. These signs include requirements documentation that grows substantially after Explore closes, ATC exception logs accumulating without scheduled review, or steering committee packs presenting status without revealing decisions. 

Each of these individually is a signal. More than one simultaneously is a pattern. The same patterns reaching Realize are costly.

The Most Under-Resourced Delivery Disciplines

These three disciplines share a common cause when they fail: commercial pressure applied to the wrong variables. Testing gets compressed when schedules slip. Data migration complexity gets underestimated when scoping is optimistic. Senior consultants get substituted for junior ones when day rate budgets tighten. In each case, the cost of the saving is paid at go-live or shortly after, at a cost many times what the saving was worth.

Strong practices define test coverage criteria in the SOW as binding acceptance conditions for the Deploy quality gate. Test cases are generated from fit-to-standard requirements documented in SAP Cloud ALM, creating direct traceability from business requirement to test scenario. Performance and volume testing runs against realistic production-representative transaction loads. Defect severity classifications and resolution SLAs are agreed with the client before Realize begins, so defect triage during UAT does not become a commercial negotiation at the most pressured point of the project.

Data migration quality requires a documented RACI before migration work starts. The consultancy owns the tooling, the validation framework, and the migration rehearsal process. The client owns the legacy data and the cleansing decisions. That boundary, left undefined, produces the most common data migration failure mode: a go-live weekend where both parties discover they had different assumptions about who was responsible for data that turns out to be wrong. Staged migration rehearsals with documented reconciliation outcomes at each stage give both parties visibility of the actual data quality position before cutover. The cutover plan, including rollback criteria, is reviewed at the Deploy quality gate, not drafted the week before go-live.

There is a real shortage of consultants with genuine S/4HANA delivery depth at senior functional and solution architect level, distinct from ECC experience being presented as current S/4HANA competence. Practices filling senior delivery roles with consultants at the limit of their S/4HANA experience are making a quality governance decision with landscape-level consequences.

SAP’s recertification program, under which all certifications issued before April 2024 expired in March 2025, means practices that managed recertification proactively now hold a demonstrable currency advantage. Those that did not face a certification gap at the precise moment S/4HANA delivery demand is at its highest.

Knowledge Transfer, Change Management, and the Business Process Owner Problem

Knowledge transfer built into every project phase and knowledge transfer delivered as a go-live activity produce fundamentally different outcomes. The difference can be seen in whether the client’s team can operate the system independently three months after go-live, or whether the consultancy is still receiving calls that should be handled internally.

Documentation of the delivered solution (such as configuration rationale, extension classifications, integration design decisions, and data migration logic) is produced as each workstream closes in SAP Cloud ALM, before the final project weeks when cutover absorbs the team’s attention. Role-based training is built around the specific delivered configuration. CoE readiness is defined as an explicit exit criterion for project closure, with measurable conditions: that the client’s team can execute core business processes without consultancy support, manage a clean core health review independently, and own the governance model for future extensions.

The business process owner engagement problem deserves direct attention because it is a common source of both unnecessary customization and post-go-live adoption failure, and it is something for which a consultancy is accountable.

A fit-to-standard workshop facilitated without adequate BPO preparation produces resistance, escalation, and requirements that drive customization the architecture does not need. The same workshop, facilitated with evidence-based process recommendations drawing on cross-industry SAP experience, produces informed decisions. The quality of that facilitation is the consultancy’s responsibility. BPOs who leave the workshop without understanding why the standard SAP process serves their business better than their current one will relitigate that question throughout Realize, at hypercare, and in the first post-go-live steering meeting.

Hypercare and the Go-Live to BAU Transition

Hypercare defined by contract expiry rather than exit criteria is one of the most reliable indicators that a consultancy’s quality system ends at go-live. Strong practices document hypercare scope, team composition, severity classifications, response SLAs, and exit criteria in the SOW, before go-live, when commercial leverage on both sides is balanced.

Entry into hypercare requires completion of the Deploy quality gate in SAP Cloud ALM. The hypercare team includes functional consultants and the client-side BPOs who participated in UAT. Continuity of people matters as much as continuity of system access, because the institutional knowledge of what was tested, what was deferred, and what was accepted with a workaround lives in those individuals. Exit criteria are measurable: ticket volume below a defined threshold by severity, all critical defects resolved or formally accepted, core business processes executed by client teams without consultancy intervention, and the CoE governance model operational and owned.

The most common hypercare failure is under-resourcing relative to the project team, driven by commercial pressure to release consultants immediately post-go-live. The second most common is BPOs surfacing process gaps during hypercare that UAT should have caught, which is a testing discipline failure that has migrated forward in the timeline rather than a hypercare problem in its own right. Both are prevented by decisions made at the SOW stage, not improvised at go-live weekend.

Quality Is a System, Not a Standard

Every discipline covered in this article is individually manageable. The quality gate in SAP Cloud ALM is only as effective as the governance body that acts on its findings. Clean core discipline only holds if the team includes people with the seniority and mandate to enforce it under commercial pressure. Hypercare only stabilizes a go-live if knowledge transfer was built into every preceding phase. The commercial position on Level D modifications is only credible if the consultancy has already demonstrated it holds the standard everywhere else.

Practices that treat these disciplines as a checklist produce variable outcomes depending on which items got attention on a given project. Practices that have made them mutually dependent, where methodology adherence reinforces governance, governance protects clean core, clean core decisions inform team composition requirements, and team composition determines whether knowledge transfer actually occurs, produce consistent outcomes across projects, clients, and delivery conditions. That consistency is what a quality system actually is, and it is what the SAP ecosystem’s best practices demonstrate every time they deliver well.

If you are an SAP professional looking for a new role in the SAP ecosystem our team of dedicated recruitment consultants can match you with your ideal employer and negotiate a competitive compensation package for your extremely valuable skills, so join our exclusive community at IgniteSAP.