SAP & ERP Consulting from the Customer Point of View

The other day I made a post to SAP’s Community Network on making sure customers get the best SAP business software integrator for their money.  One of the comments to that post suggested I was advocating for customers using ONLY SAP as their system integrator.  My response made it pretty clear that my goal is to encourage SAP customers to get educated so they actually achieve value and ROI from their SAP business software projects.  My response sums up why I started this site and what the posts here are all about.

Don’t waste money on consultants who cannot help you implement business software in ways that improve your business!

And to that end we will look at the implementation of SAP or other large business software applications.  Continuing this series of posts on shared success criteria, please see the table below for more information.

Legend

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

16.  SAP System Vendor and Customer Trust

I place this SAP critical success factor (SAP CSF) clearly in the SAP system integrator column.  I can’t say it any clearer than you are writing the checks for an SAP system integrator who needs to deliver value, otherwise what are you paying for anyway?

Trust, but verify – Why would you pay an integrator or their consultants who do not deliver business value?

SAP System Vendor “Trust but Verify“

There is a Russian proverb which states “trust, but verify” or, its English equivalent, “better safe than sorry.”  The phrase gained popularity in the United States during the presidency of Ronald Reagan.  He often used the phrase when dealing with the Russians about nuclear weapons.  When the U.S.-Russian INF (Intermediate Nuclear Forces Treaty) was signed, Mikhail Gorbachev commented to Reagan that he used the phrase at every meeting, to which Ronald Reagan replied “I like it!”

How does this relate to you and your SAP project?  The whole idea behind the proverb as used during the Nuclear Treaty discussions was the ability to monitor compliance with the treaty details.  Just like this nuclear weapons discussion was critical to the relations and operations of the two nations, and even the world, so is an SAP implementation to your company.  A business software system project is critical to competitive advantage, efficiencies, operations, innovation, and even customer acquisition and retention.  A properly implemented SAP business software system is critical to navigating a hostile competitive global business landscape. 

Progress monitoring, deliverables verification, and QA assessments must take place throughout the project lifecycle.

See the list of SAP ASAP Methodology deliverables by project phase.  Your SAP sales rep or SAP system integration vendor will have access to the most recent ASAP methodology and can provide you with the SAP standard version of the requirements.  Unfortunately because of the way the SAP copyright is written on the material I am unable to directly distribute it legally.

How do you “trust but verify?”  Here are some tips for ensuring this:

• Ensure that you consistently communicate your expectations to the system integrator
• Make sure your integrator provides a clear project plan with key project milestones (from the ASAP methodology).
• Ensure that there are deliverables that have a connection back to the project activity being completed (again, from the ASAP methodology).
• Verify that the vendor has a complete set of deliverable templates they can show you and explain ahead of time how they will work and how they are used to track SAP project progress.
• Perform a “mini-audit” at each project milestone with business stakeholders making the determination whether the deliverable(s) were sufficiently addressed and whether the upcoming deliverables templates appear sufficient for the next milestones.
• At the end of each project phase ensure that you perform a QA check of that phase before continuing with the next.  This is a standard SAP methodology process but is rarely followed by many consulting firms.

17.  SAP system design decisions and

18.  Amount of SAP ABAP custom coding

Both of these topics are directly related and with SAP in particular they are pretty much interchangeable.  The academic literature breaks these two critical success criteria items out because SAP is not the only business software package that is evaluated.  With SAP in particular the depth and breadth of business software functionality is so significant that custom coding should only be used if there is no close fit from standard functionality.

Before you begin your SAP project it is imperative for you as a customer to decide whether or not you want to do software engineering or business process engineering.  This post explains the differences, what the consequences are, and when it might be appropriate:

SAP Implementation Focus, Software Engineering or Business Process Engineering?
http://www.r3now.com/sap-implementation-focus-software-engineering-or-business-process-engineering

