Connective Project Plan

• Workshop (half day): map CI improvement categories to KPI areas — which categories of CI items should theoretically move which KPIs?
• Add a "KPI relevance" field to the CI register template — single dropdown, mandatory at submission
• Quarterly cross-reference: pull all CI items closed in each KPI category and assess whether the relevant KPI moved in the same period
• Annual CI summary presented to the board alongside the KPI annual review — same meeting, same conversation
• Where a KPI is behind target and no CI items in the relevant category are open: explicitly flag as an improvement gap requiring a new CI item

Process owner: Quality function (lead)
Joint: Strategy (KPI ownership)
Executive sponsor: CSO

Nothing. This is a half-day workshop and a change to an existing Excel template. Can start in week one.

By month 6: every CI item submitted has a KPI area assigned. Quarterly CI-KPI cross-reference is a standing agenda item at the quality review meeting. At least one KPI with no open CI items has been identified and a CI item raised against it.

For the first time, it is possible to ask: "we closed 79 PP&C CI items in the last 12 months — did early-tenure staff exits improve?" If yes, you have evidence that improvement activity works. If no, you have a signal that the CI items are addressing the wrong root causes.

This does not require the CI items to be redesigned. It requires them to be tagged and then reviewed against the outcomes they are supposed to influence. The register becomes an intelligence tool, not just a ticketing system.

LTIFR is at 19.3% — above both target and starting point. How many CI items in the last 24 months addressed WHS root causes? Pull them. Did LTIFR move? The answer tells you whether the current CI approach to WHS is working.

• Define the minimum DSP reporting dataset (one-page brief): incident trends by category and severity; documentation currency rate (% of plans current across participant cohort); restrictive practice incidents; Commission matters status; health monitoring flags; client feedback and complaints summary
• Source each data point from existing systems — Connect, incident reports, CI register, Commission correspondence. Note which data points don't yet exist (these become scoped gaps)
• Stand up a monthly DSP reporting pack — initially manually compiled from existing sources, formatted in Excel or Power BI
• DSP Committee receives reporting pack 5 working days before each meeting
• DSP Committee report appears as a standing item at every board meeting — not by invitation, not combined with the CEO report

Data compilation: Quality + ICT (Power BI)
Reporting pack: GM Safeguarding and Quality
DSP Committee: Chair (board-level)
Executive link: COO (participant safety data originates from Operations)

Requires the DSP Committee Chair to convene a session to agree the minimum dataset. One meeting.

By month 3: monthly DSP reporting pack is being produced and distributed. By month 6: DSP Committee report is a standing board agenda item with data-driven content. By month 12: at least one board decision or policy change is directly traceable to a DSP data finding.

The DSP Committee charter places Customer Voice as its first responsibility domain. Currently Achieve cannot answer the Commission's question "how do you know your services are delivering good outcomes?" because the committee that exists to answer that question has no data. This workstream gives the committee something to look at.

It also resolves the risk register routing problem. The risk register routes through CFO/FRAC, not through the DSP. Once DSP has a data infrastructure, the participant safety risk items can route to the committee that is mandated to govern them.

Some of the data points in the minimum dataset will not yet exist — documentation currency rate, health monitoring flags, participant outcome data. Each missing data point becomes a scoped gap and a CI item. This is the mechanism by which the DSP Committee drives improvement rather than just receiving reports.

• Pilot — mealtime management plans (month 1): SM confirms verbally or via email that each worker rostered to a participant has read and discussed the mealtime management plan before first shift. Outcome recorded in a simple SM checklist (Excel or paper initially)
• Define the full list of plans requiring acknowledgement per participant (support plan, mealtime management plan if applicable, BSP if applicable, medication protocols, emergency management plan)
• Stand up a manual acknowledgement process for all plans: SM-led, recorded against the participant-worker pairing, reviewed monthly
• Specify the Connect configuration required to embed this — acknowledgement field per plan per worker, linked to roster allocation
• Cross-reference training currency (PP&C records) against plan type: if a worker's mealtime management training has lapsed, flag before allocation to a participant with a mealtime plan

Process design: Operations + PP&C (joint)
Site-level implementation: Service Managers
System specification: Connect implementation team (Karen Moore-Evans)
Clinical oversight: Clinical Nurse or QA lead

Pilot can start immediately with a single service — the mealtime management plan process is already live as a priority following the April blitz. No system change needed to begin.

By month 2: every worker rostered with a participant with a mealtime management plan has a recorded acknowledgement on file. By month 4: the process extends to all plan types. By month 6: Connect configuration specification is written and with the implementation team.

