Business Solutions with SAP

SAP Project Implementation Strategies and Approaches

October 25th, 2010 by

SAP project successFor a brief intermission before I make the final posts on managing the shared responsibilities for SAP project success I thought I would offer this explanation of the different strategies and approaches for an SAP project.

 There are three key dimensions to an implementation strategy–, they are: 1) the vendor type; 2) the methodology-tools-templates-resources for a project, and; 3) the implementation approach.  The decisions you make around these three areas generally make up the implementation strategy for your SAP project.

SAP Implementation Methodology

For the methodology approach I will assume you are using the SAP ASAP methodology.  As a result other than mentioning it here I won’t spend a lot of time on this one.  With only a few exceptions, nearly every SAP system integrator claims they follow the SAP ASAP methodology.  As an ASAP certified consultant since the late 90’s I can assure you that few SAP system integrator project managers actually follow much of the ASAP methodology no matter what claims they make during the sales cycle.

The SAP ASAP methodology will help to ensure you are doing the right things in the right way

I’ve written on the ASAP methodology in A New SAP Implementation Methodology and Implementation Steps and for more background on the different vendor or project approaches see Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP .  And let’s put this in context, the SAP ASAP methodology has been used literally tens of thousands of times.  It is tested, proven, and it plain works!

The SAP ASAP Methodology is tested, proven, and it plain works!

As a parting note I would strongly encourage any SAP customer to get their own copy of the ASAP methodology.  No matter what stage of your SAP project the SAP ASAP methodology will help to ensure you are doing the right things in the right way. 

For more information on acquiring your own copy of the SAP ASAP methodology, see the 10 steps I previously outlined under the section “Where to start with developing a solid SAP business case based on business and IT strategy” in the post ERP and SAP Business Case for ROI, Business Benefit, and Success.  During the sales cycle (or during your project if you are past that) ask your SAP system integrator to show you the SAP ASAP methodology.  There are two identical versions, one is an HTML web server version and the other is integrated into Solution Manager.  Both are free, and the HTML version is available to any customer or vendor free of charge who wants to download it directly from SAP.  There really is no reason they can not make it available.  Because of its wide availability you should beware of any vendor who pitches the SAP ASAP methodology and can not make it available to you! 

If you are an end SAP customer contact me and I will arrange for you to get your own copy!

SAP System Integrator or Implementation Vendor Type

This topic is a little different because there are several possibilities for how you approach your vendor selection or project staffing.  Each of them has their benefits and drawbacks and some of them can be substantially different in cost and results.  The type of implementation vendor and consultants you use will also affect your implementation strategy.

You may wish to employ a well established system integrator; a “boutique” consulting firm; or completely manage the project with your own selected staff of contractors; or you may want to consider a hybrid approach.  If you are considering the contractor route, of staffing a project yourself, you might wish to review the screening methods to find the right consultant Part 1 and Part 2.

You will also need to determine your project implementation model.  Will you do a pure time and materials approach, or fixed fee, or time and materials with penalties for under-delivery (over budget, over time) and rewards for over delivery (under budget, early), or time and materials with cost controls, or a blend of some of the approaches.

Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP

If you choose the large integrator be prepared for the full sales pitch about their “special” methodology (whether it actually exists or not).  This is one of the classic approaches the larger consulting firms use to try to differentiate themselves.  However the SAP ASAP Methodology has been tested and proven so many thousands of times that any other approach actually introduces risk into the project.  That does not mean that there aren’t ways to supplement that methodology — there are a few gaps — but the ASAP methodology is very solid, reliable, proven and consistent.

The boutique firm may work well for many companies, but they have the drawback of being focused on a narrow niche area. 

