SAP & ERP Consulting from the Customer Point of View

SAP implementation ROI, SAP architecture, & SAP business solutions

How the SAP Consulting Peter Principle Works

September 12th, 2011
SAP Peter Principle

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:

Steering Committee Governance for an SAP Center of Excellence

July 11th, 2011
Business to IT Convergence with an SAP Center of Excellence

SAP Center of Excellence Governance

This post is based on information from my recent ASUG presentation in Atlanta…  Beyond Technology Alignment – Building a Center of Excellence @ http://bit.ly/jJefxP

————————-

At the intersection of business and IT you have convergence.  At the place of convergence is where the Center of Excellence exists.

————————-

One of the key SAP project success factors is to use a steering committee made up of key business stakeholders.  They can meet once a week or once a month, but generally they are involved to provide business level guidance to an SAP project or IT programs.  The most effective steering committees include at least one executive and several senior leaders from throughout the business (see The Real Reason Executive Participation Creates IT Project Success).

That steering committee performs a critical function over large projects like SAP implementations.  This group is critical to your project’s success because of the amount of time from company employees, capital from the organization’s coffers, and decisions which change the business.

Some of the key functions a steering committee carries out during the course of your SAP project include:

  • Set SAP project scope and then help manage it.
  • Define project objectives and evaluation criteria.
  • Monitor project progress, including key milestones and deliverables progress.
  • Oversee Quality reviews at key check points.
  • Evaluate and mitigate organizational impact of business changes.
  • Promotes the project throughout the organization.
  • Coordinates staffing and resource levels from key business areas.
  • Makes critical decisions which the project team is unable to resolve (escalations or key business decisions).

The ongoing functions and tasks of the SAP steering committee cannot be underestimated. During the course of their duties they gain that list of unique and critical skills related to applying technology to business issues and problems (see Using Your SAP Steering Committee for Business Transformation).

You go live and WHY do you disband your steering committee???

Integrating the SAP – IT Organization Into the Business

In an SAP Center of Excellence, after your SAP implementation goes live, the steering committee functions change to one of developing and managing technology road-maps.  Their skills with scope, schedule, cost, performance, prioritizing, and evaluating risks / rewards are ideally suited to their continued involvement in the application of technology to the business.  But the underlying issue here is that they must continue to function –, they should not be disbanded.

One of the key benefits of continuing to leverage the SAP Steering Committee after the SAP business software goes live is you continue to build on their experience and unique skills.  Even as they rotate out of the steering committee role these individuals move through the ranks of the larger enterprise and take that technology to business integration experience with them.  If they have served on a steering committee long enough to see the benefits technology can bring to the larger enterprise their exposure is invaluable to building a long term Center of Excellence –, an organization dedicated to converging business and technology to meet business marketplace requirements.

These individuals have worked through many key business decisions, budget decisions, scope and schedule decisions, and how to move to technology integration project success.  As a result of their experience applying technology solutions to the business they develop critical skills for the converged and integrated organization, these skills are difficult to replicate.  In a nutshell this steering committee develops a convergence of three critical skills for tomorrow’s powerhouse enterprises: they understand management, technology, and business integration.  Those are the key ingredients to the converged SAP enterprise.

Related Posts:

ERP Education: Losing Our Religion

January 17th, 2011
Planning, coordinating, training

synchronizing success

Most ERP software packages are designed around industry accepted business practices, operating philosophies and techniques that have evolved over many years. Today the issue is not whether there is a body of knowledge with supporting software tools, the question is… are clients educated enough to see the value or understand the proper use of the tools. The short answer is no.


Education versus ERP software training

First, many have lost site of the fact there is a difference between education and software training. End user software training is very important but it is mainly about how to do transactions in the software and how these transactions related to your business processes. However, this can be very different from understanding the original design intent and industry application of the tools.

For example, the issue of education vs. software training is analogous to training someone to fly a 767 but not educating them on the concepts of jet propulsion or flight; or how to start-up a chainsaw but not the best way to cut down the big tree. Both of these are scary propositions, but in terms of ERP projects it is about failure to achieve the business benefits. At the root of the problem is senior managers and end-users never changed their behaviors to take advantage of the tools; and a big part of this is lack of education.

Independent Sources of ERP education

Keep in mind, education is more than just a seminar of “best practices” put on by a software vendor (with a hidden agenda) in room full of 300 other clients. It is about getting some real independent education, not focused on any specific package. In addition to understanding key concepts, one must also delve into the mechanics in order to implement.

Baked into the ERP implementation methodology

There once was a time when management and user education were part of the standard implementation methodologies. Interesting enough the project success rates was much higher.

For example, it is worth noting the great Joseph Orlicky wrote the first groundbreaking book on the topic of MRP (forerunner to ERP) back in 1975 (updated and still a good read). It focused on concepts and techniques on how to plan and control materials in a manufacturing plant. However, the most interesting thing is Mr. Orlicky (an employee of IBM) never glorified the role of the computer. He believed if one did not understand the underlying principles of MRP, the computer was not much help anyway.

However, the late Ollie Wight (the godfather of MRPII) said it best “MRPII is not a computer system, it is a people system made possible by the computer”. Orlickly and Wight went on to build and grow the “religion” called APICS (The American Production and Inventory Control Society). The best thing that ever happened to manufacturing practitioners.

Back to ERP Basics

Today there is a disconnect between industry best practices and what clients attempt to do with their systems. It might be time to get back to the basics of blocking and tackling or at least try to understand the intent of the package you just purchased.

Instead, we focus on the gee-whiz aspects of software, technology, implementation tools, and turnkey solutions (which usually exist only in the marketing literature). Cheaper, faster and the slam-dunk mentality is the name of the game, even when we do not accomplish anything worth the effort. We naively assume the mere existence of better tools automatically results in a change in employee behavior (if we build it, they will come). We fail to educate senior management and then wonder why they are not committed to the project. We set higher expectations of our employees, yet as leaders, we fail to provide them with the knowledge they need to succeed. When our projects go down the tube, we blame software vendors, consultants, the entire senior management staff, all employees, our spouse, and everyone else except ourselves.

No, education is not glamorous so proposing it will not make you a hero. Nevertheless, it is the stuff successful IT projects are made of. If Ollie knew what was going on today he would roll over in his grave.

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

Contributed by Steve Phillips of the Street Smart ERP Blog – Visit his site for more great project insight.

Related Posts: