SAP & ERP Consulting from the Customer Point of View

SAP Program Management

Many may be unaware that SAP provides a broad set of tools and resources for Program Management and Competency Maturity Management (or CMM). Very few are familiar with SAP’s broad set of supports for this purpose such as the “new” ASAP Methodology Phase 6 “Run” enhancement. It is loaded with key information which aligns with Program Management responsibilities and CMMI.

So, what is CMM (or CMMI as it is more properly referred to)?

“CMMI (Capability Maturity Model Integration) is a process improvement approach that provides organizations with the essential elements of effective processes, which will improve their performance… CMMI models are collections of best practices that help organizations to dramatically improve effectiveness, efficiency, and quality” [FN1].

The entire CMMI methodology and development is maintained at Carnegie Mellon’s Software Engineering Institute. These CMMI standards have been applied in a vast number of organizations together with various methodologies. The CMMI approach is well suited to engineering and software development, design, or implementation. SAP’s entire ASAP methodology, and especially the “new” Run methodology incorporates a number of CMMI principles.

SAP Program Management is all about Competency Maturity Management (or CMM)

The contract SAP program manager is accountable for providing the key tools, templates, techniques, and resources to ensure projects are properly managed and delivered for business benefit. If they are not providing this type of methodology guidance, including key templates and techniques to deliver business benefit, what are you paying them for?

SAP Program Management or Project Management Gaps

After all these years one of my biggest frustrations is the lack of SAP contract program or project managers use of the ASAP Methodology. They all talk about it, and during sales presentations they use lots of SAP’s material, but as soon as the project begins you never see it. They seem to have absolutely no idea what they are doing.

As I have often said, I never believe that a client / customer of project management or program management services has the primary responsibility for this knowledge. If they did why bother hiring outside help and paying the rates for this service except for that contract “expertise?”

Contract SAP program management or SAP project management that is not able to deliver on clearly understandable methodology development are fakes. Anyone can call themselves a program manager, but what does that mean? What is the contract SAP Program Manager accountable for? What are they on the hook to deliver and how is their performance measured?

Using SAP ASAP and CMMI to Mature the SAP Enabled Enterprise

The SAP ASAP Methodology, in particular the Phase 6 Run section, should be studied by every SAP program manager before they start doing project or program work. Even though it is in the last ASAP Methodology phase, its greatest effectiveness is realized when you begin your internal SAP delivery maturity planning from the beginning of your SAP project.

One of the critical benefits of starting your CMMI related planning right from the beginning is your SAP project can be structured to support business integration at the outset. Using this type of maturity model integration as part of your project guidance can have significant benefits to the enterprise:

“Many CMMI using businesses have beneficial results to their bottom line… including improvements in schedule and cost performance, product and service quality, forecasting accuracy, productivity, customer satisfaction, return on investment, and other measures of performance” [FN2].

SAP has already done a significant amount of the work for you. All your program manager has to do is adjust the plans, alter the templates, follow the ASAP Methodology instructions, and build the resources to support this transition. You really must question SAP program manager service providers who do not keep up with the ASAP tools and delivery methodology that SAP provides and supports.

SAP’s Competency Maturity Model Starting Point

The following maturity model is just one small example of a powerful tool that is critical for long term technology and business integration [FN3]:

This model, provided freely by SAP as part of their standard ASAP methodology is a great starting point. Your contract SAP program manager should be able to use this as it is, or adjust it to fit your particular organizational needs. This is just one very small component of the Run Phase and an even smaller component of the entire ASAP Methodology toolset.

In many cases you would be better off sending your own internal employees to SAP ASAP certification courses and Microsoft Project classes and making use of their new found knowledge. At least then you would have a knowledgeable employee who could help keep an integrator who claims to use ASAP honest. And if they claim to use ASAP in their sales materials or sales pitches GET THAT CLAIM IN YOUR STATEMENT OF WORK AND YOUR CONTRACT WITH THEM!

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

For more information on related topics please see:

