SAP System Vendor Project Success Criteria & Factors 2

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

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 can be described concisely:

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

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. Some system integrators use this tactic to misrepresent the amount of scope or of actual system requirements during the sales cycle, so they can 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 on you. 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, sometimes you need scope changes. As a customer, you need to ensure that you have a good first pass solution scope for your RFI and RFP processes using the Solution Composer tool. At the same time, a system integrator is responsible 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. Even so, 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 such as 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 two very important things:
- it helps you identify where you might have scope trouble, and
- it might point out some of the snakes in the marketplace.

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, 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 among 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. 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 your RFP may 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. The tool 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 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.

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 you need to make the early efforts to get scope correct for the RFP, vendor selection, budgeting, and reasonable project timeline, you will have some changes. The key is to revisit scope at the end of the blueprint phase of your SAP project. However, you need to heed caution. 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.

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

SAP Scope Management Tips

To avoid some of the business scope change requests, you need 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 where interested company employees can review it. Never allow an SAP system vendor to keep this hidden, because seeing the significant number of parallel tasks will help the employees 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 have 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, electronic gadgets, shoes, clothes, etc. Since we know new products and services do sell, we need to consider why.

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. Applying this to an SAP project, you need to communicate and market changes to your enterprise internally (employees) and externally (vendors and customers).

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 include 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 aware?
Do they know the project exists?
Do they understand the need for the project?
Are they willing to support the project?
Are they resisting the project?
Are they 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.

Tips for Communicating SAP Change

Ask people for their opinion before you implement change.
Explain the change in terminology that 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

https://www.iitrun.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 receiving the best benefit from your SAP implementation vendor choice, you need 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:

SAP Implementation Focus, Software Engineering or Business Process Engineering?

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

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)

A successful SAP project needs both project team training and end user training.

Over the years, I have developed a perspective that the project team members must receive significant training on SAP processes and SAP configuration. 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 can spot many of the less-than-optimal consultants and see through SAP system integrator tactics (see e.g. Screening and Interview Methods to Find the Right SAP Consultant ). A more sophisticated SAP customer ensures 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 intelligently promotes the correct design issues and focuses 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 they need to support the system after 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
https://www.iitrun.com/sap-implementation-partner-or-company-selection-criteria

The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors
https://www.iitrun.com/the-top-5-erp-success-factors-by-project-stage-from-22-critical-success-factors

SAP Project Success Factors with Vendor Selection Responsibility Matrix
https://www.iitrun.com/sap-project-success-factors-with-vendor-selection-responsibility-matrix

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

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