Facilitate live and virtual sessions, build onboarding programs and an LMS course, and prove what your training changed.

Training Delivery & Evaluation

Write the request as it was given (for example, 'new volunteers need training on the booking system').

Write the business or organizational goal behind it and how you would measure it.

Gather data from at least three sources: existing records, a short interview with someone who does the task well, and one person who struggles (or a short survey).

Write the gap as desired versus current performance, with a number if you can.

Apply the test 'could they do it if their life depended on it?' and classify each cause: information, tools, incentives, knowledge, capacity or motives.

For each cause, propose a solution. Mark which ones are training and which are not.

Prioritize the gaps by impact, frequency and feasibility.

Write a one-page summary: goal, data, gaps, causes, recommendations, and how success will be measured.

## 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:

1. Business goal and the problem as reported.
2. Data gathered (sources, sample size).
3. Gaps, stated as desired versus current.
4. Root causes for each gap.
5. Recommendations: training and non-training.
6. 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.


Find the real performance gap and decide whether training, a job aid or a process change will fix it.

Training needs analysis

How to Conduct a Needs Analysis

What is a Training Needs Analysis?

Write the role and what 'fully up to speed' looks like at day 30, as two or three observable milestones.

List what must be ready before day 1 (equipment, accounts, welcome message, buddy).

Make a table with rows for week 1 to week 4 and columns for goals, activities and a milestone check.

Fill week 1 with what the person needs to do first, not general company history.

Add at least one item for each of the four Cs: compliance, clarification, culture and connection.

Add spaced touchpoints: buddy check-ins, a short practice task in week 2, and a 30-day check-in.

List the job aids the new hire will need and who owns each.

Choose two measures to track for every new hire (for example, time to the day-30 milestone and a short survey).

Ask someone who joined recently to review the plan and tell you what they wish they had had.

## Why it matters

New employees decide quickly whether a job is right for them, and they reach full productivity much faster when onboarding is planned instead of improvised. For technical roles, onboarding is often the largest training program a trainer owns: every new hire goes through it, and every gap shows up as slow ramp-up, repeated questions to busy colleagues and early mistakes in production.

## What research says onboarding should do

Talya Bauer and colleagues' research on newcomer adjustment (including a 2007 meta-analysis) found that new hires do better when they gain **role clarity**, **self-efficacy** (confidence they can do the job) and **social acceptance**. In a 2010 SHRM Foundation report, Bauer described four levels of onboarding, the **four Cs**:

| C | Meaning | Incident-response example |
|---|---|---|
| Compliance | Rules, policies, legal and security basics | Access request, security training, data-handling policy |
| Clarification | Understanding the job and expectations | What "good" looks like on a support shift; severity standards; who to escalate to |
| Culture | Norms and values, formal and informal | How the team runs blameless post-incident reviews |
| Connection | Relationships and networks | A buddy, introductions to the on-call leads, team lunch |

Most organizations do compliance well and the other three poorly. Clarification and connection have the biggest effect on adjustment.

## Principles for technical onboarding

- **Sequence by need, not by org chart.** Teach what the person will do in week one first; the history of the company can wait.
- **Space it out.** A two-day orientation followed by silence ignores the spacing effect. Spread learning across the first month with short, scheduled touchpoints.
- **Real work early, safely.** Shadowing, then reverse shadowing (the new hire leads with the buddy watching), then low-risk tasks on their own.
- **A buddy who is not the manager.** Someone to ask "silly" questions. Give buddies a short guide and time to do it.
- **Clear milestones.** The new hire, manager and buddy should all know what is expected by day 5, 15 and 30.
- **Feedback both ways.** Check in, and ask new hires what is confusing, which improves the program for the next person.

## A 30-day onboarding plan: example

For a new support engineer joining the incident-response rotation:

| Week | Goals | Activities | Milestone check |
|---|---|---|---|
| Before day 1 | Ready to start | Laptop and accounts ready; welcome email with first-week schedule and buddy's name | Can log in on day 1 |
| Week 1 | Know the tools and the team | Compliance modules; incident tool workshop (sandbox); meet buddy daily; shadow two shifts | Opens and escalates a practice SEV2 correctly in the sandbox |
| Week 2 | Handle low-severity work | Handles SEV4 tickets with buddy review; severity calibration exercise; meet the escalation teams | 90% correct severity on 20 practice tickets |
| Week 3 | Contribute to live incidents | Reverse shadow on live incidents; writes first post-incident summary (reviewed) | Summary meets the rubric |
| Week 4 | Join the rotation | First shift on the rotation with a named backup; 30-day check-in with manager | Manager and buddy sign off; new hire's feedback collected |

Notice that each week has a performance milestone, not just activities, which connects back to backward design.

## Supporting materials

- A **checklist** for the new hire, the manager and the buddy (each sees their own tasks).
- **Job aids:** the severity matrix, an escalation contact list, a post-incident summary template.
- A **"first-week FAQ"** built from questions previous hires asked.
- Short **videos** for tasks people need to look up later.

## Measuring onboarding

Pick a few indicators and track them for every cohort:

- **Time to proficiency:** days until the new hire meets the 30-day milestone.
- **Quality:** severity accuracy in the first 60 days.
- **Experience:** a short survey at day 30 (role clarity, confidence, feeling welcomed).
- **Retention:** whether new hires are still there at 6 and 12 months (interpret with care; many factors affect it).

## Remote and hybrid onboarding

Connection is the hardest C remotely. Schedule it on purpose: daily buddy calls in week one, virtual coffees with three colleagues, cameras-optional team rituals, and a clear channel for questions. Ship equipment early and test access before day one.

## Common mistakes

- Information overload in the first two days, then nothing.
- No buddy, or a buddy with no time.
- Activities without milestones.
- Treating onboarding as finished after week one.
- Never asking new hires what would have helped.