The company run implementation with outside contractors (rather than a system integrator) requires a very experienced, very skilled SAP project manager.  I have participated on two of these projects that were very successful and their rates were about 35 – 50% less expensive than other consulting options.  One significant caution here is this type of approach can be a disaster without the means to carefully screen consultants and without a very seasoned SAP project manager.  The other problem is that many (though not all) of the staffing and recruiting firms are so “sleazy” that you are better off putting in the effort to screen yourself.  Back to the chicken or the egg problem, this requires someone who has the capability to do the screening.  This approach has probably the highest reward and the greatest risks associated with it. 

SAP Project Implementation Approach

Over the years I’ve only ever seen two key approaches to SAP implementation projects–, Big Bang or Rollout projects.  Within these two methods you can do a Phased Approach as well, but that is more of an issue of functionality scope rather than organizational scope.

Organizational scope would cover the “Big Bang” SAP implementation approach and the “Rollout” SAP implementation approach.  It affects the amount of the company or organization that is affected by the project. 

Functional scope would address the amount of the SAP business software that you plan on bringing into your organization(s).  This would generally be a “Phase” of the project.  For example you might bring in Financials and Supply Chain functionality in Phase 1, and then CRM or online ordering or BI / BW (reporting) in Phase 2, etc.

ERP Big Bang

The “Big Bang” SAP approach is probably the most common and generally involves a single major functional event.  It usually affects all “legal companies” where financial reporting is required for taxes or regulatory requirements.  This can be a large implementation across multiple countries, multiple business divisions or product lines, and generally affects the whole of the organization.

The “Big Bang” approach may be easier from a single “change event” or “change shock” to the company and organization but it has a number of drawbacks as well.  For example with any ERP application some of the potential design, data, and knowledge transfer problems are only discovered after the system is live.  So if your SAP system integrator or vendor is not as skilled as their sales presentation might have indicated you could end up with serious long-term difficulties, cleanup, and ongoing maintenance headaches.

ERP Rollout

The Rollout approach is fairly popular among a number of larger SAP customers with several legal companies, several locations, or multi-nationals that do business in several countries. 

Advantages of this approach includes the ability to “learn” from each rollout and improve subsequent operational rollouts.  Rollout risk can be more carefully managed because data and configuration inconsistencies can be discovered, remedied, and resolved while the subsequent rollout is occurring.  Change is better absorbed over a longer period of time in the company and knowledge transfer is generally better handled if the customer insists their resources are involved (done correctly this can actually reduce overall implementation costs).

Disadvantages of this approach are that it generally costs more because cumulatively it takes more time and effort to manage the ongoing operations while also bringing on new operations.  Also the blueprint will need to be re-visited for each rollout location because no matter what ANY integrator says (or what the SAP documentation purports) there always seems to be some legitimate differences between each rollout location.  Failure to re-visit the blueprint for each rollout, no matter what the integrator or SAP might say, can cause more difficulties than it is worth.  However, these later stage blueprint reviews and adjustments are not as intense or time consuming.

ERP Phased Approach

Because of the many variations and options we will re-visit the Phased Approach at a later date with more details.

Popular Searches:

  • SAP Implementation strategy
  • what are types of implementation strategies

Related Posts:

SAP Success Factors for Vender Selection – Responsibility Matrix 2

October 18th, 2010 by

Top ERP Success Factors

Based on a combination of the academic literature [FN1] and my personal experience I have put together the following SAP and ERP Critical Success Factor Responsibility Matrix. The large “A” indicates a primary responsibility, a small “z” indicates a secondary responsibility, and a blank field indicates no direct responsibility.

This is part of the continuing series on managing the SAP vendor relationship to help ensure SAP project success.  This can be achieved by reviewing the SAP critical success factors, how responsibility is divided, and tactics for managing them.

You want success, they want your money, MAKE SURE THEY EARN IT!

The small “z” indicates that the party has a very strong influence over that factor but may not be in the position to ensure that it is successful. These small “z” areas are often the key areas where parties with more of a primary responsibility tend to try to lay blame on the other party when a project runs into trouble.

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 for the success factor
z = Shared but secondary responsibility for success

