Find the real performance gap and decide whether training, a job aid or a process change will fix it.
Why it matters
Training is often requested as a solution before anyone has defined the problem: "Our support engineers keep mis-rating incidents. Can you run a training?" Sometimes training is the answer. Often the real cause is a confusing tool, a missing process, unclear expectations or incentives that reward the wrong behavior, and training will not fix those. A training needs analysis (TNA) finds the real gap and the right solution before you spend weeks building a course.
Three levels of analysis
William McGehee and Paul Thayer (1961) described three levels that are still the standard frame:
- Organizational analysis: what are the business goals and where is performance falling short? Is there support (time, budget, managers) for training?
- Task analysis: what does the job require? Which tasks, in what steps, to what standard?
- Person analysis: who needs training, and what can they do now?
For the incident-response example:
- Organization: the goal is to resolve customer-impacting incidents faster; mean time to resolve has risen 30% over two quarters.
- Task: correct severity within five minutes, escalation to the right team, a summary within 24 hours.
- Person: new engineers mis-rate about a quarter of incidents; experienced engineers rarely do.
Is it a training problem?
Robert Mager and Peter Pipe's Analyzing Performance Problems offers a famous test: could they do it if their life depended on it? If yes, they already have the skill, and training will not help. Look instead at obstacles, consequences and feedback.
Thomas Gilbert's Behavior Engineering Model (1978) lists six factors behind performance. Three are about the environment (information and feedback; tools and resources; incentives) and three about the person (knowledge and skills; capacity; motives). Gilbert argued that environmental factors are usually the cheapest and most powerful place to start.
| Finding | Likely cause | Better solution |
|---|---|---|
| Engineers cannot find the severity matrix during an incident | Information/tools | Link the matrix inside the tool's severity field |
| SEV1s page managers at 3 a.m., so people avoid choosing SEV1 | Incentives/consequences | Change the paging policy |
| New hires don't know what "customer-facing" means for internal services | Knowledge | Training plus a job aid |
| No one tells engineers when they mis-rate | Feedback | Weekly review of a sample of incidents |
A TNA often recommends a mix: a short training, a job aid, and one process change.
Gathering data
Use several sources so you are not relying on one opinion:
- Existing data: incident records, quality reviews, support ticket tags, LMS records, help-desk questions.
- Interviews: managers, top performers and new hires. Ask top performers what they do differently.
- Observation: shadow someone handling a real incident (with permission).
- Surveys: good for breadth, weak on depth; keep them short and specific ("How confident are you choosing between SEV2 and SEV3?").
- Skills checks: a short practical scenario reveals actual skill rather than self-rating.
Writing the gap
State gaps as observable differences between the desired and current performance, and quantify them where you can:
Desired: new support engineers assign the correct severity to 95% of incidents within five minutes. Current: 74% correct in the first 60 days (sample of 200 incidents, Q2). Main confusion: SEV2 versus SEV3 for internal-only impact.
This gap statement becomes the basis for objectives and for evaluation later, so it pays to measure it now.
Prioritizing
You will find more gaps than you can address. Prioritize by impact (cost of the gap to customers or the business), frequency (how often the task happens) and feasibility (can training actually change it?). A simple impact versus effort grid works for a stakeholder meeting.
The TNA report
Keep it short:
- Business goal and the problem as reported.
- Data gathered (sources, sample size).
- Gaps, stated as desired versus current.
- Root causes for each gap.
- Recommendations: training and non-training.
- How success will be measured.
Cathy Moore's action mapping gives a quick version of the same logic: start with the business goal, list what people need to do to reach it, ask why they are not doing it, and design practice only for the behaviors where knowledge or skill is the real barrier.
Common mistakes
- Accepting "we need training" without analysis.
- Relying only on a self-assessment survey.
- Interviewing managers but not the people doing the work.
- Describing gaps as topics ("needs incident training") instead of performance.
- Not recording a baseline, so you cannot show improvement later.
Quick recap
- Analyze at organization, task and person levels.
- Ask whether it is really a skill gap ("if their life depended on it").
- Use several data sources and quantify the gap.
- Recommend non-training fixes where they are the real answer.
Try it
On the Do tab, run a small needs analysis on a real or realistic performance problem.