## Quick recap

- Aim for role clarity, self-efficacy and social acceptance.
- Cover compliance, clarification, culture and connection.
- Spread onboarding over at least 30 days with weekly milestones.
- Use buddies, job aids and early, safe real work; measure every cohort.

## Try it

On the Do tab, design a 30-day onboarding plan for a role you know.


Design a 30-day onboarding plan with milestones that builds clarity, confidence and connection.

Onboarding programs

How to Design The Perfect Onboarding Process

Sketch the course on paper first: three sections, each with one resource and one activity, tied to an objective.

Create the course and add a 'Start here' section with a welcome page stating the goals and schedule.

Add the three sections with their resources (a page, a file or a video link) and activities (a quiz and an assignment).

Build a practice quiz with at least three questions and feedback on every option; allow multiple attempts.

Set completion rules so each activity counts as complete only when submitted or passed, not just viewed.

Add a release condition so section 2 opens only after section 1 is complete (or on a date).

Preview the course as a student (switch role or use a test account) on a computer and on a phone.

Fix anything confusing, then note which reports the LMS offers for completion and quiz results.

## Why it matters

Once you train more than a handful of people, you need a system to enroll them, deliver materials, track who completed what, and report to managers and auditors. That system is usually a **learning management system (LMS)**. Technical trainers are expected to build and maintain courses in one, and to know what the data it collects can and cannot tell them.

## What an LMS does

Core functions:

- **Users and enrollment:** who can see which course, often synced from the HR system or single sign-on; manual, self, or rule-based enrollment ("all new support engineers").
- **Content delivery:** pages, files, videos, quizzes, assignments, and imported e-learning packages.
- **Tracking:** completion, scores, time, attempts.
- **Assessment and grading:** quizzes, assignments with rubrics, a gradebook.
- **Communication:** announcements, forums, reminders.
- **Reporting:** completion rates, overdue training, compliance status.
- **Certificates and recertification:** for compliance training that must be repeated.

Common platforms include **Moodle** (open source, widely used in education and business), **Canvas** (Instructure, common in universities), **Google Classroom** (schools) and many corporate systems. A related category, the **learning experience platform (LXP)**, focuses on recommending and curating content; many products now mix both.

## Standards that connect content and systems

- **SCORM** packages let an LMS launch e-learning and record completion and score.
- **xAPI** and **cmi5** record richer learning activity, including outside the LMS.
- **LTI** (Learning Tools Interoperability, from 1EdTech) lets an LMS launch external tools, such as a coding sandbox, with the learner already signed in.

## Building a course: structure first

Before clicking anything, sketch the structure from your design (objectives, assessments, activities). In most LMSs a course has **sections** (weeks or topics) containing **resources** (things to read or watch) and **activities** (things to do: quizzes, assignments, forums).

For the incident-response onboarding course:

| Section | Resources | Activities |
|---|---|---|
| Start here | Welcome page with goals and schedule; severity matrix (PDF job aid) | Pre-check quiz (5 questions, ungraded) |
| Week 1: Tools | 3-minute videos: open, escalate, close | Sandbox task with a submission (screenshot of the escalated incident) |
| Week 2: Severity | Worked examples | Severity quiz (10 scenarios, feedback on every option); forum: "the ticket that confused me" |
| Week 3: Summaries | Summary template and model example | Assignment graded with the rubric |
| Finish | Checklist | Feedback survey; completion certificate |

## Settings that matter

- **Completion tracking:** define what counts as complete (viewed, submitted, passed with at least 80%). The default "viewed" usually means very little.
- **Restrict access / prerequisites:** release Week 2 only after Week 1 is complete, or after a date, to support pacing and spacing.
- **Quiz settings:** multiple attempts with feedback for practice; question shuffling; feedback shown after each attempt.
- **Groups:** separate cohorts so forums and reports stay manageable.
- **Notifications:** reminders before due dates, not daily spam.

## Accessibility and usability

- Use the LMS's headings and page tools rather than uploading everything as PDFs.
- Caption videos; give files descriptive names ("Severity matrix v3 (PDF, 1 page)").
- Keep navigation consistent from section to section.
- Test the course on a phone and with a keyboard, and view it with a student or test-learner account. Most LMSs have a "switch role to student" or preview mode.

## Data and privacy

LMS data is personal data. Collect what you need, restrict reports to people who need them (often the learner, their manager and the training team), follow your organization's data retention rules and privacy law (such as GDPR in Europe or FERPA for US student records), and do not export learner data to personal spreadsheets or unapproved tools.

## Where to practise for free

- **Moodle** runs public demo sites (sandbox sites that reset regularly) at moodle.org/demo, and is free to install yourself. MoodleCloud offers hosted plans and trials.
- **Canvas** has offered a free-for-teacher account.
- **Google Classroom** works with a personal Google account.

Offers change, so check the current options and avoid entering payment details for practice. Checked on 2026-10-23.

## Common mistakes

- Uploading a slide deck and calling it a course.
- Leaving completion as "viewed".
- Opening everything on day one, so people binge or never start.
- Not previewing as a learner.
- Treating the LMS report as proof of learning (completion is not competence).

## Quick recap

- An LMS handles enrollment, delivery, tracking, assessment and reporting.
- SCORM, xAPI/cmi5 and LTI connect content and tools.
- Design the structure first; set meaningful completion rules and release conditions.
- Preview as a learner, check accessibility and protect learner data.

## Try it

On the Do tab, set up a short course in a free LMS sandbox.


Structure a course in an LMS with meaningful completion rules, release conditions and learner-friendly settings.

Learning management systems

How to Use a Learning Management System (LMS)

What is a course?

Find the real performance gap, design onboarding that ramps people up, and run courses in a learning management system.