The project management course that became a coffee coaster

The problem

A 200-person UK software company was delivering projects roughly 35% over schedule, illustrative for this piece, but the shape of it is common enough. Its technical leads had never had formal project management training, so eighteen months before I arrived, someone tried to fix that: a classroom, certificate-style course, built around the heavy step-by-step planning documents of a traditional plan-it-all-up-front method.

Completion was poor. The leads who did finish treated the framework as paperwork, filed it, and went straight back to planning informally on their live projects. When I went looking for the workbooks, most were still on a shelf with the shrink-wrap crease showing. One had a ring on the cover from someone's coffee mug. It had been used as a coaster, not a reference.

Nobody had separated "they don't know this" from "they are refusing this," and that gap in the original diagnosis is exactly why the fix failed. Whoever scoped that first course asked one question: what project management skills are missing? They assumed the answer was a knowledge gap and built straight into it. It was not a knowledge gap. These leads ship software on fast, modern agile teams. They already know what a plan is.

The learner and the constraints

The people this landed on were not beginners. They plan every sprint: scoping work, weighing risk, managing a stakeholder who wants something the timeline cannot give. They just do it informally, on a sprint board, in a corridor conversation, never written down. They had already sat through one classroom PM course and quietly rejected it, so whatever I built next could not read as course two. It had to respect that these are competent people who ship real software, not people who need to be told, again, what a project plan is.

The sceptical technical lead was not an edge case here. They were the design brief.

The approach, and why

I did not commission a better classroom course. I built a way to answer that question first, because getting the diagnosis wrong twice was the actual risk.

• Test the diagnosis before the skills gap. Mager and Pipe asked this decades ago: is this a skill someone doesn't have, or a behaviour they're choosing not to show? I ran that as a standalone stage before any conventional training needs analysis, checking the resistance signal itself, the poor completion, the informal planning that carried on regardless, against the explanation nobody had tested the first time.
• Build the comparison as an instrument, not an opinion. I set what the old course had assumed people needed against how these leads already plan, informally: sprint boards, ad hoc risk conversations, undocumented stakeholder calls. The instincts were there. What was missing was a lightweight structure to make those instincts consistent and visible, not the instincts themselves.
• Make the flip a sentence you can point to. Won't-learn was never the finding. Won't-adopt was. I wrote that as one line in the diagnostic, not folded into three paragraphs of hedging, because a reviewer should be able to put a finger on the exact sentence where the conclusion turns.
• Choose the visible framework over the flexible one. I ran this as ADDIE, kept deliberately linear, rather than SAM's faster, iterative build. This case study's whole argument is a sequencing discipline, diagnose, then design, and a reviewer needs to trace that order cleanly rather than infer it from a stack of prototypes.
• Build a one-pager for a sprint, not a classroom. No Gantt chart, no full RACI matrix, no phase-gate document. Three or four prompts in the leads' own language, checked against the moment they'd actually use them: before you commit to this sprint's scope, name the two risks most likely to slip the milestone. A short escalation rule sits at the bottom. Designed to be pinned next to a monitor, not read the week before.
• Let a real plan catch the risk, and let the learner feel it. The scenario puts a lead inside a slipping milestone with a stakeholder pulling the other way. There's a risk a light, honest plan would have caught early. The scenario does not flag it for them. It lets the missed risk play out as a consequence they have to live with and fix, not a red cross telling them they got it wrong.
• Judge the trade-off, not the checklist. Every option the learner can choose costs something: a relationship, a date, a piece of scope, so there is no answer that is obviously right. The rubric separates a response that correctly names the risk and the stakeholders from one that judges which of them actually matters most under these particular constraints and defends that call. That's the top of Bloom's ladder, not the bottom, and it is meant to be hard.
• Measure delivery, not satisfaction. The evaluation runs on Kirkpatrick's four levels with schedule variance, a real delivery metric, as the headline result, and reaction data collected but reported last. Built to WCAG 2.2 AA throughout.

Artefacts

The outcome

The honest position here is that every figure in this piece, including the 35% starting point, is illustrative for a spec scenario, not a measured result from a real company. What is real is the method: I checked whether the diagnosis could have gone the other way before I built a single artefact, and I built the evaluation to prove schedule variance moved, not to prove people enjoyed the session.

What I took from it

Won't-learn and won't-adopt look identical from the outside. Both show up as a course that didn't take. They are not the same failure, and they do not take the same fix. Assume a skills gap and you build a better classroom for people who were never short on skill, and you get exactly what this company got the first time: a shelf of workbooks and a mug ring. The diagnostic on its own is not the interesting artefact. What's interesting is that it had to exist before anything else got built. That's the difference between designing for a sceptical audience and actually listening to what the scepticism was telling you.

Further reading: action mapping for regulated learning, microlearning in the flow of work.