Six Months to Trusted Performance

This is a 6 month secondment — what do I hope to achieve in those 6 months, and what would my approach be to ensure I am successful?

Demonstration only: Scenario, Trust (Demo Rivers Health — DRH), systems and data are fictional and for demonstration. Not Dorset HealthCare (RDY) or live Trust reporting.

What I hope to achieve

In six months, I would focus on practical, lasting performance infrastructure: clearer definitions traced from service reality to sign-off, safer reporting during system change, better demand and capacity insight, and a repeatable source-to-report model that helps services turn information into action.

My approach to succeed

My approach would be disciplined, evidence-led and resilient: Fanatic Discipline to keep the work moving, Test and Scale to validate before committing, and Productive Paranoia to protect reporting confidence during change. Not heroics or unfounded optimism.

Fanatic Discipline

Steady, repeatable progress — agreed definitions, validation rhythm and ownership every week.

Supports the plan: KPI register, source-to-report map, playbook and handover deliverables.

Read principle

Test and Scale

Test definitions and prototypes cheaply; promote winners and stop what misleads during migration.

Supports the plan: definition migration tests, demand pack prototype, ideas under test.

Read principle

Productive Paranoia

Prepared vigilance — confidence ratings, fallback routes and publish gates when feeds look fine.

Supports the plan: reporting assurance, reconciliation, withhold from Board when checks fail.

Read principle

All three principles

M1Listen, map, baseline

M2Performance framework

M3Migration controls

M4Prototype outputs

M5Validate, embed

M6Handover, sustain

Evidence for this approach: definition migration worked example (Mar 2026 dashboard vs agreed reconciliation).

Reusable approach for the next change

The same discipline applies to any service or system migration — the artefacts change; the definition-chain discipline does not.

Step	Month	Activity	Artefact
1	M1	Listen — map stakeholders, feeds and reports	Source-to-report map
2	M1–M2	Baseline — document current definitions and volumes	Definition migration
3	M2	Define — facilitate agreed KPI definitions	KPI register
4	M2	Map — build source-to-report lineage	Interactive map
5	M3	Control — maintain reporting assurance pack	Reporting assurance
6	M3	Validate — implement checks before publish	Validation checks
7	M4	Prototype — build local performance packs	Demand/capacity
8	M5	Reconcile — monthly old vs new vs agreed	Reconciliation
9	M5	Embed — apply confidence model before publish	Publish decisions
10	M6	Handover — transfer ownership of the six deliverables	Deliverables register

change_playbook.csv

Handover deliverables — worked examples (DRH)

Six focused artefacts with synthetic data, layered definition chains where relevant, and sign-off blocks for the Legendary Care → PathwayOne migration.

View all deliverables register

KPI definitions register

Layered definitions from service to sign-off.

View

Source-to-report map

Field lineage and report inventory.

View

Reporting assurance during migration

Risks, checks, reconciliation and publish decisions.

View

Demand, capacity, productivity

Weekly trends, team comparison and analysis insights.

View

Senior performance brief

View

Ideas under test

Test and Scale — promoted, parked and dismissed.

View

Ideas I would explore in a real secondment

Beyond the six worked examples, I would test small before scaling — and stop what does not work.

Statistical demand forecasting — only after six months of clean post-migration data (parked in demo; see ideas register)
Direct-report coaching — structured 1:1 performance conversations paired with productivity variance by team
Training needs from productivity gaps — link contacts/WTE and DNA trends to workforce development plans
Pathway redesign signals — caseload mix and wait-clock changes as input to service redesign, not just reporting
SPC on referral counts — control charts to detect definition drift early (parked until OPT-C signed off)

Full ideas under test register · Operating principles

Start with the evidence — definition migration

Centrepiece

Definition migration: Legendary Care → PathwayOne

The risk is not just data migration. It is definition migration. Case-based vs action-based reporting, three tested definitions, and March 2026 reconciliation where the dashboard still refreshes but the measure no longer matches agreed logic.

View worked example

Explore this section

Centrepiece

Definition migration

Case vs action; anchor patient; reconciliation.

View page

Operating principles

Fanatic Discipline, Test and Scale, Productive Paranoia.

View page

Migration scenario

Parallel run vs feed cutover timeline.

View page

Source-to-report stack

Full internal pipeline and lineage.

View page

Evidence and reports

Data manifest, mock national and local products.

View page

Roadmap and role

Six-month journey and Band 8a mapping.

View page

How this fits the rest of the site

Draft reports — useful examples using published RDY aggregate data
Warehouse demo — synthetic DRH technical design strand (CareCall, CareCase urgent care)
This section — Business & Performance operating model during system change, with a fuller internal source-to-report chain

Screenshot guide for presentation (~7 minutes)

#slide-question-achieve — interview question + what I hope to achieve
#slide-approach-roadmap — approach framing, principle cards + six-month roadmap
three-principles.html — operating principles index (or test-and-scale.html for definition-migration link)
#slide-dm-problem — case vs action
#slide-dm-vignette — anchor patient
#slide-dm-reconcile — reconciliation (Productive Paranoia)
#slide-timeline — migration phases
#slide-roadmap-role — roadmap + role table