Business Solutions with SAP

SAP Customer Responsibility for SAP Project Success

April 23rd, 2012 by
SAP Success Criteria Formula

SAP Success Criteria Formula


Some time ago I put together a synthesis of SAP success criteria based on academic literature and my own personal experience.  The table below is part of the list of SAP Success Factors for Vender Selection – Responsibility Matrix. For a more detailed explanation of each of the vendor related items see the posts listed in the Series on SAP ERP Project Success Factors.

In the prior series we went through SAP success factors with shared responsibilities between the company adopting the SAP application and the integrator they use for the implementation (listed below) but today we will briefly review customer-specific success items (further down).

No. SAP or ERP Critical Success Factor Company Integrator
1 Senior Management Support (and steering committee makeup) A  
2 SAP project champion A  
3 Empowered business project team decision makers A  
4 Company SAP project team (quality and time allocated) A  
5 Experienced SAP consultants   A
6 SAP project success criteria, goals and objectives A  
7 SAP implementation strategy z A
8 SAP project management A z
9 SAP tools, templates, and resources   A
10 SAP scope development z A
11 SAP scope management A z
12 Strong SAP project and business communication (inward and outward) A z
13 SAP change management A z
14 Business process engineering – interdepartmental cooperation A  
15 Sufficient SAP training (user and project team training) A A
16 SAP system vendor and customer trust   A
17 SAP system design decisions z A
18 Amount of custom ABAP or other SAP coding z A
19 Appropriate SAP software configuration (system settings) z A
20 SAP system change control process   A
21 SAP data analysis and conversion A z
22 SAP test planning A z
23 SAP test development z A
24 Company end-user involvement and end-user testing A  


A = Primary responsibility
z = Secondary responsibility (can influence success but limited control over success)


The previous series did not address several of the customer-specific items where organizations should focus internal efforts.  As part of the recent series on Organizational Change Management Inside the SAP IT Support Organization it is time to consider the SAP customer specific items now.  That list of items includes:

No. SAP or ERP Critical Success Factor Company Integrator
1 Senior Management Support (and steering committee makeup) A  
2 SAP project champion A  
3 Empowered business project team decision makers A  
4 Company SAP project team (quality and time allocated) A  
6 SAP project success criteria, goals and objectives A  
14 Business process engineering – interdepartmental cooperation A  
24 Company end-user involvement and end-user testing A  

1.  SAP Project Senior Management Support – 2. SAP Project Champion

You just can’t overlook strong senior leadership support and a strong project champion for SAP project success.  If the wider organization perceives it is important enough for executive leadership they will see that it is a key initiative to focus on.  The Real Reason Executive Participation Creates IT Project Success is related to the nature of their position which deals with corporate strategy. The enterprise also needs an SAP project champion to help cut through red tape, encourage organizational support, and marshal additional resources when needed.  The best project champion would be at least one NON-IT executive so this isn’t seen as “just another IT thing.”  The contribution of a well respected and strong internal leader can not be overlooked.

3.  Empowered Business Process Team Members to Make Key Business Decisions About SAP Setup

If you want your SAP project to make any progress then it is absolutely critical to ensure core team members from the business are able to make many of the important process decisions. There will be some decisions that have more widespread organizational impact and the business users will need more senior level managers to make some decisions.  For example one of the key reasons for Using Your SAP Steering Committee for Business Transformation is to help mentor, guide, and direct business project participants in designing the future state business.  This would include making “critical decisions which the project team is unable to resolve (escalations or key business decisions).”  On the other hand if they are so compliant or risk averse that they will not make any decision without gaining consensus you may be headed for problems with the project timeline and budget.  This doesn’t mean you need an autocrat either, just someone who has enough organizational insight and connections to make the right decisions, escalate the ones that should be escalated, and has an open line of communication to keep interested stakeholders in the loop.

4.  Business Process Team Members who are DEDICATED to the SAP Project Delivery and Success

