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.

Measuring the Gap

Now we look at the first of the gaps listed in my first post - the gap in the difference between the skill sets young graduates from a majority of Educational Institutions come out with into the job market, and the skills they need now to join a company's workforce and be productive as soon as possible.

Graduates from a technology-oriented bachelors’ program are expected to be ready for employment. This implies that they have already mastered the necessary skills and been exposed to key technologies of interest to employers.

However, the progress in computer and computing related technologies in the industry, and the fact that most graduates are caught with their wrong foot forward when they join such companies, makes one wonder whether most of the colleges are doing enough to prepare their students for the realities of the work arena.

Majority of students come out with the impression that skills in programming in a high level language like C++ or Java are adequate when it comes to facing the highly competitive and emerging computer field in IT organizations.

It should be noted that during the Y2K crisis, any graduate was given a basic training in troubleshooting the issue and in conversion, and found employment.

It should also be noted that a large number of developers do not necessarily come from a computer science background at all, but from diverse disciplines such as mechanical or civil engineering. They make the transition by taking up basic language courses offered by external organizations, and then essentially self-train themselves as they go about their job. Peer learning and occasionally a good mentor is often all they have for a support system.

Trainings organized are often very project specific and on complex and advanced topics, opr ? particular products. A large percentage of the people who attend such trainings don't get what they should get out of such trainings, and stumble and learn things the hard way.

The result is lost productivity, and lost time in organizations trying to execute projects under tight deadlines. Sometimes, it also end up stretching the project delivery period since the team doesn’t have the right expertise n skill-set to execute the project efficiently. Also, having picked up skills the hard way, freshers are always on the lookout for the next better opportunity. The individual programmer is an IT company's asset, therefore, when he walks out through the door at the end of a day’s work, he should have sufficient reasons to come back the next morning. A conviction that the company has invested enough time and money on them to develop and sharpen their skills can be the clinching factor.

Having said these, let me point out the desired skill-sets that is required or sought after in the fresh joinees in an IT organization, and where lies the gap therein.

• Most of the fresh joinees have little or no idea about setting up complex development environments involving one IDE or the other, or in use of versioning systems.
• They have scant ideas about software testing and the discipline involved for that. Software testing is an essential skill-set for a software programmer even though in the organisation there may be a different team handling quality aspects.
• They often have no concepts about networking, cell phone systems, Payment systems, ATMs, WiFi, LAN etc. Such knowledge is vital to work effectively in today's complex and multi-disciplinary software projects.
• Database concepts are often very elementary; skills in writing database procedures or complex queries, SQL optimization or basic database administrative functions are lacking.
• Freshers are often good at picking up technology aspects, but are very weak at application design aspects. They lack ideas on basic design patterns.
• They are also in adept at web technologies when they join an organization. For basic skills like Javascript, Ajax etc there are no comprehensive training courses available, and the path to knowledge is often through peer interaction and internet lookups and hack solutions. GUI and usability skills are often lacking. They possess hardly any knowledge on fundamentals of web and application containers as well.
• And most importantly, most often they lack a structured way of thinking to solve hard computing or algorithmic problems that come up their way during their work. It is a known fact that bulk of the time spent by a programmer on a project comprises of attempting to solve problems with which they are stuck. Problems often get solved through collaboration or through assistance from Internet forums rather than through thought, and the time spent on each such issue can be considerable, affecting the overall timeline of the project as such.

Apart from the technology related gaps above, such freshers are also expected to be good at communication and teamwork. They are required to perform in a competitive team, be ready to escalate issues as and when they rise and attend customer calls. With scant exceptions, majority of the fresh joinees are unprepared when it comes to this.

To a large extent, these issues also plague developers who may have put 2-3 years of work at an organization - because they started with the same base.

My point is, a thorough grounding on the above skill-sets is needed for any developer to be productive from day one, and is also the basis on which IT organizations can build the technical leaders of tomorrow. When the base is suspect, and institutions offering Computer Science courses are not likely to change their mindsets and co-ordinate with the industry to understand the market demands, what options do the freshers have? What options do the IT organizations have?

In our next installment we take a look at training - how it is handled in IT organizations presently...and why it is inadequate.