What a Good Programme Looks Like
A description of the end state, assembled from everything that works, as a checklist to measure a plan against.
Reference
Rather than a summary, a description of the arrangement these notes point toward.
The data
One process at a time, with a stated boundary and a validated case identifier.
Extracts incremental and scheduled, from a replica, with alerting on failure and on volume anomaly.
Activity mapping versioned and held outside any tool.
Exclusion rules documented, with the volume they remove reported.
Data quality published on the same page as the findings.
Twenty cases traced by hand and confirmed with the operation.
The identity boundary
Resource field included only where needed.
Aggregated to role or team by default, enforced at extraction rather than by a reporting filter.
Individual-level access separated, logged and justified.
Task mining as occasional scoped studies with volunteers and end dates, not a standing agent.
Raw captures deleted on a stated date, confirmed in writing.
The analysis
Findings ranked by cost, not by how interesting they are.
Variant count never reported as a finding.
Waiting decomposed into capacity, availability, dependency and batching.
Rework traced to its origin rather than its detection point.
Segments declared before testing, with confounders listed.
Every finding validated with the operation before it is reported.
The change
One finding at a time, owned, dated, re-measured from the same query.
Free changes first: decision ownership, upstream validation, availability windows, batch sizes.
Automation considered after the process is worth automating.
Null results reported.
A standing slot in an existing operational review.
The continuous part
Seven measures refreshed weekly, with normal ranges marked.
Three to five compliance rules alerting daily, routed to someone who acts.
Pipeline health alerted on.
Quarterly prune of measures and alerts nobody used.
Annual re-validation that the map still reflects reality.
The ownership
A named owner with allocated time, in process improvement, with a data engineering resource and an agreed extract.
Decisions documented per process: case identifier, boundary, mapping, exclusions, and what was tried and rejected.
Knowledge written down rather than held in one head.
What it produces
Answers in days to questions that previously took weeks of argument.
Changes that are measured rather than assumed, using the same instrument before and after.
Compliance evidence as a by-product.
A workforce that is not being monitored by it, which is why the operation tells you what actually happens.
None of this requires a large platform, and all of it requires an owner and a decision about what the programme is for.
Measuring the programme itself
Six questions, asked annually, that describe whether the arrangement works.
Can the operation answer where cases wait, in days rather than weeks of argument?
Has a finding produced a change, been re-measured and been reported, in the last quarter?
Are the compliance rules alerting and being acted on?
Is the data quality report published with the findings?
Has the map been re-validated with the operation in the last year?
Do findings reach the operation before they reach management?
A no to any names the next piece of work, which is more useful than a maturity score.
What it costs to run
Ongoing, once the first process is built, and smaller than most expect.
A few hours a week per process for the refresh check and the findings work.
One owner with allocated time, which is the real requirement.
A weekly one-page report.
A standing slot in an existing review.
A quarterly prune of measures and alerts.
An annual re-validation.
None of it is large, and all of it is what separates a working programme from a licence nobody uses.
Measuring the function itself
Six questions, asked annually, that describe whether the arrangement works.
Can the organisation answer where cases wait, in hours rather than in a workshop?
Has a finding produced a change, been re-measured and been reported, this quarter?
Does the log refresh without a person?
Are the data quality checks published with every figure?
Has any individual-level analysis happened without a stated purpose?
Do the people who run the process see findings before senior management does?
A no to any of these names the work to do next, which is more useful than a maturity score.
Also in this section