This is the control that the mealtime management plan blitz did not include. The blitz confirmed plans were current. It did not confirm that workers had read them. A plan can be current and a worker can be untrained on it simultaneously.

It also changes the nature of the compliance question. "Do you have a mealtime management plan?" becomes "Do you have a current plan AND can you demonstrate that every worker implementing it has been inducted on its content?" The second question is what the Commission's enforcement evolution is moving toward.

Service Managers are the mechanism for this workstream. The monthly SM quality review (Stream D) is where plan acknowledgement completeness is reviewed — these two workstreams reinforce each other.

• Monthly site-level quality review meeting: SM-led, structured agenda (documentation currency, plan acknowledgements, incident pattern, health flags, open CI items for this site). Not an extra meeting — replaces or supplements existing SM check-in with a structured quality lens
• Quarterly SM input session for CI register: SMs identify themes from the last quarter — what kept breaking, what workarounds are in use, what process improvements are needed from the frontline perspective. Output is a CI item batch, not a report
• COO presents a standing operational quality update to the board (via DSP Committee reporting) — currently absent from the board agenda entirely
• Any future diagnostic exercise or scoping work includes SM interviews as a required input, not an optional one
• Escalation pathway defined in writing: SM → RM → Quality → COO for documentation and quality concerns. SM should not have to escalate informally to get a response

Meeting design: Operations (COO)
Monthly site review: Service Managers
Quarterly CI input: RM (facilitates SM session)
Board reporting: COO

Requires COO to commission the design of the monthly review agenda. One conversation to agree scope and structure. First meeting can run within 30 days.

By month 2: monthly site quality review running at all sites. By month 3: first quarterly SM CI input session completed. By month 6: COO has presented to board at least once via DSP Committee reporting. By month 12: a CI item raised from SM input has been actioned and closed.

This is the connection with the highest qualitative value and the lowest technology cost. The people who run services know what breaks. They know what workarounds exist. They know where the process gap is. Currently, that knowledge does not reach the CI register, the KPI review, or the board.

Daniel Kyriacou's message to ME Services — "focus less on refining already functional onboarding processes and more on improving the 10+ year lived experience of clients once in service" — was a different problem framing than any other input in that exercise. That framing has not appeared in any subsequent diagnostic output. This workstream ensures it does.

This is not about adding a new reporting burden to SMs. The monthly quality review replaces the informal, reactive quality checking that SMs are already doing in response to incidents — and gives it a structure that generates organisational intelligence rather than individual responses.

• Weekly SM review (15 min): SM reads last 7 days of shift notes for each participant in their service — not looking for incidents, looking for patterns. Structured questions: any health concerns mentioned more than once? Any meal or behaviour observations that need follow-up? Any plans referenced in notes that are approaching review?
• Monthly site quality review (Stream D agenda item): SM presents a one-paragraph summary of notable observations from the month. Incidents already reviewed individually — this is the pattern layer above the incident layer
• Quarterly cross-site pattern review: RM pulls incident themes and SM observation summaries across their sites. Common patterns become CI items. Unusual patterns become risk flags
• Annual aggregation: Quality team reviews CI items raised from observation patterns across the year — what were the recurrent themes? Do they appear in the KPI set? (Connection back to Stream A)
• Shift note structure adapted to support this: add domain-based observation fields so patterns can be searched, not just read (see managed documentation register)

Weekly review: Service Managers
Monthly pattern: Service Managers (into Stream D meeting)
Quarterly cross-site: Regional Managers
Annual aggregation: Quality function

Requires a structured weekly review template — a one-page set of questions that guides the SM through the shift notes without reading every word. Can be designed in a day and piloted in week two.

By month 3: weekly SM review running at all sites and weekly observations feeding into the monthly site review. By month 6: first quarterly cross-site pattern review completed. By month 6: at least one health or safety concern identified via pattern review that would not have been identified via incident reporting alone.

This is the quality review flag raised in the exec summary about the health monitoring gap. The question "were health indicators present in the weeks before each acute presentation?" can only be answered if someone is reading shift notes proactively. Currently nobody is — review happens when an incident is reported, not when a pattern is forming.

It also addresses the CI register structural limit: the register records individual fixes but cannot find what fixes have in common. The quarterly cross-site pattern review is the human aggregation step that fills this gap before any technology solution is in place.

Stream E → Stream D (SM observations into quality meeting) → Stream A (patterns become CI items linked to KPIs) → Stream B (DSP Committee sees trends, not just incidents) → Stream C (pattern reveals a plan that needs reviewing or a worker who needs retraining). All five streams reinforce each other. This is what a connected quality architecture looks like in practice.