The amount of custom-coding and software engineering you engage in will have a dramatic affect on your overall SAP TCO (Total Cost of Ownership).  This will also have a significant impact on the amount of budget you allocate to critical change management activities and to ongoing software support and maintenance.

• Set a project expectation with the system vendor that everything you had in your scope must be delivered with standard functionality.
• Create a change review board to address any scope change requests AND any custom coding requirements.
• Create a contract provision with terms stating you will get ( x ) amount of a credit when a custom coded solution is proposed that had standard package functionality addressing ( x ) % of the business requirement.
• Ensure that every custom coding decision includes a written justification with:
  • The standard functionality that was evaluated.
  • Why the standard functionality would not work (what were the gaps).
  • What the business justification for the custom coding is (is it business / mission critical?)
  • Alternatives considered (remove from scope, third-party software, manual process, etc.)
  • Business impact if removed from scope or manually performed.
• If a decision is made to pursue the custom development then a standard functional specification must be completed.  A good template to start with can be found in the SAP ASAP methodology.  It should contain:
  • Detailed requirements.
  • Expected effort and cost.
  • All SAP module or other areas affected (in other words is this custom development going to be a huge project distraction by consuming too many of the consultants’ time and effort).

19.  Appropriate SAP Software Configuration (system settings)

The system integrator is hired to set up the SAP software.  Through the sales process they’ve convinced you their consultants have the experience you need for success and you hire them for your SAP project.  They are the experts and you have to rely on them because you don’t have the internal experience.

This is where good SAP consultants come into play.  The SAP ERP application contains so much functionality that nearly any business process can be addressed.

Appropriate software configuration is one of those things that is usually discovered at integration testing.  By that time in the project it may be too late to make significant corrections or adjustments without jeopardizing the entire project timeline and budget.

Make sure you invest in your own project team’s training

As a customer there are several things you can do to help ensure that the correct SAP software configuration and settings are made even though you as a customer may not know what they should be.  Here are the major ways to ensure good software configuration.

SAP Project Team Training

First and foremost to ensure appropriate SAP software configuration and to ensure you get good SAP consultants make sure you invest in your own project team’s training.  This critical training should be budgeted for right from the beginning and do not let any SAP system vendor talk you out of it.

An educated client is a sophisticated client, and sophisticated clients usually have the best implementations.

Some system vendors will try to convince you that they can teach your project team rather than having you send your people to independent SAP training.  That is a great way for them to “control the message” you receive about SAP’s functionality and the consultant’s level of skill.  Often times the “pitch” they use to try to sell you on the idea that they should be training your people instead of you sending them to training is that it is cheaper.  But if you do the math for the consulting hourly rates and then factor in the consultants’ time away from value added implementation efforts it doesn’t add up.  Often it is less expensive to send your project team to formal training and even if it isn’t, you still need that independent oversight.  Only independent training ensures your people really know what they need to know.

SAP Prototyping and Proof of Concepts for SAP Project success

I personally favor the prototyping approach.  The reason is that if you are a customer who wants to make sure you have the resources you are paying for this is the easiest way to find out.  By requiring a baseline proof of concept no later than the end of your Blueprint phase you will quickly see which consultants have real experience that the SAP system vendor has provided.  By contrast you will also see those who lack the experience as well.

In the SAP ASAP methodology one suggestion is that the initial baseline prototype (the first one done right at the end of blueprint) might cover 50 – 80% of the business requirements. 

For more information on prototyping and the steps for ensuring project success please see the post ERP, SAP, or IT Project Management and Prototyping for Success at http://www.r3now.com/erp-sap-or-it-project-management-and-prototyping-for-success  

Be sure your system integrator’s consultants do FULL END TO END process prototypes.  For example just doing a single transaction is not enough to demonstrate the system will meet the business needs.  By the end of Blueprint a seasoned and experienced consultant should be able to demonstrate these simple, straightforward, and standard processes.

