Enrollment & Claims Platform Modernization

1 · Purpose and what this plan owns G-03

The RTM records G-03 because training and process-documentation requirements were owned but not documented — named against people in the RAIDD and the resource plan, but with no plan stating what "trained" and "documented" actually mean or when they must be true. An owner without a plan is a name against a risk, not a control. This plan is that control. It defines competency rather than attendance, sets the two deadlines the requirements imply, and ties both to the cutover readiness gate.

2 · Who is affected, and trained to what Role-based

Training is designed by role, not by system module. A member-services representative and a claims adjudicator use the same platform to do entirely different jobs; training each on the whole system wastes both their time and teaches neither the specific competency their role requires at cutover. The affected population is segmented by what changes in their actual work.

Segmenting this way also sizes the training effort honestly: it is not one course delivered to everyone, but four role-specific competencies each assessed against the work that role does at cutover. A group whose work barely changes needs orientation; a group whose core task is re-platformed needs assessed competency. Conflating the two either over-trains the first or under-trains the second.

How each role is trained

Delivery method follows the competency, not convenience. A workflow that must be performed under pressure at cutover is trained by doing it, not by watching it — so the roles whose core task is re-platformed get hands-on practice on the built system, while roles facing a lighter change get proportionally lighter delivery.

Training materials are developed once the platform is built enough to train on the real workflow (see §5), reviewed by the domain process owners so that what is taught is what the domain will actually do, and reused as the reference the process documentation in §4 is built from — one workflow, taught and documented from a single source rather than two diverging ones.

3 · Competency assessment — the TR-008 bar TR-008

Competency is assessed against the job, on the new platform, before cutover. The assessment is not a quiz about the system; it is a demonstration of the work. The design principle is that the assessment mirrors the cutover-day task as closely as possible, because the only competency that matters is the one the person will need on the first Monday.

What counts as evidence of competency

Competency evidence is the completed representative task and its outcome, recorded by role — not a signed attendance sheet and not a self-assessment. The distinction is deliberate: an attendance record answers "was this person trained," which is the wrong question; the outcome of a representative task answers "can this person do the job," which is TR-008's actual bar. The evidence is auditable — a claim adjudicated correctly, a member interaction completed without escalation, a commission calculation that reconciles — so that "staff assessed as competent" at the cutover gate is a claim backed by artifacts rather than an assurance.

Remediation capacity is planned, not improvised. Some proportion of staff will be not-yet-competent at first assessment; that is expected and is why assessment runs with enough lead before the UAT deadline to re-train and re-assess without compressing the schedule. A plan that assumed everyone passes first time would discover its missing remediation capacity exactly when it had no time to add it. The lead time between the built platform (11 May 2027) and the training deadline (10 Aug 2027) exists in part to absorb this.

4 · Process documentation — the TR-009 bar TR-009

TR-009 requires business process documentation to be updated to reflect the new platform before Go-Live — owned by the Change Manager (L. Bergström). This is the half of the change that outlives the training. Training gets a person competent on cutover day; current process documentation is what keeps the next person competent, and the person after that, once the trainers have moved on and the hypercare team has stood down.

• Documentation follows the assessed workflow, not the design. The process docs describe the workflow as it is actually performed and assessed in §3 — not the workflow as originally designed, which the FSD and later change control may have moved. A process document that describes the design rather than the running system is wrong on day one.
• It reflects the I-004 resolution and the date-of-service rule. Where the new platform behaves differently from legacy — the Commission divergence (I-004), date-of-service adjudication (FS-005) — the process documentation states the new behaviour, so that staff following the document produce the correct result rather than the remembered legacy one.
• Current before Go-Live is a hard date. Documentation that lags Go-Live means the platform runs while its own operating manual describes the system it replaced — the exact condition in which staff quietly revert to legacy habits the new platform does not support.

5 · Adoption — competency is necessary, not sufficient OCM

A person can be assessed competent and still not adopt the new platform — reverting under pressure to legacy habits, informal workarounds, or shadow spreadsheets that the new system was meant to retire. Competency is what someone can do; adoption is what they actually do once the trainers leave and the deadline pressure of hypercare sets in. This is the Change Manager's domain (L. Bergström), and it is why organisational-change ownership sits in the same plan as training rather than beside it.

• The legacy system disappears, which is the strongest adoption lever there is. On a mandatory replacement, staff cannot quietly keep using the old platform because it will not exist — but they can invent workarounds that route around the new one. Naming that risk is the first defence against it.
• Process documentation is an adoption control, not just a reference. When the documented workflow is current and correct (§4), following it is easier than inventing a workaround. When it is stale, the workaround wins. That is a second reason TR-009 currency is a hard Go-Live date and not a post-cutover cleanup.
• Hypercare is where adoption is observed. The Cutover Plan's hypercare period is when reversion and workaround behaviour actually surfaces — a Sev-2 pattern of staff unable or unwilling to complete a task the way the platform intends is an adoption signal, and it routes back to targeted re-training rather than to a system change.

6 · Sequencing against the program Timeline

The two deadlines this plan owns are not arbitrary; they are placed where the program can actually use their output.

7 · Roles and sign-off Governance

8 · Traceability — this plan against the RTM G-03 closed

With this plan, the three RTM transition-requirement gaps close together: the Data Conversion Plan owns TR-001–007 (G-01), the Cutover Plan owns TR-006/007 runbook, TR-010, TR-011 and TR-012 (G-02), and this plan owns TR-008 and TR-009 (G-03). Every transition requirement TR-001 through TR-012 now has exactly one owning plan, and the RTM's open gaps are closed against maintained documents rather than against the FSD and Test Strategy by implication.