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.

For a good discussion of big-App training see Tony Karrer’s site.
He starts the discussion with a post of a question from B.J. Schone, who is looking at a major PeopleSoft upgrade. Someone suggested to him that users would need 80 (no, it’s not a typo, eighty!) hours of training. B.J. was rightly concerned that something was wrong.
Read Karrer’s post, and some comments, including mine.
Here’s my comment as well:

“80 hours of PeopleSoft training? Could that estimate possibly have come from someone with a vested interest in selling lots of training?… Some further thoughts on BJs question:

1) Complete agreement with the training design starting and ending with roles & tasks: don’t make people sit through “general” stuff…engage them with what they actually have to do in the to-be world of new processes and new (or changed) technology.

2) Get off the Happy Path. Bj talks about how boring applications training can be. He’s right and adding some random Nascar simulation doesn’t make it any more engaging. Apps training that takes people down a single happy path where everything works perfectly is boring because learners understand as soon as they leave the training room and return to the real world, they’ll fall right off that happy path. So, give em real-life scenarios where things get complicated and messed up and engage them in figuring out how to solve the real problems they’ll have.

3)Dr. Tony talks about using hybrid/reference tools. If he’s talking about what we call EPSS — a system that allows users to view the process flowchart, find their swim lane, find their task, see its relationship to other roles and tasks, and finally drill down to a step-by-step work instruction he’s right. The point is that no matter how good training is people don’t retain much.

4) Plan for (as in save time and $$$) post go-live training. Pilots are a good start on getting the training right. But give people the first month of limping along with the new process/tech and then offer them more training. Devise the content for this post go-live training by reviewing help desk call logs, or by getting users to send in questions. Or just hold open labs where users can come in and work through real-life problems shoulder-to-shoulder with an expert. This training actually sticks because it addresses real problems that real users have, NOT a random, boring stroll down the happy path.”

Everybody knows good training is essential to the success of enterprise software implementations, right? Well, if that’s true, why do so many companies fail to budget for it sufficiently?

Once a typical ERP project is about to go-live, chances are it’s over budget. Unfortunately, just prior to go-live is also about the time that:

- Senior management and business unit leaders start asking how everyone is going to get trained.
- The project team starts asking where the money for training is going to come from.

To make matters worse, the software vendor’s sales pitch is starting to sound, at best, like an optimistic version of the truth: “Don’t worry, our software is so intuitive you won’t really need to add much for training.”

To help those caught in the trap of shrinking budgets and expanding training needs, here’s a list 10 ways to stretch a training budget.

1. Start early. Request system access for the training team months in advance, not weeks. The last thing you want to do at crunch time is figure out how to access for another half-dozen team members.

2. Insist that your software vendor and integration partner construct a stable training environment so that training developers don’t spend time (and money) debugging untested software.

3. Get virtual private network (VPN) access for training developers and remote employees involved in acceptance testing. This will save thousands on travel and living expenses.

4. Use web-based training (WBT) as much as possible. A solid curriculum of asynchronous WBT modules, and synchronous eLearning (webcasts) can greatly reduce – or even eliminate – the need for in-person classroom training.

5. If you out-source WBT development, provide your vendor with corporate standards for online material and access to your LMS for compatibility testing. Do this early. Don’t consume budget on last-minute hassles with LMS connectivity.

6. Manage all class logistics from enrollment through room setup and materials reproduction internally. This is administrative work – don’t pay external consultants for busy work.

7. Document the job roles of system users and the tasks they will perform in the system. Provide your training developers with flowcharts or use cases that delineate job roles and process boundaries.

8. Assign one or more experts from the development/ configuration team to answer questions about the details of your customizations so that your training team or vendor can quickly document and prepare accurate scenarios. Don’t make them waste their time searching for answers.

9. Provide the training team with realistic training data for use in training classes – don’t make them spend their time searching for data.

10. Develop a team of super users who can attend classes (or stop in at scheduled intervals) to answer process-specific questions that might stump the stand-up trainers.

I know what you might be thinking: many of these items don’t seem like traditional cost-cutting measures. Assigning a member of the development team to training, for example (#8), sounds like a cost increase.

And it’s true, in the short run, some of these items might actually cost money. The trouble is, shortcuts in these areas will end up costing the company thousands – or millions – in lost productivity, errors, and re-work. (The term penny-wise and pound-foolish comes to mind).

In the end, it’s not just about the cost of training – it’s about cost of training’s impact on the organization.

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.

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.