Search FCW


Subscribe Now!
Table of Contents
Sprint
Business
BPM
CXOs
Columns
Columnists
Defense
E-Government
Elections 2008
Enterprise Architecture
Funding
Homeland Security
Health IT
IPv6
LOB
Management
Procurement
Privacy
Policy
Program Management
State and Local
Security
Technology
Telework
Training and Certification
Workforce

More Topics
resourcecenter
Home
Letters to the Editor
Current Issue/Download
Print/Online Archives
Editorial Calendar
researchstore
resourcecenter
Communications for Continuity Operations

Oracle Resource Center
NEW - Data Center Virtualization
NEW - Air Force ELSG Contract Guide
NEW - Security Management
NEW - DOD and Security Guide
Networx Contract Guide
SEWP IV Contract Guide
Priority Report: Virtualization
NEW - CHESS formerly ASCP
New - SATCOM II

More >>



Latest News
ADVERTISEMENT





 

Why training programs often fail

By Robert J. Guerra and Thomas Hogan
Published on September 17, 2007

Comment

Click here to comment on this article


Newsletters

You might also be interested in these FCW newsletters:

Daily
Management
Policy and Procurement

To learn more, click here.


Recently, a telling photo made the rounds of our community. It showed a successful looking executive using a BlackBerry to keep on top of business. He was standing next to a beautiful 80-foot yacht named "Change Order," and behind the yacht was a dinghy, appropriately named "Original Contract."

If nothing else, this photo reflects what's wrong with the psyche in the world of federal acquisition. We just don't seem to be able to get what we need because we insist on defining what we think we want. Time and time again experience has proven that detailed specifications are at best correct only for a relatively short time and at worst way off the mark.

Nowhere is this more evident than when it comes to user training during the deployment of major systems. Training requirements in solicitations usually focus on classroom- or computer-based training education rather than on outcomes that meet end-user goals. The attitude is, "Training? Who cares about training?" Training is just a means to an end, which is how people perform once a system is deployed. Folks in that business call it "human performance." In our business, we conduct acceptance testing by having the developers who know all the ins and outs of the system confirm the adequacy of their own work or use third-party testers who do pretty much the same thing.

Actually, training, in its classic context, probably is the least important part of any major deployment. Much more important is whether the user community accepts, understands and uses the new solution effectively.

We all acknowledge that training efforts usually fail for several reasons: 1) the students come unprepared to be trained, 2) they are taken out of their already pressure-filled jobs so they don't want to be trained and 3) because it will be six months to a year before they see the final new system (with all of the changes that happened after the training) in operation.

Generally, the solution is to have the systems integrator that is developing the solution teach the customer how to use it. Foxes guarding the hen house? In most cases, the integrator would seem to be motivated to have less-effective training in order to allow for more billable labor hours, right? Unfortunately, the measures of success for the training usually have nothing to do with the success of the deployment, but with attendance at classes or grades on exercises.


upcoming event

Enterprise Architecture 2008 - Washington, DC
September 9 - September 10, 2008

Occupational Health & Safety Executive Summit - Arlington, VA
October 6 - October 7, 2008


 

head
fcw
issue
First Name State
Last Name Zip
Title Email