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.

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.

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.

Stop the virtual presses! The IBM CIO Leadership Forum, in a recent survey of 170 CIOs from around the world, discovered that, “In order to ensure organizations growth and business innovation, there should be a cordial relationship between the CIO and the CEO.”

So that’s the missing piece; if only we could be more cordial with one another, imagine what we could accomplish.

This astounding finding is further supported by another breakthrough discovery, this time in IBM’s 2006 Global CEO study:

The IBM 2006 Global CEO study indicated that CEOs who incorporated business and technology reported greater customer satisfaction, speed, and flexibility than their less integrated peers. According to the latest IBM Global CEO study conducted among 750 CEOs, 80% of the CEOs considered business and technology integration to be important.

It is possible, I suppose, that the CXO Today article’s, author (the always insightful Mr. CXO Staff) unintentionally watered down the survey’s results with his characterization of this essential relationship.

On the other hand, it could be that the author inadvertently submitted his summary of the 1976 Global CEO study (since that’s the last time a story like this should have qualified as news).

This stuff seems especially amusing to those of us in the custom training business, since we frequently find ourselves bridging the gap between IT and business. To us, it’s kind of like “discovering” that the engine in your garage should be attached to the car if you want to get to the store.

Don’t get me wrong, I’ve known some fine IBMers, and even developed thoroughly cordial relationships with some of them. This kind of research, though, doesn’t do much to boost IT consultants’ credibility.

Finally, anyone who bought either of these surveys, please let me know so I can change into my white pants and put the results in better context.