• In the SD area (Sales and Distribution) an order, and then delivery with picking and goods issues, and then an invoice must be created.  You may wish to have them post cash and then review the material and accounting documents as well.
• In the PP area (Production Planning) maybe you want to see independent requirements run through MRP and then convert the results into the purchasing and production documents.  From there you may wish to have them do the receipts, and the confirmations of the production on a material, and even shows costs.
• In the MM (Materials Management) area you may wish to integrate this with PP (or not) and have the consultant show you the requisition to PO to Goods Receipt to Invoice receipt and then application of cash payments to the vendor.

In other words a skilled SAP consultant can do the setup work to do at least a first pass at all of these processes by the end of Blueprinting.

Significant benefits of SAP Prototyping and Proofs of Concept

I strongly favor SAP prototypes and functionality demonstrations throughout any SAP project.  Prototypes can quickly expose process gaps, potential integration problems, business process issues, and ensure that testing is smoother.  One of the significant advantages of prototyping is that it places an emphasis on overall business processes.

By relying heavily on prototypes and functionality demonstrations throughout an SAP project you help to ensure that the project team works more closely together, that only the best consultants are provided by the integrator, your internal client project team acquires more knowledge sooner in the process, and a better go-live.

Related Posts:

• SAP System Vendor Project Success Criteria & Factors 2
• SAP Success Factors for Vendor Selection – Responsibility Matrix 1
• SAP System Vendor Project Success Criteria 1
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Using SAP to Improve Revenue and Profitability

 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!

Legend

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:

• Effectively Scope Your SAP Project 
• Aligning SAP Scope to Meaningful Business Requirements

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

http://www.r3now.com/1/ASAP-OCM-Deliverables.pdf

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:

• Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 1
• Leading Change (and Change Management)
• SAP as a Change Enabler

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

• SAP Implementation Focus, Software Engineering or Business Process 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
http://www.r3now.com/sap-implementation-partner-or-company-selection-criteria

The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors
http://www.r3now.com/the-top-5-erp-success-factors-by-project-stage-from-22-critical-success-factors
 
SAP Project Success Factors with Vendor Selection Responsibility Matrix
http://www.r3now.com/sap-project-success-factors-with-vendor-selection-responsibility-matrix

SAP Success Factors for Vender Selection Responsibility Matrix 2
http://www.r3now.com/sap-success-factors-for-vender-selection-responsibility-matrix-2

SAP System Integrator Shared Project Success 1
http://www.r3now.com/sap-system-integrator-shared-project-success-1

=========================

[FN1]  Information on the Solution Composer tool, and its use can be found here: 
http://www.sap.com/solutions/businessmaps/composer/index.epx

To download the tool (free of charge) you will have to register here for access:
http://www.sap.com/mk/get/g-smcentry

