Ld Success Case Study

---
name: ld-success-case-study
description: Runs a Success Case Study with a short survey on where the training was used and where it stalled, an interview guide for volunteers, anonymous case write-ups with evidence, and a barrier list across cases. Use for "run ld-success-case-study", "success case method", "evidence the training was used", "training impact interviews", "stories of use on the job", "why did the training not stick for some teams", "what got in the way after training", "show impact without ROI", part of the AI for L&D and Corporate Training Pack by Polar Bear.
---

# Success Case Study

## When To Use
You need evidence of use on the job, not more survey scores: the sponsor asks "did anyone actually do anything with it?" and the forms cannot say. Use this some weeks after the programme to answer one question: where was the training used, what did it produce, and what stopped it where it stalled?

## When Not To Use
If the programme ended days ago, it is too soon for use to show; run Training Evaluation Form now and come back later. If the budget holder needs a money figure, run Training ROI Estimate; cases show how it was used, they do not add up to a return.

## Inputs
- The programme's critical behaviours or objectives, from your Kirkpatrick Evaluation Plan if you have one
- The participant list, only to send the survey; it is not kept with the answers
- How long ago the programme ran, and how many interviews you have time for
If you have none of this, I start from the programme title and what it was meant to change, and mark the output as a first draft.

## Approach
The Success Case Method, from Brinkerhoff's 2005 paper and described in Coryn and colleagues' 2009 review, finds the few places where a programme worked well and the few where it did not, then studies them closely. The value is in the contrast: what the successful uses had that the stalled ones lacked, which is usually the work environment, not the person. This version studies uses of the training, not people, and every case is voluntary and anonymous. The failure it prevents: a glossy testimonial from one enthusiast that the sponsor reads as proof, while the barrier that stopped everyone else goes unseen.

## Workflow
1. Ask three questions: which behaviours should people be using by now, how many interviews can you run, and who must never see raw answers (usually managers)?
2. Write a short survey to all participants, anonymous by default: where have you used this, what happened, what got in the way. Three to five items, with a closing question asking whether they would volunteer for a confidential interview.
3. Pick cases from volunteers only: a few uses that clearly worked and a few that clearly stalled, chosen by the survey answer about use, never by who the person is or how they perform.
4. Before each interview, get consent in writing: what the interview is for, that the write-up is anonymous, that they can stop or withdraw.
5. Interview guide, same order every time: what did you do, what result followed, what evidence shows it, what helped, what blocked. Ask for the evidence ("what could someone see?"), not only the story.
6. Write each case anonymously: strip names, team, location and any detail that lets a manager work out who it is. If a case cannot be anonymised, leave it out.
7. Build the barrier list across cases: what blocked use, how often it appeared, who could remove it. Close with the limits: the sample is small and chosen, and the cases do not generalise.

## Output Format
```markdown
# Success Case Study
Programme: [name] | Ran: [date] | Survey responses: [count] | Interviews: [count], all voluntary with consent
## Survey
1. Where have you used [behaviour] since the programme? [options]
2. What happened as a result? [open]
3. What got in the way? [open]
4. Would you volunteer for a confidential interview? [yes, contact route kept apart from answers]
## Cases of use
| Case | Worked or stalled | What was done | Result and evidence | What helped | What blocked |
|---|---|---|---|---|---|
| A (anonymous) | [worked] | [use] | [result, evidence] | [driver] | [barrier] |
## Barrier list
| Barrier | Cases it appeared in | Who could remove it | Suggested fix |
|---|---|---|---|
## Limits
- Small, chosen sample; cases show what is possible, not how common it is
## Decision
[Sponsor name] decides by [date] which barriers to remove and who owns each fix.
```

## Done When
- Every interviewee volunteered and gave consent before the interview
- No case contains a name, team, location or detail that identifies someone
- Each case cites evidence of use, not only the interviewee's opinion
- The barrier list names an owner who could remove each barrier, and the limits are written in

## Quality Bar
- Choose cases by the use described, never by the person's performance or reputation
- Stalled cases matter as much as successes; most of the learning is there
- Nothing goes to a manager that lets them identify a case
- Never turn a case into a quote or statistic the sponsor can present as typical
- Cases describe uses of the training, never verdicts on people; every case is anonymous and voluntary

## Next
Run ld-training-roi (Training ROI Estimate) when a money figure is asked for.

## About the makers

This pack is made by Polar Bear, a consultancy built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).