Learning needs analysis: a step-by-step guide for L&D practitioners

Needs analysis is the first phase of any learning design project — and the one that most determines whether the outcome actually matters. It is where you figure out whether training is even needed, what kind, for whom, on what specifically, and how you will know if it worked.

I want to be direct about something before we get into process: most poor learning design is not a design problem. It is a diagnosis problem. Someone skipped the analysis, assumed they knew what the problem was, built a course, and three months later nothing changed — because the real issue was never a knowledge gap in the first place.

This guide walks through a complete training needs analysis process: what it is, why practitioners consistently skip it, how to do it well, how to choose your data collection methods, and — critically — how to recognise when training is not the right answer.

What needs analysis actually is

A training needs analysis (TNA) is the process of identifying the gap between current performance and desired performance, and determining whether that gap can be closed with training.

The key word is gap. This is not an inventory of interesting topics. It is a focused investigation into a real performance problem:

• What are people expected to do?
• What are they actually doing?
• How large is the distance between the two?
• Is that distance caused by a lack of knowledge or skill?
• Or is it caused by something else — tools, process design, motivation, environment?

If the cause is not a knowledge or skill gap, training will not fix it. That is probably the single most important conclusion in all of performance consulting, and it is the one that stakeholders and sponsors most reliably resist hearing.

Why practitioners skip it — and what happens when they do

“We already know what they need.” The stakeholder arrives with a pre-packaged solution: “our managers need a leadership course.” The learning designer starts building without asking why. Three months later, the course is live and the managers have the same problem — because the root cause was not a knowledge gap about leadership, but a lack of time, unclear expectations, or a broken process that no amount of training can fix.

Time pressure. “There’s no time for analysis — just start producing.” The result is a course delivered quickly that resolves nothing. The rework that follows almost always costs more than a proper analysis upfront would have.

Limited access to data. The designer cannot get performance metrics, cannot speak with end users, or is working from second-hand information passed through three layers of management. The solution to this is professional: negotiate that access before the project begins. Getting access to real data is part of the role, not a nice-to-have.

When needs analysis gets skipped, the consequences are predictable:

• Courses no one actually needs
• Content that does not address the real problem
• Training solutions applied to problems that are not training problems
• Wasted time and budget
• Damaged credibility for the L&D function

The five steps of a needs analysis

Step 1: Clarify the business problem

Before you think about training, understand the business problem. What is happening that should not be? What is not happening that should be? Frame the problem in terms of observable outcomes, not content topics.

Weak framing: “Salespeople need a product knowledge course.”

Strong framing: “Salespeople are losing deals because they cannot articulate the differentiation between our product and the competitor’s during live demos.”

The strong framing names a specific, observable behaviour and connects it to a business consequence. That framing will guide everything that follows.

Questions to ask at this stage:

• Who requested this training and why — what triggered the request?
• What business metric is expected to improve?
• How long has this problem existed?
• Has anything been tried before? What worked? What did not?

Step 2: Define expected performance

Describe what people should be doing if they had the knowledge and skills they need. Write this in observable, measurable terms — not “understand” or “be aware of,” but specific behaviours you could watch for and evaluate.

Weak: “Understand the company’s safety policies.”

Strong: “Identify a safety hazard in their work area and report it using the internal form within two hours of observation.”

This step gives you the success criteria you will use to evaluate whether the solution worked. Without a clear definition of expected performance, you have no way to measure whether anything changed.

Step 3: Assess current performance

Investigate what people are actually doing today. Use data collection methods (covered in the next section) to build an accurate picture — not the manager’s perception, not what was true two years ago, but the current reality on the ground.

What you are looking for:

• What are they already doing well that should be preserved?
• Where are the specific gaps?
• Are gaps uniform across the group, or do they vary by team, location, or tenure?
• Are there people who consistently perform well? What are they doing differently?

That last question is often the most valuable. High performers usually have something to teach you about what the solution should look like.

Step 4: Analyse the root causes of the gap

This is the most important question in the entire process: why does the gap exist? Not every performance gap is a knowledge gap.

Causes that training can address:

• They do not know how to do it
• They have not practised enough to develop the skill
• They learned it incorrectly in the past

Causes that training cannot address:

• They know how, but do not have time
• The process is confusing or contradictory
• The tool is poorly designed for the task
• There are no consequences for not doing it
• There is no incentive to do it well
• The work environment prevents it (noise, constant interruption, unrealistic workload)

When the root cause is not training, your job is to say so — clearly, with data, and with a proposed alternative. That might be a job aid, a process redesign, a tool change, coaching, or an organisational intervention. Naming this is not a failure of the L&D function. It is exactly the kind of strategic contribution that builds long-term credibility.

Step 5: Recommend the solution

With the analysis in hand, build your recommendation:

• Is training needed? For which specific gap?
• What format is most appropriate — eLearning, in-person, blended, job aid, peer coaching?
• For which specific audience?
• What scope and priority makes sense given available resources?
• What non-training interventions are needed alongside or instead of training?

The most valuable recommendation is sometimes: “we don’t need a course — we need to fix the process.” That positions L&D as a strategic partner, not a course-production function.

Data collection methods

Stakeholder interviews

One-on-one conversations with whoever requested the training, functional managers, and business leaders. The goal is to understand the problem from a business perspective — what outcomes are at stake, what has already been tried, and what success looks like.

Key questions:

• What business outcome do you expect to improve as a result of this?
• How would you know the problem was solved?
• What has already been tried?
• Who does this consistently well right now?

End user interviews

Talking directly with the people who will receive the training. This reveals what managers often cannot see: day-to-day obstacles, what people already know versus what they think they should pretend not to know, what resources they already use informally.

Do not skip this. The gap between what managers say end users do and what end users actually do is almost always informative.

Direct observation

Watching people work. Particularly valuable for procedural tasks, customer-facing work, tool use, or any process with defined steps. What people do and what they say they do are reliably different things — observation is how you find out which is true.

Surveys and questionnaires

Useful for large audiences where interviews are not practical at scale. Surveys identify patterns, allow prioritisation, and enable segmentation by group. Limitation: people tend to report what they think they should be doing, not what they actually do. Use surveys to identify where to dig deeper, not as a primary source of truth.

Existing data analysis

Performance metrics, quality reports, support tickets, error logs, previous evaluation results, course completion data. Hard data complements qualitative perception and catches biases that interviews miss. If performance data exists, use it.

Focus groups

Groups of five to eight people with structured facilitation. Useful for exploring shared perceptions, surfacing tensions, and generating ideas. Limitation: dominant voices can distort the conversation. Facilitate deliberately and create space for quieter participants.

Task analysis

Decomposing a job into its component tasks, subtasks, and steps, then identifying what knowledge and skills each requires. Especially valuable for technical or procedural roles where the work has many distinct components and complexity is easy to underestimate.

A note on participatory approaches: when you need to run the analysis with a group — for example, mapping knowledge gaps across a whole team in a workshop setting — tools like Questiory let you design a structured experience where participants surface what they know, identify where the gaps are, and prioritise development needs together. That kind of structured group process often surfaces information that individual interviews miss, particularly around tacit knowledge and team-level patterns.

How to determine whether training is actually the right answer

There is a quick diagnostic question I use when I need to cut through ambiguity fast:

“If this person’s life depended on doing it correctly right now, could they do it?”

• If no — they probably lack the knowledge or skill. Training can help.
• If yes — they know how, but something else is preventing them from doing it. Training alone will not solve this.

A more systematic tool is the Mager and Pipe framework, which asks a structured sequence:

1. Is there actually a performance problem? If not, there is nothing to solve.
2. Does it matter? If the consequences of the gap are trivial, the investment is hard to justify.
3. Is it a skill or knowledge problem? If yes, training may be appropriate. If no, look for other causes.
4. Did they perform well in the past? If yes, they may need a refresher or updated information rather than a full course.
5. Is the task performed frequently? If not, a job aid at the point of need may be more effective than training.
6. Are there environmental obstacles? If yes, those need to be removed alongside — or instead of — training.

What goes into a needs analysis document

The deliverable of a TNA is a document that makes the case for the recommended solution. It does not need to be long. It needs to be clear, grounded in data, and structured so that stakeholders can follow your reasoning.

Problem context. What is happening, who raised the issue, what business metric is affected.

Audience. Who they are, how many people, what they currently know and can do, what they need to know and do.

Performance gap. Expected performance versus actual performance, with supporting data.