[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:

• SAP System Vendor Project Success Criteria & Factors 3
• SAP System Vendor Project Success Criteria 1
• SAP Success Factors for Vendor Selection – Responsibility Matrix 1
• A New SAP Implementation Methodology and Implementation Steps
• More on Stupid SAP Vendor – Partner Selection RFI-RFP Processes

SAP Project Success

Using the success criteria table laid out in SAP Success Factors for Vender Selection Responsibility Matrix 2 as a starting point for shared SAP project success we will look at some strategies, tactics, techniques, and ideas for managing these shared responsibilities.  By more aggressively managing these shared SAP critical success areas we can set the correct tone and expectation for the SAP project. [FN1]

This series will look at the types of things you should expect from your SAP system vendor, and how to ensure your SAP vendor is focusing on the critical issues for project success.

====================

Because of the importance of each of these SAP Critical Success Factors a set of posts covering the shared responsibilities will be evaluated.  Because of the shared responsibilities for each of these success criteria they are often some of the most common problem areas.  When one party (either the vendor or the customer) falls short of success it is a common (and maybe natural) practice to try to deflect the blame by pointing at the other party.

Both customers and vendors must aggressively address the areas of success where they have the primary responsibility.  Several of these success criteria have been extensively written about on this site and rather than re-phrase some of those high points the links to posts with more detail are included.  For SAP project success it is critical for customers to manage the SAP partner relationship by regularly verifying these critical success criteria items are being properly addressed.

Do not allow the overall control of your project to be taken over by the consulting project manager

Legend

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

Your approach to any or all of thse SAP success criteria items may be different.  In the end it is important to understand that failing to address any of these success items creates risks that should must be mitigated.  Your responsibility as a customer is to do whatever it takes to manage the SAP partner relationship rather than allowing the SAP partner to manage you.

5.  Experienced SAP Consultants

You entrust your entire business to “seasoned” SAP consultants that your SAP system integrator provides.  However too often these same system integrators, anxious to keep high margins and remain “competitive” often bring in consultants with less experience than you need to be very successful.  This topic has been explored in detail on this site with what you need in a “good” consultant, the consequences of bad consulting, and the steps to take in finding a good consultant.

To ensure the best possible results it is important for you to verify and validate the skills and experience of EVERY consultant your SAP system integrator provides.  Failing to do so may cause areas of your project to fail to see any business benefit.

How well the project is managed and delivered is up to you as a customer

After all of the time, effort, and trouble through the entire selection process that last part of due diligence, in verifying EVERY vendor consultant, is critical for success.  Here are some key resources to consider when it comes to selecting consultants.

• Successful SAP Project Team Composition – Technicians or Experts?
• SAP Technicians or Experts
• Screening Methods to Find the Right SAP Consultant
• Screening and Interview Methods to Find the Right Consultant – Part 2
• Certainly Certifiable – SAP System Integrators Not Just Consultants

The SAP implementation vendor is almost exclusively responsible providing high quality resources for your business project’s success.  However, because of their margin requirements you don’t always get good resources from them.  Therefore you will have to do some of the important due diligence to ensure you do not get taken.

7.  SAP Implementation Strategy

There are three key factors to consider for your SAP implementation strategy.  These are the implementation methodology, vendor type, and the project implementation approach.  Each of these components of your overall implementation strategy are important for achieving SAP and ERP project success.  To gain greater understanding and insight on these key SAP implementation strategy factors the following post provides details to consider:

• SAP Project Implementation Strategies and Approaches

8.  SAP Project Management

The key parts your SAP project management efforts usually involve budget, scope, timeline, resources, and deliverables. The various types of flavors of monitoring and managing tools are as different and as diverse as the companies or project managers performing the function.  The SAP ASAP methodology provides deliverables lists and templates with full explanations for the entire project lifecycle.

Properly structured deliverables will help to monitor execution progress.

Here are some key resources from this site related to project management:

• ERP, SAP, or IT Project Management and Prototyping for Success
• ERP Project Planning – Getting Real (Part 1)
• ERP Project Plan: Getting Real (Part 2)
• ERP Project Plan: Getting Real Part 3
• ERP Project Plan: Getting Real (Part 4)

The primary responsibility for successful project management falls to you as the customer.  This means that you must not allow the overall control of your project to be taken over by the consulting project manager.  That does not mean they should not have input, and it is almost exclusively the SAP partner’s responsibility to provide an initial project plan, but at the end of the day how well the project is managed and delivered is up to you as a customer.

The SAP ASAP methodology provides deliverables lists and templates with full explanations for the entire project lifecycle.

For SAP project managers from consulting firms one important “skill-set” is the ability to set, manage, and deliver expectations.  Part of that also involves social skills that might be more political in nature, including the ability to deflect criticism of their project management.  As a result when reviewing a potential SAP project manager it is critical to dig past a possible “glowing reference” to actual results. Part of the successful SAP project manager’s job (from the consulting firms) is to help set and manage your expectations.  Some of this is necessary but some of it can be abused as well.  Do not allow yourself to give up control of your project to a consulting project manager.

At the end of the day, the most effective project manager will personally “own” the success of the project.  What I mean by that is they will avoid laying blame because the success of every project team member (both of the consultants and of your own staff) is a direct reflection on their success.  A project manager who finds “fault” with a resource but does not take clear corrective actions before it becomes a crisis is not much of a project manager.

A good SAP project manager from the consulting world has enough experience with using properly defined and designed deliverables to be able to track and monitor project progress.  If they have enough skill and experience at managing those deliverables as well as the tracking and monitoring tools then they can do the necessary resource adjustments and resource leveling that are necessary for success.

A good SAP project manager must take clear corrective actions before an issue becomes a crisis. In any reference check make sure you drill down to the details of the actual project delivery, not just personality issues.

Some of the steps, techniques, tactics, or strategies for finding a good SAP project manager are:

A.  Look for an experienced SAP project manager who has actually done SAP configuration before being a project manager in either a supply chain area (SD, MM, PP) or in finance (FI or CO).

B.  When checking references it is CRITICAL to ask results-oriented questions that go beyond the personality of a particular project manager.  In any reference check be sure to drill down to the details of the actual project delivery.

a.  Was the project delivered on-time or on budget?  If not it may (or may not) reflect poor management or poor scope development, in either case it is a warning flag.
b.  Did the project manager provide the necessary tools and templates ahead of time for success?

i.      Project plan – BEWARE project or program managers who do not provide a project plan or seem to have a hard time working with very basic project tools such as MS Project.
ii.      Deliverables list.  Properly structured deliverables will help to monitor execution progress and roll up to higher level project plan items to prevent micromanagement of project activities.
iii.      Training, Change Management, Knowledge transfer plan
iv.      Progress monitoring and tracking resources down to the delivery level.  Many PMs will monitor budget and not the actual execution level of project delivery.  If they do manage the execution it is usually at a micromanagement level of the project plan which can kill productivity.

C.  When checking project manager references remember, the project manager is responsible for overall results of completion of deliverables related to project success.  So it is important to ask prior clients about:

a.  Testing, was this purely “success testing” to get signoffs or was “challenge testing” allowed to discover defects outside of the scope of testing documentation?
b. Were there significant data problems after go-live?
c. Was the project delayed several times because the scope and timing were so tight that the go-live was excessively risky?
d. Were the consulting company resources underestimated or scope changes so significant that many more consultants needed to be added?
e. What about additional software or technology, were those things missing from the original scope, quotes and estimates?

9. SAP Tools, Templates and Resources

Assuming you are using the ASAP methodology, many of the templates, tools, and resources are clearly defined and initial examples are provided, see SAP Project Implementation Strategies and Approaches.

Where these may need to be supplemented with vendor specific examples is for training, change management, security / system authorizations, and the deliverables tracking tools.  The deliverables themselves should be defined right from the beginning of the project and the SAP ASAP Implementation Methodology contains a presentation template with a full deliverables list and includes many templates for those deliverables.

Effective SAP deliverables will include a mechanism to monitor progress toward completion.

With this background, during the sales cycle, it is absolutely imperative to insist that every vendor provide ACTUAL example templates that show experience in this area.  Every one of them will claim they have the resources every time.  None of them will admit otherwise so you primary job is to verify their claims.

Vendor sales people are taught how to say “yes” even as they are telling you “no”

The key factor to consider when looking for templates, tools, and resources are do they support proper tracking and monitoring of deliverables progress?  In other words, beyond the project plan itself, are the deliverables designed to integrate progress monitoring?

==================

[FN1] Please see the following links for more background information on the development of the SAP Project Success Factors with Vendor Selection Responsibility Matrix and some of the source material from The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors .

Related Posts:

• SAP System Vendor Project Success Criteria & Factors 4
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• SAP System Vendor Project Success Criteria & Factors 3
• Some Reasons SAP Projects are Over Budget and Over Time
• Reduce SAP, ERP, or Technology Project Stress: Part 2