Consultation is treated as a hurdle before deployment. It is more usefully treated as the design review that catches what the project missed.
Why it produces a better system
Workers know which tasks the analysis has mis-specified, because they do them.
They know where the data will be wrong — the batch scanning, the workaround, the step everyone skips because the process is broken.
They know which measures will be gamed, and how.
They identify the exclusions that should be technical rather than assumed.
A design that survives consultation is more likely to produce accurate data, which is the whole point of the exercise.
What to consult on
What is being measured and at what granularity.
Why, with the specific operational question.
What it will not be used for.
Where the exclusions are.
How long data is retained and who can see it.
How someone challenges a measurement they believe is wrong.
What changes as a result — for staffing, targets and pay, honestly, including where the honest answer is that nothing is decided yet.
Doing it properly
Before the decision is made, not after. Consultation on a completed design is an announcement and is recognised as one.
With representatives where they exist, which in many jurisdictions is a legal requirement rather than a choice.
In the languages the workforce uses.
In work time, which determines whether people attend.
With someone who can actually change the design present.
With a written response to what was raised, including where the answer is no and why.
What to expect to hear
"Will this be used against us." The most common question and it deserves a specific, written, enforced answer.
"The measurement will be wrong because of X," where X is a process reality the project did not know about. This is the most valuable output.
"Why not fix the obvious problem first." Frequently correct, and worth acting on before deploying anything, because it establishes that the programme is about the process.
"What happens if I am slower because of a health condition." A question with legal implications that needs answering before deployment rather than at the first case.
Changing the design as a result
Expect to narrow the scope, and treat that as the process working.
Common changes: moving from individual to team granularity, adding exclusions, shortening retention, removing a measure that would be meaningless, delaying a component until a process problem is fixed.
Publish what changed and why, which is what makes the next consultation productive rather than performative.
Where it is refused or ignored
In jurisdictions where consultation is required, skipping it is a legal exposure and it is the kind that surfaces during a dispute, at the worst moment.
Where it is not required, skipping it still costs. A system deployed without consultation is assumed to be worse than it is, resisted, and gamed.
The cost of consulting is weeks. The cost of not consulting is the accuracy of everything the system produces, which is not recoverable by any amount of engineering.
Responding in writing
What separates consultation from an announcement.
Record everything raised, including what you disagree with.
Respond to each point, specifically.
Say what changed as a result, which should be something.
Say what did not change and why, honestly, including where the reason is cost.
Publish the response to everyone consulted, not only to the representatives.
A consultation with no written response is remembered as a meeting, and the next one gets a smaller turnout.
The health condition question
A question that arrives in every consultation and needs an answer prepared.
"What happens if I am slower because of a health condition or a disability?"
In many jurisdictions, adjustments are a legal requirement, and a uniform target that disadvantages someone with a disability may be unlawful.
Have the answer before the consultation: how adjustments are requested, who decides, and how the measurement treats an adjusted role.
Do not answer it improvisationally, because the answer given in the room becomes the policy.
Design the reporting so an adjusted role is not flagged as underperformance, which is a technical decision made at ingestion.