Root cause analysis. Why the gap exists. What proportion is a training problem and what is not.

Recommendation. Proposed solution — format, scope, priority. Including any non-training interventions if they are needed.

Success criteria. How you will measure whether the solution worked. Specific, observable indicators.

Constraints and risks. Timeline, budget, SME availability, LMS capabilities, organisational context or political factors that will affect the project.

A document structured this way protects you and your client. It creates alignment before design begins and gives everyone a shared reference point when questions arise later.

Common mistakes in needs analysis

Accepting the client’s solution without questioning it. “We need a course on X” is a request, not an analysis. Your job is to validate whether that request actually addresses the real problem. Ask why before you ask how.

Confusing “interesting topics” with genuine needs. An audience finding a topic interesting does not mean there is a performance gap that justifies the investment. Curiosity is not a need.

Only talking to the manager. A manager’s view of what the team needs is partial by definition. They see performance from the outside and through their own filters. End users know the real obstacles. Talk to both.

Making the TNA longer than the project warrants. For a short standalone course, two to three days of analysis is typically sufficient. For a complex multi-module programme with a large and varied audience, two to three weeks may be appropriate. Do not create a parallel project. Match the depth of analysis to the scale of what you are building.

Burying uncomfortable findings. If the analysis reveals that training is not the answer, say so. With data, with respect, but clearly. Organisations that build learning programmes on top of misdiagnosed problems pay for them twice — once in production cost, once in unresolved performance issues. Naming this early is a service.

Assuming everyone has the same gap. In large organisations, performance gaps are almost never uniform. A well-designed analysis surfaces differences between segments — by team, geography, tenure, role level — and allows the solution to be targeted accordingly.

Needs analysis in specific contexts

Startups and small companies

There is no dedicated L&D team. Analysis is fast and pragmatic: three to five conversations, a day of observation, a review of whatever onboarding or process documentation exists. The deliverable might be a single page. The rigour is in the thinking, not the length.

Large corporations

More formal: surveys to fifty or more people, analysis of HR and performance management data, focus groups by department, a TNA document with formal stakeholder sign-off. The risk here is that the analysis becomes a project in its own right. Set time boundaries and stick to them.

External consulting

You are arriving without knowledge of the organisation’s culture, terminology, or history. The TNA is also a discovery process — a way to learn the context and build enough trust to ask the hard questions. Plan for a familiarisation phase before you start drawing conclusions.

Compliance training

Here the need is often defined by regulation or legal requirement — the question is not whether the gap exists but how to close it effectively. Even so, analysing what errors actually occur in practice, where the sticking points are, and how people interpret the rules will significantly improve your design. Compliance training built on actual workplace behaviour is more effective than compliance training built on the policy document alone.

Using participatory methods in needs analysis

One of the underused approaches in learning needs analysis is structured group participation — where instead of running interviews one by one, you design an experience where the group itself surfaces the gaps, priorities, and context together.

This works well when:

• The team is the unit of analysis, not individuals
• You want to build buy-in for the resulting learning programme during the analysis itself
• The knowledge gaps are partly tacit and emerge through discussion rather than direct questioning

With a tool like Questiory, you can design a facilitated session where participants respond to structured prompts, share what they already know, vote on what matters most, and collaboratively identify where the real development needs lie. The session generates both data and alignment at the same time — which matters when you will be asking the same group to engage with whatever learning experience follows.

A note on positioning yourself as a performance consultant

The shift from “course designer” to “performance consultant” is the most significant professional evolution available to anyone working in L&D today. It is not a credential or a job title — it is a stance.

A performance consultant does not assume that a training request means training is needed. They ask what outcome the organisation is trying to achieve, investigate what is getting in the way, and recommend the most effective path — whether that is a course, a job aid, a process change, or an honest conversation with a manager about what their team actually needs.

This stance requires something that is professionally uncomfortable at first: the willingness to tell a stakeholder that the course they asked for is not the solution to the problem they have. Done with data and done early, that conversation is what builds the kind of credibility that makes L&D a strategic function rather than a service desk.

Needs analysis is where that stance is enacted or abandoned. Do it seriously — even quickly — and your work will be grounded in something real. Skip it, and you are producing content that may be well-designed but cannot possibly know whether it solves anything.