The cycle only works because the four weeks are not interchangeable. Each week has a different kind of work — discovery, structure, production, verification — and different kinds of work can overlap without colliding.
Staggered by a week, three or four projects sit in different phases at any moment: one in intake while another is in build and a third is in pilot. The load balances because I am never doing SME discovery for two courses in the same week. When a project slips, it slips into a phase the next project is not occupying.
| Week 1 | Week 2 | Week 3 | Week 4 | |
|---|---|---|---|---|
| Course A | Intake | Architecture | Build | Pilot |
| Course B | — | Intake | Architecture | Build |
| Course C | Pilot | — | Intake | Architecture |
| Update queue | Small content updates absorbed continuously — they need production capacity, not discovery capacity | |||
Equipment specs change, hardware revisions land, a process gets rewritten. The question is never whether it happens — it is how much rework it costs when it does.
- Modular authoring is the insurance. Content built as discrete, independently publishable segments means a spec change touches one module, not a monolith.
- Source material is tracked to the segment that uses it. When a document is superseded, I know within minutes which courses are affected and which are not.
- Change in weeks 1–2 is cheap; in week 4 it is expensive. That is why the prototype goes out in week 2 — to pull disagreement forward into the cheap part of the cycle.
- Not everything needs a course. A revised torque value or a changed sequence is often a job-aid update and a notification, not a rebuild. Choosing the smallest sufficient intervention is what protects the cycle.
I have never held an engineering degree, and it has never been the constraint. What SMEs need is not a peer — it is someone who arrives having read the documentation, asks about the failure modes rather than the features, and gives back something concrete to react to.
The most useful question I ask a technical SME is not “how does this work.” It is “what do people get wrong, and what happens when they do?” That single question produces the performance objective, the scenario, and the assessment in one answer — and it moves the conversation from explaining a system to preventing a failure.