Why Trainings Fail?

We look at the gaps in handling IT Training in many IT organizations, and why it so often falls short of the mark.

Ad hoc requirements: No IT organization would take up work on an application or a product without having a detailed requirement drawn up first. Requirement study and design form a major part of any software development life cycle, irrespective of the development model followed.

However, when it comes to training, the needs and objectives of the training are often not clearly stated. A typical training requirement often goes out as a one-liner, though the technologists who are the stakeholders for the training are aware that this does not adequately describe what they really need.

Technology topics are actually vast and complex subjects. Training is not a replacement for college education - it is needed to meet specific project objectives by bringing developers up to speed quickly on certain technical subjects; on these they would be required to work and deliver results in a short while.

Thus, in such cases, if the training specification is laid out to match the actual project requirements and trainee profile, it is helpful both to the organization and the trainer as a whole. Failing that, an open discussion in detail with the trainer should be the first activity in a training exercise, especially if the needs are complex.

This saves a lot of time that gets taken up subsequently, and helps in keeping the training precise and to-the-point and thus more effective.

Often, the number of people to be trained is not specified correctly, even though it's clear that this has an impact on the actual conducting of the training.

I would give an example to indicate how ineffective training can be if designed and delivered around an indifferent specification. Several years ago, I was working for a Software giant, and two projects needed that the designated workforce be trained in a product of considerable complexity. Trainers were flown in from abroad and a week long course organized. Sadly, the specific needs of the projects were never consulted in deciding the training contents, nor the technology readiness of the team addressed prior to training delivery. The result was an instantly forgettable training experience, delivered at a high cost, which did not address the issues that the teams faced later on. Half the team was not even ready for the training - it did not address the basics and went overhead for most. The training was part of a stock training the software vendor had for the product, but ill-designed for the specific case.

Ineffective Management: In so many organizations, the training needs are handled by the HR team or a Training Manager, and do not come up to the mark. They are not always in a position to realize the inadequacy of the specifications they receive from the project team, and their effort gets directed towards collecting a number of proposals and leaving it to the project team to take a decision. 

The trainer may have many observations on how the training should be conducted - but these don't always get projected to the project team. There is, as a result, often no appreciation of the difference in quality between two adjacent proposals for the same training. In effect, training gets treated as a commodity.

I should say that their responsiveness also can improve. Trainers - the knowledgeable set at least - may often need to get in touch with the technical team to understand the real training needs and design a solution accordingly. This does not happen smoothly if the request for an audience is passed through the HR person. If the Trainer submits queries through mail, there is often no response received. Once a proposal is submitted by a Trainer, there would be no updates on the status of the proposal unless he calls up the person in question.

There would be notable exceptions. But, in majority of cases, Training is viewed as a commodity by the people responsible for driving it and treated as such.

Issues with technical teams: There is a flip side to the scenario above. At times, when the training manager is eager to arrive at a decision regarding training, there would be delays from the team who are the ultimate decision takers on the training. It is understandable that project team members would give priority to their immediate project needs. However, this mindset can and often does lead to unconscionable delays in finalizing the training.

We have seen cases where the training manager has followed up conscientiously on the training needs initially received by her, got the necessary proposals in, clarified to the best of her ability any questions from the Trainers; this for trainings which initially were to be delivered in the shortest possible time; and then have to wait indefinitely because the technical team is taken up with more important issues.

Queries from the trainers are often not very well received by the technical team who are best suited to answer them – whether due to lack of time or plain organizational hubris. Considering the trainer as an external consultant for the training is the best way to ensure excellent training quality, but this is seldom practiced. Companies have a process of conducting an interview of the trainer, and trainer evaluation is well and good; but that does not address the issue here.

Some companies try to address quality concerns by putting in a clause that if training is found unsatisfactory, the training organization shall deliver the same training again free of cost. This is rather like resorting to the authority of the family court to save a marriage.

The result is a mismatch of expectations when the actual training does get conducted. And it hurts the IT organization most.

So, how do we break out of this cycle? What changes need to be brought about in the way companies approach training and what should they look for among training providers, to make IT training - which, we all admit is a vital need – really effective? How should our mindsets change in this regard?

We look at these issues in the next edition of the blog - one week from now.