What Makes a Great Training Organization? (eBook)

Chapter 4

Diagnostics

Leaders of training organizations perform diagnostics in the same way your doctor does: they assess your current health and establish a baseline, determine the cause of any problems that exist, and recommend solutions to get to a desired state. In training, learning leaders perform diagnostics by assessing the current performance of the organization they support and determine if new training is needed or if the current training solutions provided are achieving the desired results. If the solutions are not achieving the desired results, the learning leaders assess the root cause of the problem and prescribe actions to remedy or improve the situation. And, as with a doctor’s first look, their objective is to determine what is performing well, what is not performing well, and what adjustments need to be made.

Leaders of training organizations use a series of approaches, processes, or strategies coupled with previous experiences with other clients and initiatives to diagnose real problems. The quality with which a training organization uncovers the “true” needs or drivers of the gaps in performance is key to an organization’s success. Some organizations rely heavily on the review of data to determine whether a client’s training was as effective as it was designed to be. Diagnostics is important because it helps you link solutions to the needs of the business, and it helps you improve the probability of success, as well as shorten the time it takes to deliver the training, increase the effectiveness of the training, and reduce the costs of doing it right.

Diagnostics is the bridge between understanding a client’s needs and performance problem and delivering a set of requirements or specifications for the learning solution. It’s important to comprehend that diagnostics doesn’t end when you say you understand the problem. Diagnostics includes delivering a set of recommendations or specifications to the instructional design team. In a case where training can be procured from an external firm, the specs may be given to procurement and ultimately to the supplier. Specs must be delivered to whoever needs to be a part of the design of the solution or intervention.

Differences between Diagnostics and Strategic Alignment

At first glance, it seems that diagnostics and strategic alignment are very similar. In essence, they are closely linked. Strategic alignment, though, involves training leaders working with clients to determine their needs and understand their objectives. In addition, strategic alignment allows learning leaders to find problems so they can do diagnostics. For example, for a doctor to diagnose a patient’s illness, he or she must interview the patient to understand pain and discomfort and then use data from tests to look for underlying symptoms and causes.

Diagnostics is an activity that follows strategic alignment, where the leader triages problems related to the training organization’s success in meeting client objectives. Think of it this way: you can’t know what the root causes of the problems are if you don’t understand the objectives. What makes diagnostics and strategic alignment different is that whereas strategic alignment determines needs, diagnostics determines what’s keeping you from fulfilling those needs.

In our research, we found a large telecommunications company that was experiencing double-digit growth in employees and revenues. It showed us an example of how diagnostics can impact the performance of a business. The learning leader was confronted with the problem that newly hired software engineers were being inserted into intact teams of product developers and expected to learn from their coworkers on the job. Inconsistencies in getting new hires up to speed and productive led to many quality issues, missed deliverables, and frustrations among product development managers and staff. To compound the problem, the company’s growth required it to increase new hires by more than 2,000 software engineers per year—most of them right out of college.

To diagnose the problem, the leaders of the training organization met with client executives to understand the fundamental need of the business. They found that product development executives expected new employees to be productive much sooner than was actually happening. The time to productivity for new software engineers was much longer than what the software design organization expected or needed. To compound the problem, a small budget was appropriated for training new hires. The expectation was to get them trained quickly for little or no investment, basically through a few one-day workshops and then on-the-job training with coworkers. The software engineers also required knowledge of a very sophisticated software development environment, which included access to a proprietary product development methodology, as well as familiarity with the product architecture for which they would be developing code. These requirements were not being communicated consistently and effectively because the engineers expected to manage this communication had been hired just a few months earlier and had also not been trained properly.

After working with the client’s leadership team and looking at the performance requirements of the software engineering role, the leaders of the training organization concluded that the fundamental objective was to quickly get newly hired engineers proficient enough to be placed into design teams of 5–10 people without disrupting current activities and, of course, to do it for the lowest cost possible.

To get to a solution, the learning leader had to deal with five key issues:

• The training needed for each employee was estimated to exceed six weeks of in-depth classroom training, which posed a large expense, especially if the organization chose to use external suppliers.
• Much of the content was proprietary information. This meant it was impossible to source external instructors with knowledge and experience of the subject matter.
• The workload for trained and experienced software developers was so high that management of the product development groups had a hard time allowing employees to take time away from the job to do training.
• The new hires were being deployed into seven development centers across four locations in the United States, five in Canada, and two in the United Kingdom. Therefore, the training had to be replicated in multiple locations. Having new hires travel to a training center for six weeks was prohibitive.
• The training needed to be very hands-on, in labs with lots of instructor involvement.

Working with executives of the software design teams, the leaders of the training organization determined that the solution was to develop a six-week onboarding program that blended classroom, eLearning, and virtual instruction. All the engineers began the training after one week of onboarding on human resources policies and procedures. They were then scheduled for a series of classroom and lab-based programs delivered by internal subject matter experts to get them familiar with the proprietary development environment and product architecture. For the courses that consisted of nonproprietary content (object-oriented analysis and design and telecommunication protocols), virtual instructor-led delivery was used, with one external consultant delivering to multiple locations in live virtual classrooms. This kept the cost of external training suppliers to a minimum. The important lesson from this case was that using a systematic approach to understanding the needs of the client, gaining an understanding of the causes and issues that affected the problem, and then looking for alternatives to find a solution returned the best solution for the best value.

Let’s examine a training program designed to reduce the number of calls that escalated from Level 1 support to Level 2 support at a customer call center that was supporting the start-up of a new consumer technology product. By working with the client manager, the learning leader began the diagnostic exercise by pulling the data associated with calls from various call centers related to customer documentation. The analysis found that the highest percentage of call escalations (from Level 1 to 2) were coming from two call centers, both with mostly non-English inbound calls. The data showed that the call times for these two centers were substantially shorter than similar inbound calls to the English-language call centers.

Using this analysis, the client manager and the learning leader realized that the basic training for these groups needed to focus more on how the call center professional handled the initial receipt of the call. In all call centers, the first 30 seconds of engagement with the caller is the most important in understanding the problem and determining whether the customer’s issue can be resolved quickly or whether it needs to be escalated for more detailed support. The client manager and the learning leader reviewed the current training program and compared it to the needs of the business. They found that in the non-English version of the call center’s professional computer screens, two initial screens did not have the appropriate information to help the call center professional solve the customer’s problem. They also found that the English program did have a review of these two screens and dedicated about 10% more time on the start of a new call...