Business Solutions with SAP

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. 


Contact me today through our site contact form ( ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175
Bill Wood contact


Print pagePDF pageEmail page

Related Posts:

Leave a Reply