Too often I see core SAP project team members, whether from the business or the internal IT organization, who are not assigned exclusively to the SAP project.  While they are given the new role they often still have their “day job” to continue overseeing and managing.  This is a significant distraction from a very serious undertaking.  When an SAP project is done effectively, and what I call “correctly,” there is significant business change that takes place.  To help manage that change and to ensure business users have their needs most properly represented requires a full commitment to the SAP project.

Unfortunately there are a lot of system integrators who are happy to have your business users commit to just “part time” on the project.  It helps the system integrator increase their billing, allows for lots of excuses for missing dates, and provides them the opportunity to push any solution they deem you should have.  Because core team members from the enterprise have divided attentions they can not ensure the same level of quality if the SAP project were their only focus.

6.  SAP project goals and success criteria

I was recently reading an article where a study of several hundred companies who had implemented enterprise applications were asked about having defined business related goals and success criteria.  The referenced study suggested only 4% of companies who implement enterprise applications complete the entire process of defining goals and success criteria and then actually follow up on seeing that they achieved the promised benefits. 

To achieve Sustained Business Value from SAP Business Software it is important to incorporate a Change Management Program within the SAP / IT Organization itself which is focused on Achieving Business Value from SAP Investment.  Another key part of the goals and success criteria is to Change How You Look at SAP to Create ROI because SAP Implementation is an Investment NOT an Event.

14.  Business process engineering – interdepartmental cooperation

 This is directly related to the first 3 items in this list:

  • Senior Management Support (and steering committee makeup)
  • SAP project champion
  • Empowered business project team decision makers

Because of the nature of the integration in SAP some of the data entry responsibilities change, for both upstream and downstream process steps which may be in different departments.  There are also significant process changes and responsibility changes as a result of the SAP implementation.  All of these require a focus on processes, communication, and cooperation.  Because this can also be an area of political “friction” between departments or leaders it is critical to have a strong executive SAP project champion. That executive sponsor can help to reduce a some of the inter-departmental “border wars.”

24.  Company end-user involvement and end-user testing

Even a great implementation effort can turn into a painful disaster at go-live if end users are not prepared to use the new system, security and authorizations are a mess (VERY typical), and testing was not thoroughly performed.  Unlike other systems which were built in silos and without the level of integration a data or process mistake that is not uncovered during testing can have significant up and downstream effects.  Unwinding and correcting the error can prove to be very challenging.

For all of these items I only touched the surface, but none of these items can be ignored and are important for a successful SAP project.  Every one of these items is completely within the control of the enterprise or organization who implements SAP.  Good luck on your SAP journey but be sure to pay special attention to all of these success criteria for your SAP project which are provided in more detail in the Series on SAP ERP Project Success Factors.

Popular Searches:

  • sap project management

Related Posts:

SAP ERP Project Failures Lessons Learned and Mini Case Studies 2

December 20th, 2010 by
SAP ERP Project Failures

SAP ERP Project Failures

The following SAP ERP project failures cover the importance of testing, change management, training, senior management involvement, scope management, and quality of the consultants provided by ERP implementation vendors.

With the exception of the inept, incompetent, or otherwise unqualified “con”sultants provided by some system integrators it is important to note that these failure overviews illustrate many of the points made by Steve Phillips in the post on Software Consulting Firms and Clients Myths and Half Truths .

There Mr. Phillips lays out pretty significant areas where the business must chart and then control their own project destiny.

For a table of the primary areas of responsibility for end customers to ensure project success please see SAP Success Factors for Vender Selection – Responsibility Matrix 2 .  The table developed there is derived from the academic literature and my own experience.  I have added my opinion on how the responsibility for those success factors is divided between the customer and the SAP implementation partner or vendor.

Continuing on the series of SAP ERP project failure overviews, here are three more.

SAP ERP Implementation Failure Overviews – part 2

Levi Strauss & Company – SAP Failure? (2008)

  • After go-live shipping was prevented for one week and there were legacy system integration issues.  Levi was an interesting case study because many industry experts believe the SAP implementation was used as an excuse for broader economic issues affecting Levi.
    • One week of delayed deliveries was insufficient to explain the overall drop in financial performance (approximately 98% decrease in revenue could not be sufficiently tied back to the SAP implementation).
  • Levi Strauss has since worked through and resolved the implementation issues and SAP is running smoothly.

