Monitoring programmes fail by starting with a procurement and ending with a dashboard nobody reads.
The sequence
One: join what exists. Task events, scans, telematics, order data. No purchase.
Two: fix the data quality problems the join reveals, which is a real project and a prerequisite.
Three: run the elapsed time decomposition and find where work waits.
Four: fix one thing, visibly, and say why you fixed it. Wave timing, break staggering, slotting — all free.
Five: consult on anything involving individual data, before deploying it.
Six: identify specifically what the existing data cannot answer.
Seven: buy for those gaps, which is now a narrow and defensible requirement.
Eight: keep measuring, as a habit rather than a project.
Why this order
The first finding funds and legitimises everything after.
Fixing a process problem first establishes that the programme is about the process, which determines how the workforce reads everything subsequent.
Data quality before analysis, or the findings are confidently wrong.
Buying last produces a system scoped to your gaps rather than to a vendor's product.
Consulting before deploying individual measurement is both an obligation in many places and the design review that improves it.
The first ninety days
Weeks one to three: extract and join. Verify clock agreement. Build the location scheme.
Weeks four to six: data quality. Find the batch scanning, the open tasks, the stale master data. Fix what can be fixed and document the exclusions.
Weeks seven to nine: elapsed time decomposition, queue by stage, demand curve, travel estimate. Take the findings to the floor and verify them.
Weeks ten to twelve: change one thing, re-measure, report.
No hardware, no licence, no consultation required for any of this, because none of it involves individual measurement.
What to avoid early
Buying a platform before knowing the gaps.
Installing positioning as a first project.
Individual dashboards, at any point.
Setting targets before understanding the variation.
A launch, which raises expectations before there is anything to show.
Governance
A named owner with allocated time, permanently.
Sponsorship from operations, not only from technology, because every finding requires an operational decision.
Worker representation in the design, which is a requirement in several jurisdictions and improves the result everywhere.
A standing slot in the operational review rather than a separate forum.
A written purpose limitation, agreed and published.
Knowing whether it worked
Waiting time by stage, trended.
Cycle time percentiles.
Travel per order line.
Exception rate by origin.
Near-miss reporting rate, which should rise.
Data quality measures.
Findings closed, with the change and the re-measurement.
Not: number of sensors installed, dashboards built, or data points collected, which measure the project rather than the operation.
Choosing the first visible fix
The first output sets how everything after it is received.
Free, so it needs no capital case.
Owned by the operation, not by another department.
Visible to the people on the floor, ideally something they have complained about.
Not about individual performance, which would define the programme wrongly at the outset.
Wave timing, break staggering, slotting the top hundred items, or parking positions are the usual candidates.
Attribute it to what people said, which is what converts the programme from surveillance into a tool in the first month.
The purpose limitation, published
A short written statement, agreed before deployment, that constrains the programme.
What is measured and at what granularity.
What it is used for, narrowly.
What it will not be used for, explicitly.
Who can see individual data and under what trigger.
Retention periods.
Where the technical exclusions are.
Published to everyone, not just to representatives, and enforced in the first hard case, which is when it becomes either real or decorative.