Transformational software (ERP, CRM, PLM, etc.) implementations rarely deliver the promised benefits. Companies spend tens of millions on the implementations, but the ROI is usually late - or worse yet, never materializes at all. The software itself is rarely the problem. Instead, benefits arrive slowly because of failures in process redesign, change management, and training.

Three essential dimensions contribute to user acceptance: understanding, motivation, and skill. Check out this short self-assessment to see how your company or project stacks up in these areas.

Robert Cenek at The Cenek Report points out some enduring wisdom from OD guru Roger Harris.

An organization development intervention should occur at a level no deeper than that required to produce enduring solutions to the problems at hand; and

The intervention should be at a level no deeper than that at which the energy and resources of the client can be committed to problem solving and to change.

The quotes are from an article, Choosing the Depth of Organizational Intervention, written by Harris in 1970, but no less true 38 years later.

A colleague commented to me recently that one of my clients needed a “Dinosaur version and a 21st Century version” of a particular ERP softare training course. Indeed, the audience for the course was as diverse as I’ve seen in almost every respect: generationally, culturally, politically, and in their level of computer literacy and years of experience with the organization.

This was an instructor led course and the content was primarily conceptual. The client had tried for a balance between traditional lecture and interactive exercises and games with the intent of trying to address a variety of learning styles during the one day course.

So, combine a widely diverse audience with a course presenting content in a variety of ways and, what is the feedback from the particpants? Overwhelmingly, about half of the particpants wanted more lecture and far fewer exercises and games and the other half wanted less lecture and more exercises and games. Interestingly, (or maybe not) the divide between these two groups was not so much related to individual learning styles as is was to age and years of experience with the organization. So, at least for this organization, the generation gap is the biggest one of all.

Thus the comment about the dinosuars and the 21st century. But here’s the problem, a big part of the reason for making these people sit through a full day course was the get them to interact, share experiences, and learn from each other. Having two versions of the course would not help to achieve that goal. So what’s the solution? How can we avoid a classroom experience where half the class is bored and disengaged from the lectures, and the other half is annoyed at the forced participation in interactive exercises and games, which they see as a waste of time? How do we get to a level of interaction that is reasonably comfortable for everyone? I don’t have the answer yet. But, I’m working on it.

It’s doesn’t surprise me any more when “project success” checklists fail to include change management, training, and documentation. So, when they make even the bottom of the list, it feels like cause for celebration. Michael Krigsman at the Project Failure blog puts forth 6 tips to reduce IT project failures. Last, but not least, among them:

6. Change management, documentation, and training are important. To be successful, users must understand the project’s goals, status, and impact on their jobs. Many projects pay too little attention to training and documentation, especially when the project starts to run over-budget. This oversight reduces productivity and can negatively impact the project ROI. In extreme cases, users simply don’t use the new software, bringing the effective ROI to zero.

So, the last few words in the last paragraph tell us about something that can “bring the effective ROI to zero.” If that’s the case, why is it so often at the bottom of the list? Or, as Michael states, ignored once the project starts to run over-budget?

One hypothesis I have: Project success for the software team isn’t measured on user adoption - or ROI of any kind. Instead, they’re measured on functioning screens and transactions. It’s up to the business to actually use the stuff.

Reminds me of a health club membership; just spending a lot of money on it doesn’t make you lose weight — you have to actually use it.

In any given field of study, there is Perfection and Reality.

Let’s say you’re talking with a recent PhD graduate in Sub-Molecular Omni-Buzz (2.0), and you have a simple question.

You: “How do I get my sub-molecules to buzz, omni-wise, 2.0 times?”

PhD: “Well, technically, you’re supposed to read the manual, close all other applications, don your safety glasses, and most important, do not attempt to rock the machine.”

You: “Hmm, that sounds pretty complicated.”

PhD: “Actually, you can just unplug the Omni-Moleculator, wait 10 seconds, and plug it back in.”

Clark Aldrich has a great post about the difference between Math as a Perfect science vs. Math in the Real World. It’s true, Clark says, that one and one equals two.

1 + 1 always equals 2. Isn’t that perfection? It seems like it. [But] if I combine two piles of hay, what do I get? One pile of hay!

The same goes for Training in the Real World.

When companies do soft skills training, for example, they can apply Perfect World principles. They can use the right blend of study, practice, discourse, and testing. They can even throw in a wiki and a podcast and everybody’s thrilled.

Training in support of change management on a major change, like a software implementation, is closer to the Real World (Sorry, HR training departments; I’m exaggerating for effect).

For example: Company A is installing Big Hairy Software package XYZ (or should it be called ERP?). They’re spending $2 million on the software, $8 million on their Big 4 system integrator, and taking 20 people out of their regular jobs to work full-time on the project for a year.

So, with a monthly burn-rate of $1 million or more, training takes on a new flavor. Is there really time to let learners practice (what the heck is the ROI on practice, anyway?). A Wiki? That would only facilitate rumors and mis-information (or would it?). The fact is, we don’t know.

Of course, I know that theory has to run a few years ahead of practice. It has to be perfected in the lab before it can work in the real world.

The trick is to somehow use a solid, blended learning approach in the context of a costly, time-crunched change effort. That might mean backing off on the Perfection a bit, and striving for a tolerable Reality.

Finally, a decent explanation for the uneasy feeling I get when I hear the phrase, “It’s not about the technology.” Put simply, it’s an oversimplification.

This feeling was articulated in a recent article by Andrew McAfee about the frequently over-used phrase, It’s Not About the Technology. He says,

Searching for this exact phrase yields about 1800 results on Google Blog Search, 17,700 on Google Web Search, and at least one book title. I’m sure I’ve said it myself a few times, although I try not to.

People usually mean one of two things when they say INATT; one of them is correct but somewhat uninformative, and the other conveys a lot of information, but is incorrect and even dangerous. The correct-but-bland meaning is “It’s not about the technology alone.”

I too have said INATT, because it’s a lot more provocative than what McAfee points out is the “correct-but-bland” meaning. For those of us in the fields of user acceptance, training, and change management, it’s an easy way to draw attention to - and puff up - our otherwise under-appreciated disciplines.

So, I started thinking: what’s a more interesting - and provocative - way to say It’s Not About the Technology alone?

Some completely inappropriate ideas:
All technology and no people makes Jack a dull boy.
Ask not what your technology can do for you …
It’s not about the technology, it’s about time for lunch (yikes)

Enough, already.

Let’s hear some real ideas.

A concise explanation for why large-scale software projects frequently fail, from Michael Krigsman:

Why do projects fail? Very often, the roots of failure lie in non-technical areas related to project management, organizational politics, and lack of consensus across stakeholders. In plain English, failures often occur when people with conflicting agendas can’t put aside their own narrow concerns and agree on a course of action that is best for the project as a whole.

In our business, we encounter a lot of people who specialize in Change Management, Organizational Development, Leadership Alignment, and similar fine pursuits. Few of them, however, can capture software implementation dynamics as succinctly as someone (Krigsman) who has clearly lived through these projects on the front lines.

A great post the other day from Michael Krigsman at his blog, Rearranging the Deck Chairs. He excerpts a white paper sponsored by SearchCIO called As the World Turns: CIOs and their ERP Dramas. A particularly insightful bit:

It’s not ERP systems per se that present the stumbling block; the trouble arises from the internal state of the enterprise, the way IT is conducted and how decisions are made. The ERP project ends up being a kind of IT CAT scan, revealing everything that is broken or out of alignment.

So getting full value from an ERP investment requires the organization to examine what’s out of alignment and fundamentally change how it works. The question is one of readiness: Is your company braced for this level of change?

I like the image of big-project-as-CAT-scan. It’s not until times of stress that we usually see what’s really not working in our organizations. I am encouraged, however, that more companies seem to be paying attention to change management before (or at least during) their large-scale software implemementations.