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.

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.”

As I’ve been working with several customers over the past couple of weeks, the question keeps coming up: what are some good ways to sustain the impact of training after the initial classroom sessions are done?

I did a little online research and talked with an eLearning expert, Patty Stillwell, who I’m working with on several training projects. Here are some great ways to use technology to keep the initial excitement of in-person training alive while sharing business wins:

1. Give business managers exercises and surveys that they can push to learners using a survey tool. Learners complete and submit the survey, and results are shared with managers. This is a great way to measure classroom retention, ongoing change and provide recognition to those learners who find great business applications.

2. Create a wiki or blog for learners to share thoughts, ideas, new ways to use the training, etc. Encourage learning leaders who have successfully applied the training concepts to initiate the “dialogue” and support participation by others.

3. Implement a private channel for downloadable video or audio of lectures, recorded conference calls, presentations, etc. Utilize format-neutral options that work with a wide range of devices.
Develop short podcasts to share scheduled information updates or high priority notices (trends, competition, etc.)

4. Use your website to offer new tools and training updates with downloadable documents
Conduct Webex meetings and online discussions to foster collaboration between groups that may not otherwise interact.

5. Use Second-Life environments to expand learners’ understanding of changes throughout the company, supply chain and customer base.

A couple weeks ago I pointed out how we’re seeing more companies than ever - especially very large ones - rely heavily on Electronic Performance Support Systems (EPSS) as a complement to structured learning.

The idea is that employees want to learn only the information they need to perform a given task — and no more.

And, they want the information at the time the task must be performed — and no sooner.

Shortly after that post, Brent pointed out an article
in which Charles Jennings, global head of learning for Reuters, talks about a much-needed shift in training:

“Too many learning professionals are obsessed with transferring information into employees’ heads, even though they know that the amount of information is growing very quickly and that the nature of that information is changing.

“These changes mean that knowledge workers actually need less knowledge to do their jobs … Formal training is less effective as the amount of information increases and its shelf life becomes shorter.”

The article goes on to discuss the virtues of EPSS systems and how they enable real-time support. Reuters uses SupportPoint as a context-sensitive help system. We’ve been helping companies build content for these kinds of systems for over a decade, but it seems like we do it more every year.

So it’s good to know we’re not alone in advocating heavy use of EPSS systems which, according to Jennings:

Allow us to employ what I call ‘just in case’ learning. That means that the information is there in case you need it. A simple transfer of knowledge is no longer appropriate. We need to know less and learn more.”

Well said. In fact, Jennings’ term Just in Case learning is a bit less cumbersome than my term, At the Time learning - but the intended meaning is the same.

The photo above is from the excellent discussion thread at Tufte.com.

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.

Dozens of big companies have started running “serious play” workshops, in which participants construct Lego models to represent business challenges or opportunities. From an article in the Atlanta Journal-Constitution the other day, “Lego Facilitator” Lewis Pinault says:

“We use Lego as a tool that enhances psychological flow. Lego takes people out of their usual comfort zones.”

Psychological flow: good. Lego-free workshop: bad.

Seriously though, it does make sense. Any activity that results in participants setting aside their conscious egos seems likely to produce more creative ideas more quickly.

Another Lego Facilitator, Robert Rasmussen, says the program is effective because it results in 100 percent participation from 100 percent of the group 100 percent of the time.

In general, Rasmussen said Lego is rare in that it functions as a universal language understood by people regardless of their age, race, gender, or culture.

Again, sounds like a cool idea, but I didn’t think it was new. In fact, during the 10 years or so that I worked for a big company, I attended three or four training events in which Legos played a prominent role.

Today, Lego facilitators like Pinault help clients in two-day training sessions at a cost of $7,000.

I guess it was only a matter of time before some consultants got hold of a Good Idea and turned it into a Good and Billable Idea.

Photo from Digger Digger Dogstar.

Karl Kapp put together some nice guidance on software training last week in his post Tips for Teaching Software to Others.

Of course, since teaching software to others is pretty much at the core of our business, I couldn’t resist leaving a terribly long-winded comment, which I will excerpt below.

But first, I want to point out another comment in the thread, by Dave Ferguson that I absolutely love:

With newcomers (to an application, or to computers generally), I also try to avoid alternative-itis, a disease pandemic among enthusiasts. Many actions have a menu route, a keyboard-shortcut route, and sometimes a mouse-action route. Telling someone three ways to save doesn’t usually facilitate learning. Mostly, it increases cognitive load.

While Dave makes a lot of other great points, this one has always bugged me. I’ve often said that software training courses should follow this sequence: 1. Get trained; 2. Use it for 30 days; 3. Get trained on all the hot-keys and shortcuts!

Finally, this probably violates about 25 blogospheric codes of conduct, but I am actually going to quote myself from Karl’s comment box. Here are some of my own tips for training software to others:

1. Require pre-work. A couple of concise web-based intros (or quick Captivate modules, or even Powerpoint slides), prior to arriving in class can yield a huge return in terms of what you can accomplish in the classroom. This kind of pre-work serves two purposes:

A) It brings widely disparate skill levels to a base level of understanding (logging on, basic navigation, simple searches). This is a huge time-saver in class, and greatly appreciated by faster learners.

B) Done right, it can reinforce for students why it matters that they learn the software. There’s nothing worse as a trainer than having to “justify-on-the-fly” the employer’s rationale for moving to the new software platform in the first place.

2) Place every software function in the context of a business process. This requires genuine preparation on the part of the trainer, and of course the curriculum developer. Software training that focuses on clicks and screens (like most “out of the box” curricula) loses steam every time. Start training people on how to do their jobs, and everyone gets engaged.

Remember when you first set out to learn Excel (or Lotus)? I remember pulling up that first blank spreadsheet and thinking to myself, “what the h*** am I supposed to do with this?” Once I had a problem to solve, though, I was hooked.

3) Spend way more time than you think teaching on-line help. I know I’m just reiterating your point, but it’s such a good one that I think it deserves repeating. Most software learners won’t have a need or an opportunity to put their learning to work for days, weeks, or even months after class. By they time they need it, they’ve forgotten it.

If classroom training gives learners a proverbial fish (allowing them to eat, or remember, for a day), then teaching the on-line help gives them a handy, if cliché, fish-pole.

I was at Circuit City last night, buying one more in an endless stream of adapters, AC power supplies, and replacement batteries that now consume exactly 20% of my income (but that’s another story).

Overheard at checkout line:

Mature Woman (handing object to checkout girl
for scanning): I had a terrible time finding this.

Very Young Checkout Woman: Yeah, you don’t see
them much.

MW: I mean, what do people do if they want to take a walk
and listen to music?

VYCW (with pity): iPods

MW: Oooh.

It turns out the MW was purchasing a Walkman, as in cassette-player-with-headphones.

Initially, I thought, Whoa, what cave has this person been living in?

But then I realized that, very soon, I will be the Mature Woman in this story. Not long after that, the Checkout Woman will be the Mature Woman. And the Checkout Woman’s daughter will be pitying all of us.

Kind of makes a person want to be careful about thinking he knows an awful lot about an awful lot of things.

Here’s a great list of 101 ways to know your software project is doomed. From Codesqueeze.com via Michael Krigsman.

A few of my favorites:

#25. Project estimates magically match the budget
#35. Your manager thinks MS Project is the best management tool the market offers
#46. Your manager thinks being SOX compliant means not working on baseball nights
#50. Your manager spends his lunch hour crying in his car (true story)
#79. Budget for testing exists as “if we have time”
#100. You have been 90% complete 90% of the time

My suggestion for #102: Your manager believes the software salesperson who says, “Training’s included.”

While the banking industry appears to adopting gaming as an eLearning tool at a healthy pace, there’s not much else to cheer about in that business.

Two contrasting articles published this week:

1. Gaming as eLearning tool on the rise in banking industry.
2. Banking industry falling apart.

The following from a Business Week article citing research from the eLearning Guild. (Congrats to Brent, by the way, for the nice eLearning Guild visibility in Business Week):

According to a 2007 survey by the eLearning Guild, which polled nearly 1,500 of its members, from large and small companies throughout the U.S., 38% of insurance companies are investigating using games for work. In finance, accounting, and banking, that figure was above 50%.

Meanwhile, The Hub, talks about a looming banking industry crisis that many believe has only just begun:

Big banks are seeing merger and acquisition activity frozen, resulting in a full stoppage of deals that were in progress, which can’t be good for bonuses.

Various bankers and financial types we’ve talked to lately have ranged from quietly worried to nearly hysterical to uncomfortably sarcastic.

“Work sux” says one [hedge fund employee] by text.

“Its bigger than the Asian Financial Crisis in 1998″ says one person at Merrill Lynch. “Some major hedge funds are going to not be here by next year.”

I certainly don’t mean to imply a relationship between gaming-as-eLearning and the growing banking crisis. Nor would it be prudent to make light of the plight of those in the banking business. But, you have to admit, this could provide ample grist for any number of late-night talk show hosts.