Now, the failure rates are as high as 70 % according to McKinsey. For those ready for a heart attack, Oxford based research by Chris Sauer finds failure rates as high as 93% when the measure is ‘On Time, On Budget, On Scope (OTOBOS) and intended results are delivered.

Why do we keep doing projects that might fail?

It is rational to do so in most organizations: it gives people a job, it allows sponsors to be seen to be active and it is often politically very dangerous to suggest that a project might really fail. Who wants to be the messenger and shot?

Warning signs on a risk register are one thing, but to call out ‘this project has a 15% chance of success’ is another. On the other hand, who wants to hang around a failure? Particularly if they are avoidable – which they are when you know what to look for.
We also tend to hope that this time will be different and that our good intent and better planning this time will be sufficient to over come the cynicism, agendas, and background cultural issues that get in the way.

Change is the Only Constant

At the human level, this is costly – frustration, doubt and cynicism at change, leadership intent and whether anything good will come of a project this time around. From the business perspective – it’s also costly. By one estimate, a minimum of USD 330 billion dollars was wasted on projects in 2008. That’s an astonishing amount.

Failure rates of this level have been around for decades. So have successful projects. It’s not all bad news.

The reality is we all change all the time. Most of us have picked up an iPad (new this year), use a mobile phone (my first one was a brick in ‘98) or surf the internet to book a flight or check out a restaurant (me last night – and I couldn’t have done that a decade ago). The thing is, all these changes have helped me in some way or other – connect with those I want to, excited me or given me choices I didn’t have before.

At the personal level, a few years ago I was dissatisfied with my life and I’ve consciously taken on a personal journey of transformation – and in truth, while there were periods that were black, I’m far closer now to who I wish to be than I was. I’m counting the process as a success.

With longer term transformations, the process is as much part of the ‘result’ as the official goal be it an individual or an organization.

If as individuals, we can change (a new phone) or transform (choose to become fundamentally different), as a human collective organizations can and do too.

As a long time project and change manager of assorted business projects (SAP, CRM, outsourcing, shared services, vision & mission, cost-cutting, re-engineering…) I got curious, what were the common factors of successful projects? What undermined success?

The Facts

For data oriented logical types:

• Up to 93% of projects fail to deliver their intended results
• This is the equivalent wasting of up to 70% of the investment
• Those that invested in adequate organizational change management delivered 46% higher returns
• 80% of the issues that undermine results from projects are identifiably and addressable up-front

(For more on the rational side of setting up for success, see Chapters 2 & 3 of The Success Healthcheck for IT Projects. Yes, it’s about business projects based on IT as IT is a pervasive source of change in our lives – and 99.9% of these require organizational change management!)

To put this in human scale terms, getting a successful project is like dating and staying married:
Meet a lot of people with only a small minority working out (assuming one is dating with the anticipation of a long term relationship).

• Numerous dinners, speed dating events, emotional roller coasters etc that seem to amount to little until Ms/Mr Right is found. Divorce is even more expensive option when a relationship finally comes to an end.
• Continued investment of emotional energy is needed to keep the relationship alive.
• Our friends and family can often tell us if it’s a fit very early on if we care to listen and act.

There are always the courageous ones who will shoot for the ‘A’ even at the risk of admitting to possible failure.

They asked me, “So if 80% of the risks to results from my project can be identified early on, what should I as a practitioner look for to do a Success Healthcheck?”

The Checklist

As an organizational change practitioner, there are 8 elements you should focus on. They are:

1. Is the Intent Clear? If we don’t know what we are aiming for…    Like in the search for Mrs/Mr Right specificity is good. There are eight areas that require definition – including the experience of the project;
2. Is the Business Case Robust? If the funds are there, great. If they are not sufficient…   Then political will and executive sponsorship under-estimate what is required for success or the project is not high enough on the bigger priority list.
3. Is the Results Delivery Process Reliable? If we don’t reliably deliver results from projects, why is this time different (ok, yes, you are involved, but aside from this, what else is needed?)    Where things have been simplified (KISS) so far that the KISS no longer reflects reality. My personal favorite over-simplification: “let’s assume that all the people are motivated by the same things and respond in the same way”
4. Is the Motivation Energised? If the change is working with a groups motivation … or not    If a change is not in the personal interests of individuals, why would they be enthusiastic? Resistance is someone refusing to do what they are told – often as it is not in their interests. That’s a sensible lack of motivation! It’s rational at the individual level and dysfunctional for the organization.
5. Does the Project Align to Current Strategic Position? The bigger the gap between current reality and the project’s strategic vision, the bigger the job (and the more the business case needs to be sound). And the more risky it is, the more things are likely to change and the more complex. Exciting, stimulating – and less likely to succeed.
6. Does the Operational Context Support the Project’s Intent? Operational rules in many parts of an organization are like the challenges of a golf course: roughs, water traps etc. You can play a game, but it is harder and requires more skill. Where you are going to have to do more work is in the organizational practices that – while often well meaning for a stable environment – are not supportive of a dynamic environment.
7. Does the Flow Favor Project Intent? Does the flow of organizational memory and history favor your project? Are there recent good experiences that you can build upon? On the down side, is there left-over cynicism that your project needs to deal with from past failures?
8. Are the Balancing Dynamics Aiding Project Intent? This is the home of complexity and dynamics and systems and ‘absorbable stages’. Be attentive to areas where people or events can convert state from being neutral to enthusiastic or to being against. Finally, also look for areas in the organization where burnout or turnover will affect performance and thus your projects.

Now, having identified a few ‘health risks’ you can make an active choice… to return to our dating/marriage metaphor…

• To get the support and advice you need to address risks to the project/relationship
• Decide there are too many risks and that this project is a bad date or a divorce waiting to happen and quit now by closing out the project
• Wait and see.

Or you could get a copy of the Success Healthcheck for a colleague and give it to them with a note to say ‘let’s have a healthy project’.

___________
Check out the Cool Friends page on this blog for Joanne’s profile.

Stop-gap / stäp.gap/
noun. a temporary way of dealing with a problem instead of satisfying the real need.

More often than not, project managers find themselves in the situation that their organization ‘is going wall-to-wall SAP,’ and they are then left to implement the chosen application without a clear understanding of the expected benefits and the organizational changes that will be required.

The Formula

Here is what happens next as the project managers work their way out: NT + OO = EOO (New Technology + Old Organization = Expensive Old Organization)

Any SAP implementation should be embedded in a fundamental business initiative to transform the business. You are not implementing SAP for the sake of SAP or because of its features like multi- currency, the ability to define sales organizations, reporting, etc.  Good old Michael Hammer knew this as no other.

You are doing so because you want to gain benefits that are essential for the survival of the organization. Technology is an enabler on that path. But if you fail to paint a clear picture of the destination it is a stopgap. The technology is rolled out, there is a successful go-live; pizza, party and then everybody goes home.

It ain’t over ’till it’s over

Benefits formulate the goal of a program in terms of the success of your organization. These are the beacons, guiding the program to develop in the right direction. Benefits are the basis of the business case to justify the cost of the SAP implementation. They make outcomes concrete, measurable and above all: actionable.

The point is that the project ain’t over till the benefits are realized! Implementing SAP is just a step on the path towards realizing the benefits.

Destination Postcard

In an ideal world, the decision to implement SAP fits in an overall business strategic program derived from the company’s business vision. In many cases, however, the decision to implement SAP is based upon a combination of less compelling operational features, listed below:

• Legacy systems need to be replaced;
• More integration of information is required;
• Better integration of the IT landscape is needed;
• The current version of SAP will no longer be supported;
• Common ways of working need to be implemented;
• The supplier of current systems doesn’t provide proper support, or worse, is no longer financially stable;
• Data integrity;
• Improved continuity and enhanced disaster-recovery planning

Yawn

Yawn-provoking indeed. But here’s the thing: unless you are able to convert the above mentioned reasons into benefits that serve the organizations strategy, you will not be able to win the hearts of your stakeholders. This means: a compelling vision AND actionable benefits that will prevent to see the SAP implementation as an end in itself.

In short: If you are unable to come up with quantifiable benefits, you should consider not moving forward with the SAP implementation. If you do, you risk getting lost in the fog without a beacon to steer for.

Outcomes are the destination postcard (you can see the picture and you want to go there), and benefits are the black-and-white writing on the back of the postcard (the exact coordinates). SAP is a fuel station on the way to the destination. If SAP is figuring either on the front or the back of your postcard you’d better cancel your travel plans. It’s not about stopgaping symptoms with SAP, it’s about treating the real causes with benefits realization!

But hang on – here is the good news: if you to stop being right and start to investigate the choice architecture of your message, there is a great chance for you to improve your communication.

In a recent book called Nudge: Improving Decisions About Health, Wealth, and Happiness, economist Richard Thaler and legal scholar Cass Sunstein explore the psychology of our every day decision making and argue that we make poor decisions due to the architecture of how choices are presented to us.

This includes food decisions, investment decisions and all kinds of well-informed decisions (that’s the frightening part!).

Choice Architecture and Door Handles

Below is a excerpt from chapter 5 explaining the core ingredient of their book “Choice Architecture”

“Early in Thaler’s career he was teaching a class on managerial decision making to business school students. Students would sometimes leave class early to go for job interviews (or a golf game) and would try to sneak out of the room as surreptitiously as possible. Unfortunately for them, the only way out of the room was though the double door in front in full view of the entire class (though not directly in Thaler’s line of sight). The doors were equipped large handsome wood handles, vertically mounted with cylindrical pull about two feet in length. When the students came to these doors, they were faced with two competing instincts.
One instinct says that to leave a room you have to push the door. The other instinct says, when faced with large wooden handles that are obviously designed to be grabbed, you pull. It turns out that the latter instinct trumps the former, and every student leaving the room began by pulling on the handle. Alas, the door opened outward.”

Further in that chapter the authors continue:

“At one point in the semester, Thaler pointed this out to the class as one embarrassed student was pulling the door handle while trying to escape the classroom. Thereafter, as a student got up to leave, the rest of the class would eagerly wait to see whether the student would push or pull. Amazingly, most still pulled!“

With this example Thaler and Sunstein point out that the doors display bad choice architecture because they violate a simple psychological principle called Stimulus Response Compatibility (SRC). SRC means that you want the signal you receive (the stimulus) to be consistent with the desired action. Flat plates say “push me” and big handles say “pull me”. So don’t expect people to push big handles! This is a failure of architecture to accommodate to the basic principles of human psychology.

From Handles to Heamophilia

Saying “red” when you see a red light go on is an example of high compatibility. Having to say “green” when a red light goes on is an example of low compatibility. This has far reaching consequences, even in the medical world. Below is an example that I have experienced multiple times.

Patients with haemophilia A cannot produce a protein known as factor VIII (FVIII) and must get it from somewhere else. KOGENATE® Bayer is a FVIII product that a patient can use instead of natural FVIII. KOGENATE® Bayer is a great product which improves the lives of many haemophilia patients. But it’s also an expensive product, burdening social security with more than 100.000,- Euro per patient per year.

Needless to say: we better don’t waste a drip of this precious and expensive product! Yet, this is precisely where the engineers of Bayer have failed to cater for some SRC into the design of their injection bottles. Have a closer look at the instructions below: the fluid (drawn in black) is in one part and needs to be mixed with the powder in the other part. Movements A to J must be performed a few minutes prior to injection.

To cut a long story short: figure C and D is where it mostly goes wrong – even with well trained nurses, parents and patients. The normal way of using ‘fluid-and-powder’ products is to screw on and inject. That is what the design communicates: “screw and inject”. Yet – as you can see in C and D, there need to be two separate pushes (followed by a ‘click’) prior to adding the fluid. The latter is so counter intuitive that I have literally seen thousands Euros being flushed onto the ground before my eyes.

Even trained parents and nurses who are familiar with this product need their full attention or they miss the crucial C and D.

OK for door handles. Not OK for social security.

From Heamophilia to SAP

To me the link with communication in big organizational change projects is obvious: communications are vital and precious for the health of an organization. And expensive too. Nevertheless communication sometimes turns out in the opposite direction. This is mostly due to failed choice architecture and untested stimuls response compatibility. When respondents fill out the wrong details, use the wrong settings or insert their card upside-down, it is easy to call them ‘stupid users’ or to tell them RTFM (this stands for “Read The F** Manual”).

I still remember the day that the logistics responsible typed the article number in the weight field when we were implementing SAP in a large chemical plant. The automatic interface that we were so proud of automatically blocked all the transports available of our 51 neighbouring plants. We had to write a program to unlock all those transports. And guess what we said: ‘stupid user’. However, this did not prevent other users from committing that same mistake.

From SAP to Traffic

Next time you build a survey or a communication, a note or a manual requiring your receivers to fill out something, to use a system or to take an action of any kind, consider how SRC-proof your communication is by testing its usability at full length PRIOR to sending it out.

As a final thought I could easily link this idea to the communication articles I have written before. Whenever I talk about communication I tend to use the metaphor of traffic and this one fits in pretty well; If communication would be a mission to bring a vehicle (i.e. your message) from point A to point B, then you want this vehicle to be equipped with an SRC button. SRC will avoid your vehicle from going in the opposite direction when you accelerate.

Every year, thousands of runners are injured due to leg and foot pain. In response, athletic-shoe companies have invested fortunes into high-tech cushioning, arch support, and shock absorbers. But despite these efforts, as many as six out of 10 runners get injured every year.

A great fiction story…or not?

In his latest book Born to Run, Christopher McDougall describes an epic adventure that began with one simple question: ‘Why does my foot hurt?‘ In search of an answer, Christopher McDougall sets off to find a tribe of the world’s greatest distance runners and learn their secrets, and in the process shows us that everything we thought we knew about running is wrong.

Born to Run is a compelling story, a page turner full of incredible adventures and a cast of characters worthy of Dickens. So as a reader you may think you are reading a great fiction story. Until … you go surfing on the web and you find out that every fact and character of the book is real.

BFT

Barefoot Ted (BFT), for example is one of those amazing characters that have helped McDougall to the flip the question: If shoes are not the solution, could they possibly be the problem?

Barefoot Ted is a phenomenon. On his website he describes himself as “committed to re-discovering our primordial human potential”. And boy, is he committed! For more than a decade, BFT is being the change he wants to see in the world.

He does not ‘fight’ the old paradigm. Rather he:
- is evidence of the new paradigm
- embraces every positive evidence he can find;
- builds a community of fans and has devoted his whole existence to barefoot running;

BFT as an Organizational Change Practitioner

And there is more. BFT has interesting things to share about paradigm shifts and how they occur. Insights that are highly relevant to us a organizational change practitioners implementing SAP.

As you can imagine barefoot running is a hot topic in runner’s circles and far beyond because shoe companies and just about half of the medical world’s advice is at stake: barefoot running rocks the status quo.

Slowly but surely, there are shoe companies that have adapted to the virtues of barefoot running: the Vibram FiveFingers is a good example. Barefoot running goes mainstream.

Trojan Horse

Pondering over this evolution here’s what BFT says about barefoot running going mainstream:

“I still think that barefoot is best, but barefoot is free…, and I always knew that the only way barefooting was going to become a true, mainstream hit was that there was going to have to be a product…something people could buy. And the VFF is that product…, or from my perspective, Trojan Horse.

The Vibram Fivefinger is a foot glove. No support, no real cushioning. Yet, it is a thing I can buy. A solution that can be purchased. Consumer cultures feel comfortable with it. But what is its real message? It seems the real message of the VFF is that your foot is just fine AS IT IS! That regaining strength and range of motion in your foot is a worthy goal. That you are not broken by default.”

SAP is the FiveFingers of Business Process Reengineering

Implementing SAP is also like a Trojan Horse. People think it’s just a software rollout and that all other things will stay the same. … NOT! People wake up in a new world where the system allows or disallows certain things. People have access to different information. As a consequence, people will start working differently – breaking holes into silo’s and getting grips on input and output.

As a matter of fact, SAP is the FiveFingers of Business Process Reengineering (BPR). Like barefoot running, process reengineering is common sense and getting back to basics. BPR suffers the same flaw as barefoot running: it’s free.

SAP is the enabler of BPR and nowadays we see lots of organizations implementing SAP ‘because everybody does it’. Like FiveFingers it is a solution that can be purchased. And the real message is the same: your company is not broken by default. SAP is not ‘fixing’ a broken company – just like your foot is just fine the way it is. But SAP makes you run differently (i.e. on on your bare business processes) and therefore BPR becomes way more obvious.

I even like the analogy in the abbreviations: What FiveFingers is to BFR (BareFoot Running), SAP is to BPR (Business Process Reengineering)
BPR = BFR!

Thanks BFT (BareFoot Ted) – for this great insight!

The video is in Dutch (with my own Flemish accent ) and you will find the English transcript below. So there you go: my thoughts on film and a free language course in one article!

Less Training, More Learning!

I have an SAP background and some experience in large scale SAP projects. SAP is software that typically impacts the complete organization and a lot of users at the same time, and there is a great need for training. Last year the plant manager of a big plant came to see me. The fact that the return for the people on the SAP training sessions was disappointingly low caused some frustration.
What happened here? The organization thought that sending people to the SAP training was enough in order for them to be prepared for the day-to-day work with SAP. Together with that plant manager I discovered that people remember maximum 10% of what was taught in the training sessions.

In my opinion that’s normal because 90% of the things you need to know in order to perform your work cannot be taught in the classroom; you learn it when you need to solve a problem, when you receive the right communication and whenever you are obliged to take some actions in practice. Training managers need to be aware of that. 90% of what is needed for my job is situated in the field, so as a training manager I need to be in the field.

Bicycle

Let’s suppose that we agree on me teaching you to ride your bicycle. I will prepare thoroughly and I will tell you all about the mechanical aspects of a bicycle. Next, I will tell you all about the laws of gravity. Then I will tell you about the organ of balance because it is the critical success factor for riding a bicycle without falling over. Finally, I will even make the training practical by showing you a real bicycle and I will even ride some laps so you can see what cycling is.

At the end of the day I expect you to be capable of riding a bicycle because you know all about cycling from A to Z.

This may sound absurd but is the current state of training and development: we teach people how to ride a bicycle by showing them PowerPoint slides. When they come out of the classroom we are surprised that “the thing isn’t working”.

Cause?

What went wrong with the bicycle training? I made the mistake of looking at the training as a purpose in itself:

• I prepared the best materials;
• I showed the most beautiful bicycle;
• I may even have invited Lance Armstrong as a guest speaker.

While doing so I focus too much on the satisfaction of the participants. And what happens when the participants are happy? All of a sudden the training was brilliant in achieving its goals! All of a sudden whether or not you are able to ride a bicycle has become irrelevant. That’s immensely frustrating.

Solution?

How are we going to solve this bicycle problem? I will alter my starting point towards what is needed for you in order to cycle. As a consequence:

• I will ask you to bring your own bicycle;
• Instead of preparing manuals, I will prepare a safe trail for you to drive around;
• Instead of standing in front the whole day animating and telling you how to ride a bicycle, I will be standing behind you to catch you if you fall.

Hunger

Whenever I conduct a training I ask the participants to state their personal objectives in the beginning of the day: ‘what is it exactly that you want to be better at when the day is over?’. At the end of the day we turn back to these objectives on the whiteboard and we evaluate whether the participants reached their goals.

The message here is clear: as a participant it is your responsibility to use me as a trainer in order to reach your objectives. That’s the best way of going through the day. It’s important to sharpen the training hunger so the participants are fully aware of what they want to get out of that day.

Interaction

I am aware that participants only remember about 10% of what I tell them or show them and therefore I trigger their own experiences as much as I possibly can.

My task is to ask the right questions and then to frame the answers that I receive. So I will not be standing in front too much of the time. Rather, I will be standing behind the participants to motivate them to come up with those answers.

Island

I often come across project managers complaining that people are stupid. When I ask them why they think so, they show me their slides and then they say: ‘my slides are very clear, don’t you think? I couldn’t possibly be clearer that that?’

But it’s not about the slides! At best those slides contain 10% of what a participant needs in order to perform his job in practice. The last 90% is situated in the field: in the middle of conflicts and problems. That’s where we need to be heading. That is exactly the reason why we are standing next to this lifebuoy: for the project leaders and training managers who desperately need to leave their PowerPoint Island.

_________________
Related articles:

- Knowledge = a Social Fabric – September 13th, 2009
- Return-on-Training? Wrong Question! – January 18th, 2009
- Do I need to paint a picture? SAP and Learning! – December 20th, 2008
- The End of Teaching – November 2nd, 2008
- Teaching versus Learning – May 13th, 2008
- How do you learn? – September 23rd, 2007
- It’s About Involvement, Stupid! – June 1st, 2007
- Learning and Resistance – May 22nd, 2007

We have been preparing the users of his plant by means of extensive classroom trainings, both on process knowledge and systems skills. From his gut feeling he told me that his people demonstrated at best 10 to 15 percent return (i.e.: what they effectively remember and use in their jobs).

Training is the Smallest Part of Learning

I will not argue about the percentages. The point is that I obviously did not create the right expectations: he should be looking for the return-on-learning instead of the return-on-training! On this same blog I already announced the end of teaching and I also proclaimed that teaching is placebo. I even painted a picture about it in order to demonstrate what this means for SAP implementations specifically.

In retrospect the 10 to 15 percent reported by the plant manager is fairly high compared to what I always have been saying: 99% of what ‘Learning’ really is occurs outside of the classroom. The bottom-line is that training alone is not enough in order to make an organizational change happen. Increasing the quality of your training sessions will not leverage the return-on-training to the same extent. At the very best it is a starting point. From there on you will need to coach your way to the future state. The drawing below is taken from John Seely Brown (again!) and clearly depicts how learning really occurs

Now back to the return-on-training question. What could be the best way to increase that return? The answer is simple: this return can only increase if workplace learning has already occurred BEFORE the training session (in action, action through participation, participation with the world, participation with the problem and participation with other people, i.e., practices). Involvement, participation and ownership are key.

Time-to-Task

The concept of Time-to-task is another way to look at it. Normally we use that term to describe that the training should occur as closely as possible to the task at hand. The only way return-on-training can increase is when time-to-task is negative. In plain English this means: people will get more out of a classroom training when they have been frustrated by real-life problems form the task at hand; they will posses an enormous learning pull and they will ask for and absorb every detail that is needed for the job at hand.

Here is a quote from David Maister to support that view:

A good test for the timing of training would be as follows. If the training was entirely optional and elective, and only available in a remote village accessible only by a mule, but people still came to the training because they were saying to themselves, “I have got to learn this – it’s going to be critical for my future,” then, and ONLY then, you will know you have timed your training well. Anything less than that, and you are doing the training too soon.

Rethinking Knowledge Management

Participation, involvement and enculturation (i.e.: “belonging to”) lies at the heart of learning. It also lies at the heart of knowing. Knowing has as much to do with picking up the genres of that particular sub-profession as it does with its conceptual framework. For example, how do you recognize whether a problem is an important problem, or a solution an elegant solution, or even what constitutes a solution in the first place?

Jerome Bruner made a brilliant observation some time ago when he said that we can teach people about a subject matter, for example, physics. That is, we can teach them the concepts, conceptual frameworks and facts of physics – the explicit knowledge of physics. But that does not make the student a physicist. To be a physicist he must also learn the practices of this profession. As he continues:
“We teach a subject not to produce little living libraries on that subject, but rather to get a student to think mathematically for himself, to consider matters as an historian does, to take part in the process of knowledge-getting.”

Here we are. Now what?

All the evidence tells us that learning is a social thing. It exists in action, participation with the world, participation with the problem and participation with other people, i.e., practices. A lot of the knowledge comes into being through the practices of the people and the environment you’re working in. The return-on-learning question reveals the challenge we face today for rethinking knowledge management:

1. Shift our mindset from “pushing knowledge to people” (authority based and explicit) to “supporting people to participate in their productive inquiry” (situational based and on-the-fly)
2. Shift from tools to increase the individual knowledge stock to tools which support relationships and interaction.
3. Shift rigid structures from managing an academy (where knowledge gathers dust) to facilitating an ecology of different communities-of-practice (where knowledge lives and evolves).
4. Do everything we possibly can in order to introduce Web 2.0 thinking in the boardroom. Think: collaboration and moments of truth instead of teaching!

Talking about organizational change management… there is work to do!

Regular readers of this blog know that you can’t blame the consultants for missing out the largest part of the iceberg… after all, they are only ducks – unable to spot what could possibily be going on below the surface.

One would say: for the sake of the quality of the system it should be attendance to the testing session; and for the sake of learning the key user should attend the training session. I say: NO WAY – testing is the main event for both quality assurance AND learning!

As I mentioned earlier, teaching is placebo in order for learning to occur. A Classroom training is at best a moment of truth in which the participants flip over the decision switch that says: “as of now I will be capable”.  Learning occurs AS OF that pivotal moment – not ‘during’ and not ‘before’.

On the other hand: in testing you want to find something out or get something done. As John Seely Brown notes: it is about doing stuff; and then getting stuck while you’re trying to do something generates the passion to find out more about it. In testing you don’t get to build up an inventory of knowledge and skills. Learning happens on the fly, but you have to be willing to be confused, you have to be willing to make errors.

And there is more news: the digital divide between generations that we once thought of as being isolated to a group of nutcase computer engineers, introvert and pale skinned; has now gotten mainstream. Young employees, average IQ’ed moms and pops and even early adopters of the grey-haired generation are now subscribing to this new world of learning.

The Web 2.0 has a side effect on learning and it’s a big one: throw away those expensive manuals and get out of that classroom! John Seely Brown refers to it as Learning 2.0 – day by day classrooms are becoming obsolete and social spaces – most of them virtual spaces – are finally being recognized as learning environments. In the below drawing I have taken a slide of John Seely Brown and fitted in where I think ‘Classroom Training’ and ‘Acceptance Testing’ belong.

Each day it is getting clearer that learning is social and that knowledge is a social thing. It exists in action, participation with the world, participation with the problem and participation with other people, i.e., practices. A lot of the knowing comes into being through the practices of the people and the environment you’re working in. When I say “the end of teaching”, I mean: the end of a paradigm where we believe in knowledge as an inventory of stock – eventually gathering dust.

But now there is a second reason for HR people to despise of my blunt opions on HR. In the October 2008 issue of HR Expert I now examine what it takes for HR to become a business partner. In short, the article covers a concrete three-step approach for HR to become a reliable business partner. The biggest takeaway for HR managers is an understanding about the importance of HR processes and how an ERP implementation should be used to support an HR strategy. Next to that we also outline some opportunities for managing expectations of HR.

Both articles are based on my observations as an organizational change manager on large scale ERP implementations. During those implementations one is involved in the trenches in a weird way; offering people new roles and responsibilities; focusing on processes as a new way of working and … sharing their frustration as HR is never involved and most of the times completely ignoring the changes at hand.

So I have to find better ways of getting our point across about the impact of SAP. The best way of doing that is to have someone who’s ‘been there and done that‘ to share experiences and stories. And that works. This is because people (that includes you and me) absorb stories far better than concepts, facts and figures. It’s our our human nature to be more compelled by bush-fire war stories than by accurate statistics and plain facts.

For that same reason metaphors work really well; a metaphor is a lively comparison that allows you to get your point across. Good metaphors stimulate the ‘story’ part of the brain in different steps: first by highlighting a certain aspect that is abstract; second: by comparing it with a familiar element; third: by highlighting straightforward characteristics for this familiar element, and finally: retrofitting these characteristics to the abstract element. 

Here are some metaphors that have helped me to get my point across for audiences that are new to SAP. I have collected them from al kinds of clever people that I have worked with so far.

1. The Euro: one single currency
- The abstract element: getting a grip of uniform master data and what this will be like in the future state
- The familiar element: Uniform master data are like a single currency
- The straightforward thinking loop: when we changed to Euros we were able to use one single currency all over Europe. As a consequence all goods and services became comparable. The first year we kept calculating in our old currency but after a while we just got used to Euros and stopped to calculate back.
- The retrofit: Uniform master data – a single currency – will cause us tag one single article or equipment with the same identifier in all countries and all sites. As a consequence comparisons become possible and things become more transparent. In the beginning people will continue thinking in the old terms but as soon as they feel comfortable with the new ones they will let the old ones go.

2. The sports car and the racetrack
- The abstract element: understanding that processes are important in order for the system to run properly and that every user should understand them prior to using the system. 
- The familiar element: a sports car
- The straightforward thinking loop: SAP is like a beautiful and powerful sportscar with a powerful engine. However, a sports car can only race if there is a good race track and if the driver is skilled to drive it.
- The retrofit: SAP is powerful system – like a sports car, but it requires business processes - a racetrack - in order to work properly. On top of that you will need skilled users – drivers - at the steering wheel.

3. Concrete
- The abstract element: The importance of blueprinting and design before you build. 
- The familiar element: the concrete fundaments of a house
- The straightforward thinking loop: When you make the concrete fundaments of a house, you need a clear plan, the right equipment and the right construction people. Once the concrete is put in the ground it will easily fit the shape that you have dug. However, if you try to change a certain part of that concrete shape, it is very hard to do.
- The retrofit: SAP needs to be carefully planned and designed by the right people with the right equipments. If the system is not designed with the business processes in mind than the fundaments will turn out to be the wrong ones for the house that you are building – and corrections will be as difficult as changing the shape of concrete fundaments.

You will have noted that there are plenty of other metaphors that you can use and especially during SAP implementations there is a great need for making the abstract future tangible and simple. We stimulate people’s involvement and buy-in through a simple story, a straightforward comparison or a down-to-earth message. These are three things that look easy when we see or hear it from others but when it’s our turn…a writer’s block is the first thing on our path.

Do you know other good metaphors or catchphrases that relate to implementing SAP? Please share them in a comment to this article!