Lessons Learned: Ensure that all legacy system interfaces are carefully tested before going live. Don’t use SAP or enterprise application implementations as an excuse for poor economic or poor overall market conditions.

Waste Management Incorporated – SAP ERP Failure Overview (2008)

  • Waste Management claimed in its lawsuit that they “wanted an ERP package that could meet its business requirements without large amounts of custom development…” They also claimed “SAP used a ‘fake’ product demonstration” and “SAP’s technical team had ‘recommended that SAP deliver to Waste Management a later version of the software than the version SAP in fact delivered’.” They also claimed SAP knew the software was “unstable and lacking key functionality…” [FN1]
  • SAP claimed that its application could meet the company’s needs without modification.
  • SAP claimed in its legal counterclaims that “Waste Management didn’t ‘timely and accurately define its business requirements’ nor provide ‘sufficient, knowledgeable, decision-empowered users and managers’ to work on the project.” [FN1]

Lessons Learned: First and foremost any organization or company who implements SAP, ERP, or other enterprise software applications must ensure they are in control of their own project. This would generally fall under numerous critical success factors: business process engineering / change management, scope management, senior management support, formal project plan and schedule, consultant experience, implementation strategy, and amount of custom coding.  Delivering a project with standard system functionality, and on time / on budget requires strong leadership from both the customer and the integrator.  For additional insight and a somewhat different perspective please see the post where SAP and Waste Management Finally Settle .

Los Angeles Unified School District – SAP ERP-HR Failure Overview (2007)

  • Fake Consultants / Trainees / unqualified consulting resources on the project
    • “[I]t appears Deloitte (the implementation partner) brought unqualified resources (i.e., personnel) to the project.” [FN2, pg. 28].
    • I personally encountered one of these fakes as a project manager for another company looking for a workflow resource.  Their ABAP and SAP skills were horrible but they got a great reference from LAUSD.
  • Lack of cooperation with the Teacher’s Union and no user buy in.
    • This is a project planning and change management issue; the company and the integrator bear this responsibility.
  • Has since worked through and resolved the implementation issues and SAP is running smoothly.

Lessons Learned: SAP implementation vendors and partners may allow margin desires to override quality to the point of presenting significant project risks.  It is critical to evaluate every consultant any integrator brings onto your project.  There are just too many fakes in the marketplace that do not have proper background checks.


[FN1]  SAP, Waste Management settle lawsuit.  Business Week. May 3, 2010. (retrieved 5/11/2010)

[FN2]  Bhagwani, A. (2009). Critical Success Factors In Implementing SAP ERP Software, University of Kansas Graduate School.

Popular Searches:

  • sap implementation failures
  • waste management erp sap case study first publication in 2008

Related Posts:

SAP System Vendor Project Success Criteria & Factors 2

November 8th, 2010 by

ROI, TCO and Business Benefit from SAP - critical success factors

 This is a continuing post in an extensive series on achieving SAP project success.  For the complete series on posts please see the Additional Resources list at the end of this post. 

Last week’s post looked at some of the key factors around the type of consultants you need for success, your project approach, and the structure around the project. 

This week we will continue exploring details around the SAP critical success factors (SAP CSF’s) as they relate mostly to SAP project scope and SAP project change management activities.  The basic idea behind the posts in this series is

You write the checks for an SAP system integrator to deliver business value, make sure they do!

No. SAP or ERP Critical Success Factor Company Integrator
5 Experienced SAP consultants   A
7 SAP implementation strategy z A
8 SAP project management A z
9 SAP tools, templates, and resources   A
10 SAP scope development z A
11 SAP scope management A z
12 Strong SAP project and business communication (inward and outward) A z
13 SAP change management A z
15 Sufficient SAP training (user and project team training) A A
16 SAP system vendor and customer trust   A
17 SAP system design decisions z A
18 Amount of custom ABAP or other SAP coding z A
19 Appropriate SAP software configuration (system settings) z A
20 SAP system change control process   A
21 SAP data analysis and conversion A z
22 SAP test planning A z
23 SAP test development z A


A = Primary Responsibility for the success factor
z = Shared but secondary responsibility for success

10.  SAP Scope Development

Probably one of the single most abused areas of shared responsibility is in Scope Development.  It is a routine tactic of some system integrators to misrepresent the amount of scope or of actual system requirements during the sales cycle to try to land a contract.  System integrators who deliberately under-scope a project may hit you continuously with change orders for “new requirements,” new consultants, and additional fees or budget throughout the duration of the project. The whole time these unscrupulous vendors position themselves and their contract language so that the “responsibility” for the scope change is never on them and always your problem as a customer. Never mind that they led you down the wrong path to begin with.

Your best defense is to use SAP’s Solution Composer Tool

While some vendors use unscrupulous “gaming” of scope to underbid and land your business there are times that scope changes are necessary.  It is your responsibility as a customer to ensure that you have a good first pass solution scope for your RFI and RFP processes using the Solution Composer tool but it is a system integrator’s responsibility to validate the accuracy or completeness of that scope, your budget, and your timeline.  Beware of system integrators who wait until they are employed and then “suddenly” discover major scope problems.  However it is important to keep in mind that there will likely be some adjustments to scope by the time you complete the blueprint.

One other thing to keep in mind is that even with the Solution Composer Tool your initial assessment of scope may be too aggressive.  In other words you may be trying to do too much too fast with the initial scope.  A good indication of this is if your vendor proposals consistently come back with much higher budget requirements than you originally anticipated.  Again, one of the things to be careful of here is when you put out for bid if several vendors come back very high compared to your budget and one vendor seems to come in much lower than the others they may be using very junior resources OR they may be planning on “gaming” you throughout the project. 

SAP Scope Development Tips, Tricks, and Methods

1.  Before you even do your SAP project join an SAP customer peer and support group like ASUG (America’s SAP Users Group) if you are in the United States. 

  • Go to local meetings and network directly with ASUG companies (avoid the vendors at these meetings).
  • Post questions on SAP forums asking for feedback, input, and insight on problems other companies had with scoping.  This does 2 very important things,
    • it helps you identify where you might have scope trouble and
    • it might point out some of the slimy snakes in the marketplace to be sure you do NOT send an SAP RFI or SAP RFP to them.

2.  Possibly as part of the negotiation process, or after you sign your software agreement, get your online OSS (Online Support System) ID and get your version of SAP’s fully functional evaluation system called “IDES” (Internet Demo and Evaluation System, see SAP Note 799639 for general information).

3. Create contract requirements with penalties and credits for poor performance or failure to deliver.

4.  As part of your RFP be sure to include your first pass at scope, and include a description of the goals of the project and the high level department affected.  Then ask the vendors to suggest additional scope if necessary.

5.  Ask each vendor to put together an initial staffing plan with estimated man hours and project duration as part of the RFP.  Regardless of rate differences between vendors this should help you to understand what a vendor actually thinks the time duration and resources should be for your project. 

The real difficulty in scope development is that a good RFP needs enough scope details to get an accurate SAP proposal.  Valid man hour estimates by vendors are difficult without a good starting scope in your RFP.  This is because as a customer you do not usually have the understanding and knowledge of SAP’s integration, system functionality, and third party applications (or custom development). If vendor RFP man hour estimates are wildly different then it may be an indication that your RFP did not have enough scope details for the vendors to make an accurate assessment of your needs.

 To overcome this your best defense is to use SAP’s Solution Composer Tool.  It will map SAP’s system solutions to your business from a business process perspective.  It is free to anyone considering an SAP implementation and you do not already have to be an SAP customer. [FN1]

For a more background and insight on SAP project scoping please see the following posts:

If vendor RFP man hour estimates are wildly different then it may be an indication that your RFP did not have enough scope details

11.  SAP Scope Management

The requirement to manage scope (assuming it has been properly developed) falls to the customer.  It is in a customer’s interests as part of budget management, timely project delivery, and manageable work requirements to manage scope. 

Some SAP system integrators intentionally misrepresent the amount of scope or of actual system requirements during the sales cycle.

IF scope was properly developed it then becomes a customer responsibility to ensure scope is properly managed throughout the project.  You should know in advance that new requirements or desires from various parts of the business will come up during the project.

While it is critical to make the early efforts to get scope correct for the RFP, vendor selection, budgeting, and reasonable project timeline you will have some changes.  So the key is to revisit scope at the end of the blueprint phase of your SAP project.  However it is important to beware here.  If you have followed the steps to develop a good starting scope, then scope changes at the end of blueprinting should be minimal.  If there is a sudden “need” for additional scope that causes a significant change in budget and project timeline requirements at the end of blueprinting this should be seen as a serious caution flag.

To ensure that business scope change requests are properly managed consider some of the following steps:

SAP Scope Management Tips

  • To help avoid some of the business scope change requests it is important to institute a clear communication program.
  • Be sure to publish a “Solution Composer” type scope presentation to mid-level and higher management to ensure their concerns are addressed.  This “expectation setting” is one of the keys to preventing surprises that might come up later.
  • If a scope change request does occur from the business then be sure to have a mechanism to capture the scope change request and ensure the contributor their request will be evaluated after the initial scope is completed. 
  • Keep middle management and above updated on a regular basis as to project progress (possibly a monthly status meeting for anyone interested). 
  • Publish the SAP project plan and progress in a place that interested company employees can review it.  Never allow an SAP system vendor to keep this hidden because the ability to for interested individuals to see the significant number of parallel tasks will help them understand why introducing scope changes can be disruptive.
  • Create a company or business unit wide program for managing and addressing changes and employee concerns.

12.  Strong Communication (inward and outward)

A solid communication program, inside and outside of the enterprise is a critical component of change management and of a successful SAP project.  Project messaging cannot be underestimated.

For years we’ve heard that people resist change but that is not true!  What is true is that people resist change that they do not understand or that they perceive has a negative impact on their lives.  If people truly resisted change then no new product or service would ever sell. There would be no new cars, new electronic gadgets, new shoes, clothes, or any number of new products or services we buy would ever change.  Since we know new products and services do sell then we have to look at why. 

Project messaging cannot be underestimated

Why do people not only accept, but welcome change in new products or services?  It is in the marketing.  The core of marketing is messaging and communications. So the key is in finding ways to communicate to your enterprise internally (employees) and externally (vendors and customers) to ensure that the coming changes are properly “marketed.”

Whatever channel or methods of marketing your company uses make the effort to get the marketing area engaged in project messaging.  The key is to understand and communicate to your audience’s fears, concerns, and uncertainty to help them understand why the current state isn’t working (or won’t work) and what benefits or advantages the new system brings.

For a solid communication program your SAP system integrator should have samples, including worksheets or guides on identifying each affected stakeholder and the messaging necessary.  At its most basic there are a few key steps.  1) Identify stakeholders, 2) perform a project impact / stakeholder analysis, and 3) create plans to move all key stakeholders to the “engaged” or “actively involved” category. [FN2]

Where to begin with an SAP Communication Program

1) Identify stakeholders – Identify any groups or individuals who will be affected by the SAP project (stakeholders).

  • Executive leadership
  • Project steering committee
  • Line of business managers and other department heads
  • End users (including subject matter, power, reporting, transactional)
  • Project team (internal to the company and the consulting team)
  • Customers
  • Suppliers
  • Etc.

2) Stakeholder analysis – Determine on a grid where each of these stakeholders fits in terms of messaging.  This should be actual current state, desired current state, and ultimate future state.  In other words, what is their awareness and involvement in the project, what should that awareness and involvement be today, and where do you want them by the time the project goes live?  Are they

  • Unaware
  • Know the project exists
  • Understand the need for the project
  • Willing to support the project (or are committed)
  • Resisting the project
  • Actively involved or actively supporting the project

3) Stakeholder communication and participation plans – Develop the messaging, participation, and change plans to move each key stakeholder group to the analysis status they should be at that phase of the project.

From the SAP ASAP Methodology

Tips for Communicating SAP Change

  • Ask people for their opinion before you implement change.
  • Explain the change in language people understand.
  • Every message should be audience specific.
  • Explain the change in terms of how it will affect them rather than what’s in it for the corporation.
  • Try to anticipate how people will react, the questions they’ll raise and the issues that may result.
  • Design your communication to answer those concerns immediately.
  • Solicit Feedback at all times.
  • Keep communicating about the change after it has been made. 
  • Recognize and celebrate its successful implementation.

13.  SAP Change and Expectation Management

If you want a successful SAP business software project then you must engage in change management activities.  No matter what name you use for the change, whether business transformation, business (re)engineering, or other names, the ability to manage change during the SAP project is critical to overall success.

If people truly resisted change then no new product or service would ever sell

Core elements of a successful SAP change program:

  • Communication
  • Leadership / Sponsorship Engagement
  • Stakeholder Management
  • Company Change Leaders / Change “Champions”
  • Risk Management
  • Organizational Alignment
  • Skills and Competencies / Training and Knowledge Transfer
  • Performance Management
  • Governance Support

The SAP ASAP Methodology (as of version 7.1) contains a list of key change management deliverables by project stage.  You can see those here:

Organizational Change Management deliverables in ASAP

Again, the SAP ASAP Methodology contains all of the key elements you need for project success.  To ensure that you are getting the greatest benefit from your SAP implementation vendor choice it is invaluable for you to get a copy of the latest version of the ASAP Methodology (in its HTML form) and get familiar with it before the first vendor shows up to make their pitch. 

The subject of change management has been posted on several times on this site.  At some point in the future we will begin to look at more of the details around SAP change management requirements for a successful project.  For now though please see the following posts for more insight:

The change management issue with SAP business software systems comes down to whether or not you do business process engineering or software engineering:

In many ways this could be re-phrased as do you do change management (business process engineering) or do you do software engineering to prevent the change related organizational struggles?

From the SAP ASAP Methodology

Organization Transformation for your SAP project

  • Establish a sense of urgency
  • Form a powerful guiding coalition (possibly the project steering committee)
  • Create a vision
  • Communicate the vision
  • Empower others to act on the vision
  • Plan for and create short term wins
  • Consolidate improvement and produce more change
  • Institutionalize the new approach

15.  Sufficient Training (user and project team training)

One of the most critical elements of a successful SAP project is both project team training and end user training.

Over the years I’ve developed a perspective that the project team members MUST get significant amounts of training on SAP processes and SAP configuration.  And I would strongly suggest that training come from a third party such as SAP directly or one of the other quality SAP training programs.

The reason project team training is so important is that a sophisticated SAP customer ends up with the best implementations.  A knowledgeable and sophisticated project team, who has significant amounts of SAP training is able to spot many of the less than optimal consultants and can see through SAP system integrator tactics (see e.g. Screening and Interview Methods to Find the Right SAP Consultant ).  A more sophisticated SAP customer is able to ensure that more of the standard functionality is used in their implementation rather than all of the custom-coded “solutions” provided by many consulting firms.  A well educated end customer is able to intelligently promote the correct design issues and focus on business process engineering rather than on software engineering. 

Maybe most important of all, a well educated end customer already has a head start on critical knowledge transfer that will be needed to support the system after you go live.

For more background on knowledge transfer (training) see the post on Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 2 . That post includes different types of training requirements, and knowledge transfer requirements, needed for a successful project.


SAP Project Success Additional Resources

SAP Implementation Partner or Company Selection Criteria

The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors
SAP Project Success Factors with Vendor Selection Responsibility Matrix

SAP Success Factors for Vender Selection Responsibility Matrix 2

SAP System Integrator Shared Project Success 1


[FN1]  Information on the Solution Composer tool, and its use can be found here:

To download the tool (free of charge) you will have to register here for access:

[FN2]  This communication information is based on a synthesis of tools, resources, and materials provided by SAP in their ASAP Methodology versions 3.10 and 7.1, and supplemented with my personal project experience. 

Related Posts: