Updating Courseware When the Product Changes

Technical courseware has a maintenance cost that is rarely budgeted and that grows with the library. Products change, procedures are revised, regulations move, and every one of those events touches an unknown number of courses.

A library built as monolithic courses cannot be maintained economically, and the visible symptom is a network still being taught a superseded procedure.

Why it goes wrong

Nobody owns currency. Courses are commissioned as projects with an end date. After that, there is a library and no process.

No map from product to content. When a procedure changes, nobody can answer which courses referenced it. So either everything is reviewed, which nobody does, or nothing is, which is what happens.

Updates require rebuilding the whole course, because the content is a single package with everything baked in.

Multiplied by language. Every update is as many updates as you have languages. See localisation.

And the record is not versioned. Technicians completed "the course", and nobody can say which revision they saw — which matters when the revision was the one with the corrected procedure.

Designing for change

Decisions made when the library is built, which determine what maintenance costs for a decade.

Modularise by rate of change. Separate the parts that are stable — principles of operation, diagnostic method, safety fundamentals — from the parts that move: specific procedures, torque values, tool references, model-specific content.

Then a torque figure change touches one module rather than six courses.

Reference rather than duplicate. If a safety procedure appears in twelve courses, it should be one module referenced twelve times, not twelve copies. Copies diverge, and the divergence is invisible.

Keep values out of the narrative where you can. Specifications embedded in prose are hard to find and hard to update. A referenced table is a single point of change.

Separate text from graphics, which matters for updates as much as for translation.

And build a content map: which module covers which system, procedure and model. Without it, "what does this change affect" is unanswerable.

The maintenance process

Someone owns currency, named, with time allocated. This is the whole thing — everything else is technique.

A trigger from the product side. Technical bulletins, procedure revisions, campaigns and regulatory changes should reach the training function as events, not be discovered.

A review cycle for content nobody has triggered — annually for stable material, more often for anything model-specific.

Impact assessment on each change: which modules, which courses, which languages, and how urgent.

Urgency tiers. A corrected safety procedure is not the same as an updated part number. Having three tiers with defined response times prevents everything being treated as routine.

And a withdrawal decision. Content covering a procedure that is now wrong should be withdrawn rather than left available while the update is produced. This is the decision most often deferred and it is the one that matters most.

Versioning and the completion record

The part that has consequences beyond tidiness.

Version the content, visibly, so a technician and a dealer can see which revision they have.

Record which version was completed. A completion record against "Course 4412" is much weaker than one against "Course 4412 rev 3".

Decide what a new version means for prior completions. Three positions, and the choice should be deliberate:

Minor revision — prior completions stand.

Substantive revision — prior completions stand but the technician is notified and offered the delta.

Critical revision, such as a corrected safety procedure — prior completions no longer count, and re-completion is required.

Without this decision, every update either invalidates thousands of records or none, and both are wrong.

And produce a delta where you can. Requiring a technician to retake a two-hour course because one procedure changed is how a network learns to ignore update notifications.

Language versions

Track currency per language against the source. A network should be able to see that the Spanish version is at revision 3 while the source is at revision 4.

Decide the policy for a lagging version. Withdraw, or serve with a notice. Serving an outdated procedure without saying so is the default and the worst option.

And prioritise by exposure. The language with the most technicians using the affected procedure goes first.

Retiring content

The other half of maintenance, and it is almost never done.

Content for vehicles no longer in the parc, procedures that no longer exist, tools no longer used.

A library that only grows becomes unnavigable, and technicians searching it find superseded material alongside current material with no way to tell.

Set a retirement review, annually. Withdraw, archive, or confirm.

And check what the network is actually using. Courses with no completions in two years are candidates.

The short version

Modularise by rate of change — stable principles separate from moving procedures and values.

Reference rather than duplicate, because copies diverge invisibly.

Someone owns currency, named, with time. Without that, every technique here is unused.

Version the content and record which version was completed, and decide in advance what a critical revision does to prior completions.

And withdraw content that is now wrong rather than leaving it available while the update is produced.

For open standards that support maintainable web-based courseware, consult W3C standards overview.