Build a course maintenance schedule you can sustain
Most maintenance plans fail because they treat every lesson equally. A schedule that survives contact with a real week reviews high-risk material often, low-risk material rarely, and reacts to events in between.
TeachCurrent editorial team · Published · 6 min read
Rate each course for staleness risk
Risk is a function of two things: how fast the underlying software changes, and how tightly your lessons depend on its surface. A course full of click-by-click UI walkthroughs against an actively developed product is high risk. A conceptual course with occasional demonstrations is low risk, even on the same product.
- High — step-by-step UI work on a fast-moving product, or a course you actively promote as current.
- Medium — mixed conceptual and practical material, or a stable product with periodic releases.
- Low — concepts, fundamentals, or a course explicitly positioned as teaching a fixed version.
Set review intervals from the rating
Pick intervals you can actually hold. A quarterly cadence you keep beats a monthly one you abandon in week six.
| Risk | Full review | Spot check |
|---|---|---|
| High | Every quarter | Monthly, first module only |
| Medium | Twice a year | Quarterly |
| Low | Yearly | On trigger only |
Spot checks matter more than they look: the first module of a course is where an outdated step does the most damage, because a student who cannot finish lesson two never reaches lesson twenty.
Add trigger-based checks
Calendars miss the events that matter most. Run an off-cycle check when:
- A major release or deprecation notice lands for software you teach.
- Two or more students report the same confusing step.
- You are about to run a launch, promotion or bundle for the course.
- Refund or drop-off reasons mention instructions not matching.
Student reports are the highest-signal trigger available and the most commonly ignored. Two identical questions about the same timestamp is not coincidence.
Triage weekly, in fifteen minutes
Keep one list of open findings. Once a week, sort it and do exactly two things: publish a note for anything blocking, and schedule anything else into the next review pass. The rule that makes this work is that nothing blocking waits for a scheduled review.
Name an owner per course
Shared ownership means no ownership. One named person per course decides update, keep or retire, even on a two-person team. If you work with contractors, they can produce findings, but the decision and the dated reason stay with the owner.
An illustrative calendar
Synthetic example for a publisher with four courses: one high-risk flagship, two medium, one low. Month one — full review of the flagship. Month two — spot check flagship module one, full review of medium course A. Month three — spot check flagship, full review of medium course B. Month four — flagship full review again, low-risk course spot checked only if a trigger fired. Roughly one review week per month, predictable enough to plan around.