During your SAP or other ERP project it will be critical to pay very careful attention for you as a customer to those areas where the system integrator or consultants have a primary responsibility (the “A” areas) and where you share the responsibilities (the “z” areas). Those are generally the activities that many of the “con”sulting companies and unscrupulous integrators will take advantage of you and lay blame on you for activities they should be more carefully managing. If your project really goes wrong you can bet that in one way or another, you as a customer, will be shown to be somehow responsible for their primary area of responsibility.

SAP Vendor or System Integrator Responsibilities

On the other hand, you as a customer also need to be aware of, and careful about, the areas where you have the primary responsibility. And especially the areas where there is a shared responsibility with the system integrator and they only have a limited ability to influence your activities and success. Those areas should not be blamed on an SAP consulting firm or the consultants if it can be shown they tried to encourage you to do the important tasks to ensure success.  Keep in mind, at the end of the day, as the customer, you are always primarily responsible for your own success.  If risks, problems, or other issues arise and you as the customer do not take corrective action then no system integrator or consultant can change that.

SAP Customer or Client Responsibilities

For those shared responsibilities where the system integrator is tagged as a “z”, if they failed to let you know ahead of time, in a timely manner, a) what to expect, b) how to deal with it, and c) the risks involved, they may not have the experience they sold to you. Keep in mind that does not mean they will be able to spot every issue, every time, ahead of time or have the answer for every situation. But if that foresight is consistently lacking then caveat emptor, or, buyer beware in your engagement with that vendor.

List of ERP or SAP System Vendor Request for Information (RFI) Requirements

One great area to start out your SAP vendor selection process is with an RFI, or Request for Information from the vendors you are considering. I suggest you ask them to respond on how they will handle any and all of the key shared responsibility areas. In the table below you might want to reproduce it and remove the responsibility assignments (see the example below).

At the end of the day, as the customer, you are always primarily responsible for your own success

SAP system vendor RFI’s should include a list of each shared responsibility from the list above, who the vendor believes should “own” that responsibility (the large “A” or primary), and what resources they have to facilitate success.

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

You can use this table as a first pass method to disqualify ANY system integrators that are non-responsive and those vendors that attempt to avoid any accountability for what they deliver. If any SAP system integrator is going to try to make you solely responsible for the success of every facet and phase of the project what do you need them for? In other words, if they are not willing to “own” any of the responsibility for your project’s success maybe you should be looking for different vendors.

How to use the SAP Vendor RFI Shared Responsibility Matrix

