SAP ROI — Enterprise Architecture & Business Solutions

People, organizational, and change management strategies on an ERP implementation are usually more difficult than the technology implementation. 

ERP implementation changes to the business cause employees from different departments to become more knowledgeable about business in general (Hall, 2002) (see also  The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors about interdepartmental cooperation and communication).  While this is good, it also presents a set of knowledge transfer process challenges that consultants without the depth of project and business skill may not be able to navigate.  They may not even be aware of knowledge transfer techniques (see Screening Methods to Find the Right SAP Consultant Part 2 about the required skills and communication requirements of a good consultant). 

The Critical Nature of Training and a Knowledge Transfer Strategy and Techniques in Any SAP or ERP Project

ERP applications like SAP have a “single source” of information creating a need to develop understanding of business processes.  Duplicate entry tasks are eliminated and the degree of data accuracy is increased. Organizational processing speeds increase over time (after the initial learning stage downturn) and the dependencies between departments increases requiring a level of cooperation that makes some tasks and jobs obsolete.  Employee skill level and performance increases (Scott and Sugar 2004) making knowledge transfer techniques, like training, a critical component for long term success.

Different Types of Training are Needed for SAP and ERP Project Success

One of the biggest problems in workforce preparation for ERP applications like SAP is the type of training they receive.  The types of training you decide to use are all part of the knowledge transfer strategies, techniques, or methods to support business transformation.

Most companies only perform the traditional scripted keyboard training which consists of carefully controlled individual transaction exercises.  The training contains only a very limited focus on performing a small sequence of keyboard tasks to impart the understanding of a single transaction.  They generally do not transfer process related knowledge.  Often there is little or no knowledge transferred of:

• The significance of the data that is entered.
• Where that data is integrated into other parts of the system.
• What the underlying data dependencies are.
• What types of troubleshooting steps to take.
• What interdepartmental impacts exist.
• What part of the overall process is affected.
• Etc.

Together with these common gaps in knowledge transfer techniques and methods there is little ongoing followup after the system is live such as:

• Communications about maintenance or performance tips and tricks after the system is live.
• Additional troubleshooting training or techniques as they arise.
• Where to find key data and information for decision making.
• Etc.

Current knowledge transfer processes, plans, strategies, techniques, or methods do not include these key activities even though they are important for long-term business success. Essentially users are trained on what tasks to perform but little or no training is done to help them understand why the transactions are being performed.  They have little or no understanding of the upstream and downstream dependencies within their own departments and across the enterprise (Wheatley, 2000).  The type of insight that would produce these kinds of knowledge transfer plans and techniques only comes from significant experience.

The typical system implementation focuses on training individual transactions without the explanation of dependencies or processes.  This works for initial exposure to the system–, for learning the user interface and the new data entry requirements.  This method is not good for long term business transformation or for high productivity.

Successful Change Management Planning Requires Multiple Strategies and Types of Training — A New Training and Change Management Model is Needed

A more complete change management process and plan, which some companies installing SAP or other ERP systems conduct, is an explanation or overview of processes and how the transaction fits into an overall process stream.  This is still not a sufficient change management strategy  or process to ensure you are doing the right knowledge transfer methods and techniques. 

A more complete list of knowledge transfer methods includes several components:

1. Transactional processing (typical keyboard training).
2. Business process understanding (some projects use this method with transaction flowcharts for showing dependencies).
3. Master data dependencies (few projects do this level of end user training because it is generally the implementation consultants who have this level of understanding).
4. Operational processing (fewer projects still do this type of training because this is the production support “troubleshooting” type of training that requires seasoned consultants to be on site long enough to help users work through the issues).
5. Ongoing knowledge transfer activities such as ad hoc troubleshooting meetings with all affected users (work through problems as a group in a conference room).
6. Continuing communication about tips and tricks after the system is live.

The first 3 items on the list above can be carried out by competent and skilled training professionals.  Or, as many companies do, they can also be done well by training team members.  Most consulting companies use a method called the “Train the Trainer” approach. This approach relies on teaching internal company employees how to teach, or train, the transactional (keyboard related) courses.  It relies on them to be able to walk-through carefully scripted and controlled user exercises of limited and discrete transactions.

The “Train the Trainer” approach is a good knowledge transfer technique or method for many companies if the staff they have provided is not stretched so thin that they have an opportunity to learn what they need to know.  For this to be effective it also requires the consultant to be skilled enough to transfer the critical understanding needed to be successful. If a consultant has deep experience they can transfer the transaction knowledge together with the data dependencies, key process understanding, and even troubleshooting tips.  If the consultants on the project are unable to do this then it is highly likely that they do not have the experience you may have been presented.  Your engagement agreement may be beneficial to include some type of language to support the knowledge transfer requirements, not just that it should be done, but expected results of that knowledge transfer.

If the consultants on the project do not have a good overall process understanding your trainers will struggle and the fourth item, the exception processing, will be nearly impossible.  For example a good consultant’s knowledge transfer plan should include the ability to transfer understanding of the entire process cycle of their area such as:

• Order to Cash
• Requisition to Payment
• Plan to Produce
• Etc.

My experience is that the “Train the Trainer” approach is the most effective method for knowledge transfer to internal employees.  And in turn, good knowledge transfer for internal employees helps to ensure longer term change management.  As a result of the need to understand the overall process cycle area the consultants must have deep experience in their respective area of expertise.

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

Hall, R.(2002), “Enterprise Resource Planning Systems and Organizational Change: Transforming Work Organizations?” Strategic Change, Vol. 11, pp. 263-270.

Scott, J. and Sugar, D. (2004), “Perceived Effectiveness of ERP Training Manuals.” Proceedings of the Tenth Americas Conference on Information Systems, New York, pp. 3211-3215.

Sia, S. and Soh, C. (2002), “Severity Assessment of ERP-Organization Misalignment.” Proceedings of the Twenty-Second International Conference on Information Systems, New Orleans, pp. 723-729.

Wheatley, Malcolm (2000), “ERP Training Stinks,” CIO Magazine, June.

Related Posts:

• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Using SAP to Improve Revenue and Profitability
• SAP Implementation Partner or Company Selection Criteria
• The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors
• ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?

Let’s develop a project schedule people can believe and support. After all, it is people that must make any schedule a reality.

When it comes to ERP project planning, there is nothing wrong with an aggressive schedule. In fact, it is encouraged. However, being dumb about it is a different story and only results in a plan that is eventually tossed out the window. We are now operating in the blind and later must deal with the ramifications of unrealistic expectations.

Edicts do not always work 

First, there is a false premise when senior management edicts a date, it will somehow automatically happen. No matter how well intended, edicts with no supporting detail behind them rarely accomplish anything (or cause even more confusion). In addition, some organizations waste years selecting ERP software or approving a project, then attempt to slam-dunk it within six months or less.  Finally, some use the same bad software for eons, and then suddenly wake up one day and insist on replacing it almost overnight. I have some bad news; “it ain’t gonna happen”.

Project Managers can be their own worst enemy

Some project managers publish dates without a clear understanding of how they are going to get there. Others develop valid schedules and later cave in to unreasonable schedule demands. These demands usually come from people that understand little, if anything, about the project details. As a project manager sometimes you just have to say “no”, and take the political risk of doing so. It comes with the territory.

The Sales Pitches are Over; it is Time to Deliver the Goods

In the meantime, some software consulting firms are no help in setting the right schedule expectations. Many more or less throw darts to come up with dates or attempt to use “templates” as a substitute for project management experience. Other software consultants intentionally “low ball” the schedule and do the “bait and switch” maneuver after they get their foot in the door. It is amazing how many clients fall for the oldest trick in the book. 

It can get worse. Even after services are sold to the client, some firms continue to act like sales people (or master of ceremony) not project managers. For whatever reason, they cannot bring themselves to tell client management any bad news. This is unfortunate because the client is paying consultants big bucks for their expertise.

The point is, when outside help is required to develop a project plan,  get project management consultants very familiar with the software and have scheduled the implementation many times before (on projects within a similar industry, scope and complexity). Also, hire consultants that will not sugar coat the real issues. What you need now, more than anything else, is the truth. Finally, never let consultants develop a schedule in a vacuum. The client must be heavily involved from the start, help shape and develop the plan, get their hands dirty, and understand the assumptions behind it.

There are Consequences to Your Project Planning

One might say, “So what, we missed the schedule. We will revise the schedule, and give it the old college try again”. Unfortunately, when we totally miss the mark, good things rarely happen:

The Project Plan Relationship Between Time and Money

An invalid schedule usually means a blown budget down the road. When a project budget reflects a twelve-month schedule, but it actually takes sixteen months, do the math, and assume consultants cost at least $150/hr and you probably have more than one.

The Calm Before the Storm

While it appears everyone on the project is busy working on something, the question is, are they working on the right things, and at the right time? When they are not, it usually means delays and rework later. This is not about poor budget estimating; it is money that otherwise should not have been spent. This is one reason why software consulting cost can average 60% or more of the total project cost. I do not know about you; but this is an unacceptable percentage from my perspective.

Deflating Those that Must Make Your IT Project Happen

When a project schedule really is not doable, it is not hard for most people to figure out. In this case, do not expect the project team to get too excited about attempting to implement a plan that is doomed from the start. I cannot say I blame them. 

Feeding the Naysayers

Any project has doubters throughout the organization, but when we incur schedule slippage due to poor planning, this only fuels the informal grapevine. “See, I told you they do not know what they are doing”! This certainly does not help the cause of the project, the team or make “organizational change management” any easier.

Taking Project Planning Shortcuts

No matter what implementation approach or methodology utilized, in order to get back on schedule people sometimes do nutty things. The result can be a host of unintended consequences such as poor software quality, higher cost, lack of user acceptance and failure to achieve project objectives.

A Project Schedule is Not a Wishlist

The goal is to produce a valid project schedule that achieves project objectives. In addition, a schedule the project team and key client stakeholders believe, support, and can actually use to manage the project.  

In terms of a timeline, a good project schedule is not necessarily one that depicts what we ideally want to occur. Nor is the sole purpose to “light a fire” under those that must make it happen. Above all, the project schedule should reflect reality.  If not, no one except the project manager and consultants will own it. The problem is, for the schedule to actually materialize; all key client stakeholders must first believe it, in order to get behind it (including sr. management, the project team, IT, key functional managers).

Once senior management agrees on project objectives, scope, resources and the schedule is properly developed, adjusted and verified, the project “is what it is” (whether we like it or not).  When we cannot live with the proposed dates, there are only a few options available: 

              Apply more resources to the critical path,

              Change the project objectives (goals, benefits, etc),

              Reduce project scope (modules, interfaces, processes, etc)

All of the above can eliminate associated tasks or reduce task durations. However, permanently cutting objectives or scope for the sake of meeting an arbitrary schedule is not very smart. When it comes to resources, there is a law of diminishing returns. For example, assigning nine people to screw in a light bulb is not going to get it done any faster. Above all, when moving up schedule dates, avoid “voodoo” scheduling. This is when we manipulate the dates forward, to get the schedule to say what we want it to say (with no valid cause and effect justification for doing so).

Define the Project Path to Get There

A project schedule should convey specific project deliverables, supporting tasks, task durations, dates, responsibilities (resources) and recognize the relationship between tasks (dependencies). This does not imply any plan is perfect since scheduling is just as much an art as it is science.

However, when the right people are involved and proper detail, durations and dependencies built into the “work breakdown structure”, many of the assumptions and imperfections at lower levels of detail tend to cancel each other out. This means at the highest level of the schedule, planned start, and planned completion dates for key project deliverables / milestones should be reasonably accurate (including the go-live date).

This level of the plan(sometimes referred to as the “Schedule of Deliverables”) serves as an important road map with regard to where the project is going and when we want to get there. The dates at the individual task level are less relevant (except on the critical path), but they do serve as input to planning weekly activities as the project unfolds. They also are a day-to-day gauge to tell us if the project is on track per the original plan.

It is Sometimes Hard to Argue With the Facts

Finally, a project schedule (with the details to back it up) is a project manager’s best defense against those that insist on unreasonably aggressive timelines. In other words, anyone can throw dates around, but it is hard to argue with the work required and the sequence in which it must be accomplished, particularly if the goal is to be successful. On the other hand, a project plan and schedule with no detail is wide-open for criticism, second guessing and manipulation.

In previous blog entries, we discussed the importance of proper definition of project scope, assigning the right internal resources to the project team and getting all key client stakeholders heavily involved in the planning process. In my next blog, we build on this foundation and discuss how to construct a project schedule while addressing the common and not so obvious pitfalls. Finally, we close out this project planning series with a discussion on methods to estimate and budget for software consulting cost.

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

Editor’s commentary - Steve Phillips runs a great blog which is linked here:

http://it.toolbox.com/blogs/street-smart-erp

Be sure to visit his site and support his work!

Related Posts:

• Some Reasons SAP Projects are Over Budget and Over Time
• SAP Implementation Projects: Still Crazy After All These Years
• Reduce SAP Project Stress Part 3
• ERP Project Plan: Getting Real (Part 2)
• ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?

IT Project Hostile E-Mails to Wide Distribution Lists

Previously I’ve offered insight and suggestions on the topic of reducing SAP project stress in a 2 part series:

But recently on LinkedIn, in the Project Management Group someone raised an interesting question that I have had to deal with on a few projects.  They asked:

“How do you respond to a senior project member who wrongly accuses you and have your bosses and team copied on email?”

Because I have been doing SAP projects since 1994, in highly charged corporate environments (including corporate politics) I have experienced this situation a few times.

Someone will pop off about something and they do not know what they are talking about.  They may be completely clueless or they may be wrong, but the message is inappropriate and it has now gone out to a number of individuals.  There are effective ways to respond to this situation.

1. DO NOT RESPOND IMMEDIATELY unless there is some absolute imperative that you must. Your best bet is to appear professional, let things cool, and get your own emotions in check so that you do not escalate this into a full blown war.

My personal experience has been that about 50% of the time this has happened to me, as long as I do not react in a rash manner, they are quickly resolved. By not responding immediately I have experienced the following corrections where I came out looking like a hero:

- On a few occasions some senior leaders on the client side (or the consulting side depending on who initiated the flame) have responded back to the e-mail initiator and corrected them. 

- On a few occasions the individual was known as a hot tempered instigator.  As a result of not getting the immediate response they wanted I had 2 people became irrational, try to escalate the situation, and exposed that they were completely nuts.  One of those two was fired shortly afterward.

2. WRITE the response e-mail immediately but DO NOT SEND IT! It gives you a chance to vent some of your frustrations and clarify some of your thoughts. Save the message, come back to it later (generally a day later), review it and re-write it in a much more dispassionate manner.

3. DEPERSONALIZE your response if you do send it. Avoid the use of any personal pronouns. Deal with the issue and not the person. If they continue to attack you and you continue to point back to the issue they look like a completely unprofessional idiot in front of everyone else.

4. ALWAYS be professional and try to empathize with the initiator even if you know they are vindictive or have some ulterior motive. In other words, you might say something like “I understand why this might be thought, but please consider…” Their response will speak volumes.

5. Your response to everyone should make it clear that you would like to schedule a meeting to review the issue face to face. The message should make it clear that there is no reason to take up everyone’s time and this can be resolved with the key stakeholders.

Your professional response speaks volumes. As a project manager you will gain everyone’s respect. Everyone who knows about it will realize that in dealing with you that even if they screw up or get a little over the line that you will deal with them in a professional manner as well. It helps to reduce project stress and defuse potentially ugly situations.

Some Past SAP Project Experiences with Improper E-Mails with Wide Distributions

While at Hitachi Consulting I was a mentor for one consultant who experienced a similar situation and gave all of the counsel listed here.  They followed these suggestions and let the situation die down.  The next day the client individual who had responded so improperly openly apologized and things were much smoother from then on.

I have seen this “provocative” type behavior from several consultants who were complete frauds!  They work to hide their own incompetence by sabotaging your ability to manage a project, or by creating unnecessary conflicts with other co-workers.  Because the SAP world is full of frauds it is one of the ways they create diversions from looking hard at their work product and experience.

I have seen this type of provocative behavior from client employees who were worried about layoffs and saw the attacks as a way to look important.  I have seen this type of behavior from client employees who lied about their own talents / skills / experience to get onto the SAP project.  Once they found out they were in over their heads they created havoc to distract from their lack of contribution.

The reasons really do not matter as much as how you, as a project leader or a project participant deal with the situation.  Handling stressful or highly charged situations is not easy but in this line of work you will have to deal with it.

Related Posts:

• SAP Failures: Is Lack of Sr. Mgt. Commitment the REAL Issue?
• Some Reasons SAP Projects are Over Budget and Over Time
• ERP Project Plan: Getting Real Part 3
• ERP, SAP, or IT Project Management and Prototyping for Success
• ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?