• SAP Project Manager – SAP Program Manager, Lessons from the Trenches
• Effective Results from SAP Project Managers – SAP Program Managers
• SAP IT Convergence Beyond Business to IT Alignment
• Create SAP Convergence Instead of Business to IT Alignment
• Integrating Business Stakeholders as Part of SAP IT Convergence
• Steps to Achieve SAP IT Convergence
• SAP IT Convergence is About Business Focused Integration
• Steering Committee Governance for an SAP Center of Excellence
• Using Your SAP Steering Committee for Business Transformation

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

[FN1] CMMI Overview: Software Engineering Institute at Carnegie Mellon University, retrieved November 5, 2011. http://www.sei.cmu.edu/cmmi/

[FN2] Why CMMI: Software Engineering Institute at Carnegie Mellon University, retrieved November 5, 2011. http://www.sei.cmu.edu/cmmi/why/

[FN3] SAP ASAP Methodology version 7.1, WBS 6.2.1 – Table 1: Maturity Level Characteristics. For more information on the SAP ASAP Methodology please go to http://www.sap.com/services/more/servsuptech/asap.epx

Related Posts:

• Steps to Achieve SAP IT Convergence
• Steering Committee Governance for an SAP Center of Excellence
• ERP and SAP Business Case for ROI, Business Benefit, and Success
• Why Use the SAP ASAP Methodology?
• SAP IT Governance, SAP Program Management, SAP PMO Metrics

SAP Offshore Development

My experience with SAP offshore development is that no matter how detailed your spec is their lack of experience with standard SAP transactions and functionality means they will never properly test their own creations.  Their results are more than just full of bugs, often times they crash when attempting to do even basic testing.  Repeat testing by expensive functional resources happens so frequently and consumes so much hidden time from parallel project activities that entire project timelines are frequently affected. 

Functional resources have to babysit and handhold these SAP offshore resources through the whole process because of the language barriers and lack of experience.  More functional time, more project management time, more unplanned distractions from functional Realization activities and your entire project timeline can be wiped out.  If that happens you have to pay even more for a missed development date because you have to move your go-live date.  And that cost is completely hidden from you by some of the shell games they play on their supposed efforts.  All of that functional time and the risks to the project timeline point to some of the real hidden costs of SAP offshore development. Develop, test, bugs, fix, develop, test, bugs, fix, rinse and repeat at least a dozen times.

A common SAP offshore practice is to keep throwing “crap” at you saying it is “done.”  With all of the crashes and bugs that are so common with offshore development, and especially all of the program crashes, how much testing could they have done?  The bigger question is how much is this really costing you and how do you find the hidden costs?

SAP Project Timeline and Budget Due Diligence

Because of the nature and pace of SAP project work whenever the issue of blown budgets and blown timelines come up most companies rarely perform root cause analysis or due diligence.  Instead the accusations and recriminations fly in the heat of the moment.  Meanwhile the offshore developers keep saying “we finished x development on y date… the functional teams didn’t support us…” or “the specs were bad and we had to make 20 changes…”  You name it, the extent of the excuses are never ending.

Evaluating Hidden SAP Offshore Development Costs

Because of how SAP “functional” consultant time (needed to support the offshore development) is hidden from you it never shows up anywhere in the rates you were quoted.  You really have no idea about the real Total Cost of Ownership (TCO) for that offshore SAP development.  The offshore company constantly claims the “specs were not detailed enough” or every microscopic change and adjustment becomes a “change order.”  I’ve even seen this where standard SAP functionality was completely broken by the development and the developers insisted because there was nothing spelled out in the design spec about allowing standard functionality to continue working a change order would have to be separately paid for!

On new SAP implementations the functional time premium can easily cost you 50% to 75% (and in some cases even exceed 100%) of the total development hours.  Think about that for your next quote as you try to put the pen (or your spreadsheet) to the numbers.  Have you really factored in the amount of high priced functional resource time needed to support those “inexpensive” offshore developers?  Between writing “super enhanced” specification documents, repeated endless functional testing of buggy SAP development, “training” of inexperienced developers, language barriers, “babysitting” the actual development, and the lost opportunity to focus on other functional Realization activities can kill any supposed savings.  It’s all a shell game.  You pay just about the same amount (and on many occasions even more) with far more headaches and lower likelihood of making your go-live date.

Even after all of this, there is still one more hidden cost that is not realized immediately at go-live–, the cost of poor coding.  You may have significant performance problems, constant bug fixes, and a whole host of other maintenance activities that you never planned or budgeted for.  Now this is true of any development but because of the language translation issues and the modest (at best) quality of coding you are likely to have incrementally more production maintenance costs with the offshore development.

Some Considerations to Help Reduce The SAP Offshore Development Shell Game

First and foremost NEVER accept the offshore development group’s code review options.  One way you can help to combat so much of this is to budget for at least one local developer, even at premium rates, to serve as a quality checker.  They do not have to review all of the code from all of the developers but they should look for the “tells” of experience over inexperience.  And your SAP statement of work (or SOW) as well as your contract with the offshore developers should include various protections about the quality and expectations of the development work and functional consultant time and contributions.  That SAP SOW should also include some definition around what a “change” is and what a “defect” is.  Without that everything will be considered a “change request” and destroy any supposed savings.

Next week the wrap-up part 3 of this series:  Where Does SAP Offshore Development Make Sense?  There are some situations where it is a great cost saving alternative.

Related Posts:

• Where Does SAP Offshore Development Make Sense?
• SAP Offshore Development Project Experience
• More on Stupid SAP Vendor – Partner Selection RFI-RFP Processes
• How the SAP Consulting Peter Principle Works
• Steering Committee Governance for an SAP Center of Excellence

SAP Peter Principle

Most of us working in business for any period of time have heard of the “Peter Principle.”  It was “formulated by Dr. Laurence J. Peter and Raymond Hull in their 1968 book The Peter Principle, a humorous treatise which also introduced the ‘salutary science of Hierarchiology’ …” [FN1]  While the exact quote is a little different, it has come to mean that people tend to rise to their level of incompetence in organizations built on hierarchies.

As an important caveat before getting into this topic, I have known many really hard working folks who have risen through the ranks the “old-fashioned” way –, through hard work and “paying their dues.”

My Experiences with the SAP Consulting Hierarchy

After over 20 years in IT, and over 20 SAP projects, I have seen the Peter Principle again and again.  It’s the nature of how the IT consulting world works.  It is frustrating, and it is enough to drive the competent, diligent, and most talented consultants absolutely crazy.

The “Peter Principle” happens in the consulting world because this is what organizations who implement SAP demand of their implementation vendors.  Sure, that sounds counter-intuitive and crazy, but unfortunately it is a sad reality.

You might be asking yourself right now, IS HE CRAZY?  Maybe a little, but on this point, let me assure you, it is quite true and in a moment you will see exactly how it happens and why.

Enter the Crazy World of Consulting – Why Consulting Incompetence is Rewarded

Once inexperienced, incompetent, or “less than optimal” consultants get onto your SAP, ERP, or other IT project, you are now set up for seeing the “Peter Principle” in effect.  On your implementation or upgrade project an inexperienced or incompetent consultant will ultimately make a mess, however it won’t be seen right away.  There may be signs along the way, but only deep experience will recognize this unless it is blatantly obvious.  There is always some reasonable sounding explanation, or some gibberish, or some babble that is pronounced with confidence but you don’t really understand it. Or, they have become polished and provide entirely rational and reasonable explanations, whether true or not.  After all, they are the “expert” you hired so they must know what they are talking about, right?  Nonsense!

First Sign of the SAP Peter Principle

“Blah, blah, blah”  I have no idea what you just said but just so I don’t look stupid I’m not going to challenge it.

As I’ve written on many occasions, part of the key skills and experience a good consultant or business analyst MUST possess is the ability to take the complex and make it simple.  ANYONE can take something complicated and keep it complicated, or worse still, make it more complicated, or, worst of all, make it a mess.  It takes experience and competence to take the complex and simplify it.  But all that “technical babble” and jargon sounds so convincing, so educated, so, foreign.  It’s a foreign language that you don’t completely understand and these incompetents know it.  Unscrupulous consultants know if they can make something up and sound as though they know what they are talking about you will believe them –, you hired them for their expertise.  They can game you to increase scope, or extending project timelines, or busting your budget and they do this because they are personable and manipulative.

How Can You Identify the SAP Con Artists?

Accountability, Responsibility, and Quality.  The cons avoid accountability or direct responsibility.  On a project where they are discovered they must be nearly forced to have clear accountability for delivery.  They must be pressed into doing what I call “due diligence” around a solution to make sure it will work correctly.

If you catch it early enough you can keep these incompetents from being rewarded for blowing your budget, causing project delays, and creating even MORE complicated and convoluted processes than you had BEFORE you did your SAP implementation.

How Customers Provide Perverse Rewards for Incompetence

The incompetent consultant’s area seems to have users who struggle with problems / issues / bugs that need the most fixing and the most attention.  By this time many companies have invested so much time and effort with the incompetent consultant that they don’t see any other options but to continue with this fraud.  The incompetent consultant is needed badly to support the mess they make for some time after you go live.

One way you can tell you have been manipulated or gamed during the project is by the quality, completeness, and accuracy of the solution the consultant delivers at go-live. 

From a consulting firm’s perspective, the incompetent consultant puts in lots of extra billable hours, helps them get extensions and budget increases, and needs to have lots of extra consulting support.  They are always behind, and no matter how hard “they try”, they always have another excuse for why the problems they cause really aren’t their fault–, it’s always someone else.

These consultants stay on long after go-live to ensure that their questionable solutions are supported by the same person who made the mess to begin with.  This is what customers insist on because by the time go-live happens they are “stuck” with the mess and “stuck” with the “con”sultant who made the mess.

Incompetent consultants tend to be VERY personable most of the time, and ingratiate themselves with the customer / client so that there is no question that they are working SO hard, and doing such a GREAT job.  It could never be their fault.

How SAP Consulting Vendors Reward and Promote the Peter Principle

For the consulting vendor, billing hours go up, staffing and utilization numbers are high, additional “backfill” support is needed and more people are staffed.  From their metrics and possible compensation incentives the incompetent consultant is doing a great job!  On the other hand the highly experienced, competent, and diligent consultants “work themselves out of a job.”  The competent consultants tend to have fewer go-live support issues, they usually have more engaged, involved, and knowledgeable users.  And they are just plain better prepared.  They are not “needed” as you go-live and you, as the customer, get rid of them to cut the blown budget wherever you can.

In a partner oriented firm the incompetent consultant is headed for being a manager, senior manager, managing partner, etc.  The incompetent consultant has great utilization, helps to get more staff on projects, and is always busy.

In the consulting companies incompetence is rewarded and incentivized by the consulting firms.  The most competent and diligent consultants are passed over for career enhancement precisely because of their competence – they may finish projects earlier than their incompetent peers and may be “on the bench” more frequently.

The more skilled the incompetent consultant is at being personable, at presenting a compelling case for why they are doing such a great job but you need more resources, the better positioned they are for higher level promotions.  After all, in consulting firms, senior level positions are focused on getting billable resources out and billing.  The more experienced and capable at this the better positioned you are for partner or senior management.

Stay tuned next week – details on how to spot them and then ferret them out…

Related Posts:

• Reduce SAP, ERP, or Technology Project Stress: Part 2
• Protecting Yourself from SAP Consulting Fraud
• Screening and Interview Methods to Find the Right Consultant – Part 2
• Screening and Interview Methods to Find the Right SAP Consultant
• SAP Offshore Development Project Experience