Use this table for gaining insight into a vendor’s operations and project approach. For example you might wish to use it in the following way:

    1. Send the proposed system integrator a list, similar to the one below, with BLANKS under the responsible party column and ask them to fill out who should be responsible for each success factor.
    2. SAP ERP Critical Success Criteria Table for Vendor RFI processing.


    Y / N
    SAP or ERP Critical Success Factor Company Integrator
      Experienced SAP consultants    
      SAP implementation strategy    
      SAP project management    
      SAP tools, templates, and resources    
      SAP scope development    
      SAP scope management    
      Strong SAP project and business communication (inward and outward)    
      SAP change management    
      Sufficient SAP training (user and project team training)    
      SAP system vendor and customer trust    
      SAP system design decisions    
      Amount of custom ABAP or other SAP coding    
      Appropriate SAP software configuration (system settings)    
      SAP system change control process    
      SAP data analysis and conversion    
      SAP test planning    
      SAP test development    
            Additional Vendor SAP Success Criteria 1    
            Additional Vendor SAP Success Criteria 2    
            Additional Vendor SAP Success Criteria n…    


    1. Pay special attention to those vendors that might offer ADDITIONAL success criteria from what you send them. These vendors may understand and appreciate your focus on project success. If nothing else it will at least indicate they are giving it serious thought.
    2. Indicate in your RFI that failure to adequately address the critical success criteria section of the RFI will automatically disqualify that vendor. Why deal with ANY integrator, no matter how cheap or how supposedly “experienced” they may be if they are not willing to focus on your project success?
    3. Under the “Resources” column ask the vendors to indicate if they have specific approaches, tools, methods, or other resources to help ensure success.
    4. In your RFI ask them to include in a separate sheet any of the “Y” answers, and to be ready to demonstrate those approaches, tools, methods, etc. during any future sales presentation.
    5. For any Resource answer with an “N” (no resources) ask the vendor in their RFI to propose some method to manage the risk associated with not achieving that success factor.

    In other words, this exercise does a number of things that are helpful to you as an ERP services buyer from an SAP system integrator or SAP implementation vendor:

    • It focuses every vendor on project success criteria even before they engage in their sales pitches.
    • It helps to separate some of the less reputable vendors from the process by exposing the vendors who do not believe they have any stake in your project’s success.
    • This approach ensures that the prospective SAP system vendor or SAP consulting company provides tools, resources, methods, and approaches to mitigate risks associated with not addressing each of the success criteria.

    As we continue through this evaluation of SAP software critical success factors in future posts we will look at methods, tactics, and strategies for managing each of them to promote success. After all, you want project success, ROI, and business benefit, they want your money so they should earn it. Take some time and review the following posts for more background on vendor selection and vendor evaluations.


    [FN1] This table was developed from a combination of factors found in a graduate student’s submission, from peer-reviewed academic literature I’ve previously written about, and from my own experience with SAP since 1994 and business systems since the mid 1980’s.

    Bhagwani, A. (2009). Critical Success Factors In Implementing SAP ERP Software, University of Kansas Graduate School. .Somers, T., and Nelson, K., (2001) The Impact of Critical Success Factors (CSF) across the Stages of Enterprise Resource Planning Implementations. Proceedings of the 34th Hawaii International Conference on System Sciences. Somers, et. al., has been reviewed in detail on this site at:

    The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors

    Related Posts:

    SAP Success Factors for Vendor Selection – Responsibility Matrix 1

    October 11th, 2010 by
    ROI, TCO and Business Benefit from SAP - critical success factors
    SAP ROI Success Factors

    Recently I was reviewing another of many papers I often read on various business and IT topics.  A paper from a graduate student recently caught my attention and while it lacked some of the insight from personal experience, it made up for it in the substance of the material. 

    After a short look at the peer-reviewed academic literature, Anil Bhagwani, did a brief case-study on 10 failed SAP implementations and 10 successful SAP implementations.  From these he continued to distill SAP critical success factors.



    For more vendor selection background, before or after reading this post, please refer to another study that was reviewed on the topic of vendor seleciton–, SAP Implementation Partner or Company Selection Criteria.

    Common SAP Critical Success Factors (CSF’s) identified for successful ERP implementations

    The study author’s perspective and summary of the key success criteria from the Executive Summary, pg. 5, is reproduced here (altered and reformatted for easy reading):

    • Sustained executive management support and their ownership of the implementation.
    • Project team composition.
    • Good project management (especially pertaining to process design).
    • System testing.
    • Training of the end users.

    These are the most important factors contributing to the success of SAP implementations in most organizations.  The lack of sustained management support / contribution and user involvement / training and testing seems to be the most important factors contributing to the failure of SAP implementations in most organizations. [FN1]

    These conclusions are consistent with my experience and tend to be mostly in line with the academic literature.

    Why do so many SAP projects come in over budget and over time?

    One important feature of this paper is the notation about project management and its relationship to project failure.

    30% of projects were perceived to have failed because of a lack of effective project planning, while 10% were perceived to have failed because of technology-driven causes[FN1]

    This, in my opinion, can be laid at the feet of the implementation vendor and the project management they provide.  More often than not it is the implementation vendor who is tasked with providing the experienced consultants and project management team.  And in the SAP world nearly every SAP system integrator pitches the SAP ASAP implementation methodology but few of them bother to actually follow it after the sale.

    Companies pay dearly for “experienced” resources who claim to follow a proven methodology to steer a customer correctly through their SAP business software system implementation.  But in most cases a good system integrator, with seasoned project management is critical to your implementation success.

    Although the literature suggests that 10% of the ERP project failures were related to technology, with SAP in particular I would challenge that as masking the real underlying cause.  Let’s put the claim of SAP technology limitations into perspective.  As of October 6, 2010,

    • SAP has over 100,000 customers in more than 120 countries [FN3],
    • nearly 50,000 employees [FN2] (with approximately 15,000 of those employees being developers [FN3]),
    • about 15% of total revenue dedicated to R&D. [FN2],
    • and more than 24 global industry segments. [FN3]

    Plainly the SAP solution has been proven in nearly every environment imaginable. In spite of some of the headlines about failed projects, the application itself is so widely used, adopted, supported, and developed it can not be the problem.  In my opinion the blame for failed implementations, blown budgets, and blown project timelines is frequently the fault of the guidance many companies receive from their hired help.  That does not mean that customers do not contribute to this in many cases, only that the system integrators are the ones that should “know better.”  When an ERP implementation project is headed toward the rocks the system integrator should have enough experience and integrity to raise the risk issues and help to avoid disaster.  After all, during all of the sales pitches they are the ones that tout how much experience they have and you hire them based on that supposed experience to help ensure you do not crash on the rocks.

    This does not mean that SAP does not have its technology limitations.  After participating in SAP projects since 1994 I have rarely encountered SAP software limitations where the standard application was not able to deliver 90 – 95% of the business requirement without any custom coding.  Where that 5 – 10% of custom coding was required SAP has provided both user exits (prior to version 5.0) and enhancement points (versions ≥ 5.0) to modify the data processing within the transaction stream.  And unlike other consultants, my experience has taught me that there is a standard solution there somewhere so I will look for the standard functionality before trying to undertake custom “software engineering” efforts.

    As a result I would attribute that 10% “technology-driven” failure rate to other ERP applications, or more likely improper requirements, poor project management, or bad consulting.  Although I have not had the direct application exposure to SAP’s competitive products, I would guess they are fairly well developed in their focus areas as well.  And over the years I have had a LOT of SAP client counterparts wanting what I call mutually exclusive requirements.  Or, as an analogy, they wanted to have their cake undisturbed while still eating it too. 

    Defining SAP Success Criteria (Lacking these can cause ERP Project Failure)

    The academic study’s author offers an ERP success definition which notes projects are “done within budget and time with meeting all the preset implementation goals as measured by ROI, etc.” [FN1, pg. 8].  The author then notes a 2007 Gartner study showed only 60% of the projects achieve this success definition. 

    In my next post I have reproduced the list of critical success factors (CSFs) and added a responsibility matrix.  Those critical success factors come from a combination of this study, done in 2009, combined with a prior peer-reviewed study I wrote on previously ( The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors ) and my own personal experience.

    The responsibility matrix I developed defines major project success criteria and who is (or at least should be) responsible for ensuring the successful delivery of those key components. 

    More of this is explained in my next post which looks at some of the key areas for project success, who should manage those success factors, and how so many consulting firms avoid responsibility.  After that we will review details on steps and strategies to ensure ERP system integrator accountability for managing those success factors to ensure you don’t get robbed in your SAP business software system project.

    Tune in over the next few weeks for more details and insight on this topic.  I’ll be exploring why so many SAP system integrators and ERP vendors are able to avoid accountability for these SAP critical success factors and how you can work to ensure your ERP system vendor covers these factors.


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

    [FN2]  SAP Inventor Relations, Business in Brief, (retrieved 5/10/2010)

    [FN3] Deutsche Bank European TMT Conference 2010, London, September 10, 2010 (retrieved 10/04/2010

    Related Posts: