Training

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

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

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.

Help Facility

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 menu bar.

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.