Training and Support Package¶
Artifact — instantiates Implementation Feasibility Alignment
Supplies learning materials, job aids, support contacts, escalation procedures, and maintenance guidance needed for repeated execution.
A Training and Support Package is the concrete bundle that lets ordinary implementers execute a new design repeatedly without drowning: the learning materials, quick-reference job aids, named support contacts, escalation procedures, and maintenance guidance, assembled and handed over as a single artifact that lives inside the design boundary. It is not a review that judges readiness, a plan that sequences a roll, or an analysis that maps a routine — it is the produced kit itself. Its defining move is that it is built from the specific capability gaps the design creates (what implementers cannot yet do) and carries a fade plan so the support tapers as competence grows, rather than hardening into permanent dependence. It also instruments its own use, so which aids get hammered becomes a signal about where the design confuses people.
Example¶
A county library system is migrating every branch to a new catalog-and-circulation platform, and staff who have used the old system for a decade must run the new one from day one. The Training and Support Package is what makes that survivable. Each branch receives a layered kit: laminated quick-reference cards for the twenty most common actions (check-out, holds, renewals), a searchable how-to wiki for the deep cases, a named super-user on each shift who was trained a week early, an escalation line to vendor support with a stated response window, and a maintenance calendar for the monthly record-cleanup the new system requires.
The package also carries a feedback form and quietly tracks which wiki pages get the most hits. Three weeks in, the "merge duplicate patron records" page dominates the traffic — an adoption signal that the platform's record-merge flow is genuinely confusing, not a training deficit. That reading feeds back to simplify the flow rather than write yet another help page, and the super-user role is scheduled to fade to on-call after month two so the branches don't lean on it forever.
How it works¶
- Derive content from capability gaps. Build the aids from what implementers specifically cannot yet do, not from a generic manual.
- Layer the aids. Provide a fast path (quick-reference), a deep path (docs/wiki), and a live path (super-user, escalation line).
- Define escalation and maintenance. Name who to call, how fast they answer, and the recurring upkeep the design demands.
- Instrument usage. Track which aids are used most as a signal of where the design confuses people.
- Plan the fade. Schedule support to taper as competence grows so it doesn't become permanent dependence.
Tuning parameters¶
- Aid layering / depth — how many tiers from quick-card to deep-doc. More tiers serve more users but cost authoring and upkeep.
- Support staffing model — distributed super-users versus a central help desk. Super-users are close to the work; a central desk is easier to staff and standardize.
- Escalation response window — how fast the live tier answers. Tighter windows reassure users but cost staffing.
- Fade / transfer schedule — how quickly support tapers. Fast fade prevents dependence but risks premature abandonment.
- Usage instrumentation — how much you measure which aids get used, trading a little overhead for a design-quality signal.
When it helps, and when it misleads¶
Its strength is bridging the gap between a design that is feasible on paper and one that ordinary people execute repeatedly under pressure — the support that belongs inside the design boundary, not bolted on after. Built as scaffolding[1], with a fade plan, it lifts competence and then gets out of the way.
Its classic failure is support substitution: piling training and documentation onto a confusing or overloaded design to compensate for it, so heavy help demand is read as a training problem instead of the design evidence it really is. Endless job aids for one task usually mean the task is badly designed. It can also foster permanent dependence when no fade or transfer criteria exist. The discipline that guards it is to treat high support demand as a signal to simplify the design, and to build fade criteria in from the start.
How it implements the components¶
support_scaffold— its core: the training, job aids, escalation, and maintenance layer that makes execution repeatable.capability_requirement— builds the specific skills implementers lack into targeted aids and coaching.adoption_risk_signal— job-aid and help-desk usage patterns flag where the design confuses people.
A support package equips execution but does not sequence the rollout or its rollback triggers (scope_adjustment_rule, workflow_fit) — that is its downstream partner Deployment Plan — nor does it run the design in the field to validate it (operational_validation); it assumes the design has already been judged executable.
Related¶
- Instantiates: Implementation Feasibility Alignment — it supplies the support layer the archetype insists belongs inside the design boundary.
- Consumes: Capacity Mapping supplies the capability gaps the package is built to close.
- Sibling mechanisms: Deployment Plan · Capacity Mapping · Feasibility Study · Workflow Fit Analysis · Governance Readiness Review · Implementation Readiness Review · Operational Pilot · Process Walkthrough
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Training And Support Package is defined in the frozen evidence as: Supplies learning materials, job aids, support contacts, escalation procedures, and maintenance guidance needed for repeated execution. Its operative deployed or enacted form is therefore Representation, Specification & Plan.
Nearest alternative: Interface, Display & Cue — Interface, Display & Cue can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; medium confidence.
Origin Attribution¶
Primary origin: Education & Pedagogy
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: U.S. Department of Defense, Interservice Procedures for Instructional Systems Development defines systematic instructional analysis, sequenced objectives, materials, learner practice, support, evaluation, and revision as an integrated training system. This directly supports education pedagogy as the best-evidenced historical home of the operation—Supplies learning materials, job aids, support contacts, escalation procedures, and maintenance guidance needed for repeated execution.—while the alternates record adjacent lineages rather than mere domains of later use.
Related originating lineages:
- Organizational & Management Science — Organizational design, management, and operational governance supplies a parallel or contributing lineage for the mechanism's defining operation: supplies learning materials, job aids, support contacts, escalation procedures, and maintenance guidance needed for repeated execution.
- Psychology — Experimental, clinical, and behavioral psychology supplies a parallel or contributing lineage for the mechanism's defining operation: supplies learning materials, job aids, support contacts, escalation procedures, and maintenance guidance needed for repeated execution.
Review resolution: The blind reviewers disagree on primary lineage (organizational_management versus education_pedagogy). The defining operation is: Supplies learning materials, job aids, support contacts, escalation procedures, and maintenance guidance needed for repeated execution. The researched U.S. Department of Defense, Interservice Procedures for Instructional Systems Development defines systematic instructional analysis, sequenced objectives, materials, learner practice, support, evaluation, and revision as an integrated training system. That is mechanism-specific evidence for education pedagogy as the historical origin. Organizational management remains represented among the uncapped alternates where it contributes a genuine formative practice, but broad deployment or governance of the operation is not by itself evidence that the mechanism originated there. origin_mode=convergent records lineage; domain_reach=universal separately records later applicability.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
References¶
[1] Wood, D., Bruner, J. S., & Ross, G. "The Role of Tutoring in Problem Solving". Journal of Child Psychology and Psychiatry 17(2), 89–100 (1976). Defines scaffolding as tutor control of elements beyond a learner’s capacity so the learner can complete otherwise unattainable tasks and develop competence. registry ↩