This is the kind of routine that turns performance management from a monthly reporting exercise into a shared operating rhythm — not by owning every technical fix myself, but by keeping the service question, the workflow and the reporting logic connected.
Problem: During migration, three different referral counts can circulate at once — what the old case system says, what the new action system defaults to, and what the dashboard shows.
What I would do: Facilitate a layered definition chain from ward language through to sign-off, and keep it visible when OPT-C and the dashboard diverge in March 2026.
Who: CMHT service managers, BI lead, performance lead and mandatory reporting owner — agreement in the room, not by email trail.
Artefact: The KPI definitions register with owners and validation rules per measure.
Benefit: Directors and service leads argue about what to do, not what the number means. After six months: The register has named owners and review dates so the next change does not start from scratch.
Problem: When a figure is challenged, teams lose weeks tracing it through systems nobody fully owns.
What I would do: Build and maintain one map from service event to report field, with confidence and owner on every row — and use it in dispute meetings, not just as documentation.
Who: BI analysts, service managers and IM&T when feeds change; I facilitate, I do not pretend to be the only technical expert.
Artefact: Deliverable map plus the interactive filterable view for live investigations.
Benefit: A disputed referral count can be walked through in one meeting. After six months: The map is the handover route for the next feed change or new report.
Problem: Short secondments often produce a burst of activity in months one and two, then a rushed handover in month six.
What I would do: Run the same month-by-month cadence — listen, define, control, prototype, validate, handover — so each month has an expected output, not a vague “migration workstream”.
Who: Directorate lead for rhythm; BI and service leads for step ownership; IM&T programme for cutover milestones.
Artefact: The ten-step playbook and linked deliverables per step.
Benefit: Progress is visible to sponsors before month six. After six months: The playbook becomes the template for the next system change, not a one-off secondment story.
Problem: Figures reach the Board or mandatory returns before anyone has asked whether the definition chain is still intact.
What I would do: Run six repeatable checks (VAL-01–VAL-06) every month and hold publication when they fail — even if the dashboard still refreshes.
Who: BI lead runs checks; performance lead owns the publish decision; service managers confirm team-level reconciliation.
Artefact: Checks and results in the reporting assurance pack.
Benefit: March 2026: executive dashboard withheld when checks fail, rather than a quiet wrong number upstairs. After six months: The check list and SOP sit with BI and performance, not with the secondment post-holder.
Problem: Improvement work evaporates when the person who built it leaves and nobody knows where the files live.
What I would do: Document six artefacts as I go — location, owner, status, sign-off — and review the register monthly with the incoming post-holder or Head of Business & Performance.
Who: Performance lead owns the register; each deliverable has a named operational owner (BI, service manager, etc.).
Artefact: The deliverables register and six worked examples with synthetic data.
Benefit: Handover is a transfer of ownership, not a memory exercise. After six months: The Trust keeps a repeatable set of performance products, not just slide decks.
For explicit Band 8a role mapping against the job description and person specification, see roadmap and role.
