Training is a critical component of any software solution
delivered by a project. The only time that training need not be considered is
when a new release of a software system has no impact on the user community
whatsoever. No impact means that the changes delivered in the new release are
entirely transparent to the user. Projects that deliver new systems, or systems
that add or change features should include some form of training.
New software systems, or upgrades of existing ones, are
usually built to address a business need and that need cannot be met by the new
system alone, it takes a proficient user community working with the new or
upgraded system to realize all the benefits captured in the Business Case orProject Charter. The more feature rich and complex the system, the more
important user training becomes. Some businesses are very mature in the area of
user training and actually treat their training departments as a profit centre.
These folks are probably already acquainted with the advice contained in this
article. If you are not one of these folks but do have a software system to
deliver, read on.
Organizations responsible for implementing new systems
frequently overlook the training component of the system, or if it is
addressed, it is not treated as a high priority. This approach may deliver the
best software system in the world, but if its users struggle to gain command of
it, it will quickly be viewed as a failure by the user community. For all these
reasons, training should be considered a key project goal or objective and be
captured in the Business Case or Project Charter along with the other key
Off-the-shelf or OEM Software
The project manager should ensure that user training is
considered when buying a component of the system. The training provided by the
vendor is as important as the documentation that comes with the application.
The training should be one of the criteria the product is evaluated on and
should figure into the purchase decision. Include the training component in the
criteria list you compose to make your decision and weight it with the rest of
the criteria. You can restrict your training costs by selecting a trainer from
your organization (or another in the same company) who will train on the new
application and then train your user community, just remember that the cost of
the in-house trainer should be borne by the project.
The significance of the application to your system and its complexity
will determine how you approach training and how important the training will be
to the use of the overall system. If the application forms all of, or most of,
the system you may want to consider having the external vendor deliver the
training. This decision should be made based on the comparative costs of the
in-house and vendor provided training, the comparative abilities of the 2
trainers, and the criticality of the training to the project.
In-house training will be required when the application is
custom built, or customized, or when the system is custom built. Requirements
should be gathered for in-house training in the same way you use to gather the
requirements for the software features the system will have. First identify the
stakeholders who will benefit from the training. This group will definitely
include the users of the system but might also include sales staff who are
responsible for selling the system, or services the system offers. Others to
consider are staff responsible for maintaining the system, database
administrators, systems administrators and help desk staff.
The next step is to determine how many different flavours of
training will be necessary to provide adequate training to all the people who
require it. The "one size fits all" approach may be appropriate where
the system is simple and the functions it supports will be limited. More
flavours will be required for large complex systems which support multiple
functions. Once you have determined how many different training sessions will
be required, you can identify the requirements for each of the sessions.
Work with your in-house training expert to determine the
approach you will take to training: train with a manual and lectures, or
"hands on" training. The advantage of the hands on approach is its
similarity to actual work situations. The disadvantage is the cost of providing
a working model of the system to the
trainer in advance of deployment.
Scheduling training sessions is important. Train too soon
and you risk having your students forgetting what they learned in the time
between their training and deployment. You also run the risk of approved
changes making the material obsolete. Train too late and you run the risk of
minor delays in training activities resulting in delivery after deployment.
Make the training occur as close to deployment as possible but leave yourself a
buffer so that if there are minor delays they don't derail training.
You will have to add training to the list of groups to be
consulted regarding the impact of a proposed change on the project. Choose a
training SME who can take responsibility for all the planned training. Each
change in the features or functionality of the system will have a potential
impact on training so those change requests must be forwarded to the training
SME for analysis. Things to watch for are: changes that occur after all, or
part of, the training materials have been composed, or changes that would draw
in new user groups to be trained.
Combining Training and UAT
One way of overcoming the problem of providing a system for
hands on training is to combine the activities of User Acceptance Testing (UAT)
and training. This approach can also overcome the resistance of the user
community to participation in UAT. The proposition is simple: access to
training is dependent on participation in UAT. To combine these 2 activities
you will need to access everyone who has signed up to the UAT platform and
ensure that the hands on training thoroughly exercises the system. A more
complete description of how to combine training and UAT can be found in the QA
section of this web site.
Most software today comes equipped with a help facility
which provides a simple version of on-line training. The role that the help
facility will play in the system and how it will integrate with training should
be considered when capturing the requirements for the system. Generally
speaking the more thorough the available help is, the less critical classroom
training becomes. In fact, many software applications rely totally on this form
of training. On-line help should be available at the feature or function level.
One approach to providing on-line help is to provide the help on the menu bar
appearing at the top of the page. The contents of the pop-up windows containing
the help information change depending on what screen is associated with the
Care should be taken when writing the help facilities. One
approach that will provide excellent quality is to include writing the help
information with the task of writing user manuals. The help facility that a
trained technical writer can provide will be superior to anything a programmer
or analyst can write. The information that populates these facilities can be
extracted straight from the manual and pasted into the on-line help screen. The
details of handling on-line help are beyond the scope of this article. Making
on-line help a part of system requirements should provide the analysis
necessary for a quality product.