A composite story about a people-count brief, two existing systems, and the reconciliation conversation that should have happened on day one.

We touched on a version of this in our piece on wrong-stakeholder spec writing, the bit where a brief lands from the function that asked the question, and the system that already half-answers it sits in a different function down the corridor.

The brief was three lines. A hospitality group running about a dozen sites across south London wanted a people-count system for their flagship venue. They needed accurate hourly headcount per floor for capacity reporting and staff scheduling. Off-the-shelf occupancy sensors (PIR or ceiling-mounted cameras that count people moving through a zone), tied into a dashboard, with a monthly report.

We quoted it as a four-week install. Hardware, network drops, dashboard configuration, two weeks of bedding-in. The number we landed on was sensible, the technology was proven, and we started the install.

Nine months in, we were in a meeting we did not see coming.

What looked like the scope

The HR director had set the requirement. She’d been clear about what she needed: a number per floor, per hour, that she could trust for scheduling and for the capacity reports she was filing with the group’s operations board. She’d specified an accuracy band of within 5%, and a reporting cadence. The brief was clean, and the kit list followed easily.

We installed eight occupancy sensors across two floors. We commissioned them. We built the dashboard. The numbers came out within the accuracy band on every test we ran. We trained the operations team on how to read the dashboard and handed it over.

For six months the system ran. The operations team used the numbers. The HR director used the reports. We’d moved on to other work for the same group.

What actually showed up

Month seven, somebody on the finance side started cross-checking the occupancy numbers against the access-control system (the badge-readers on the doors that record who came in, set up four years before our install) for a labour-cost reconciliation. The two systems gave different answers, and not by a few percent but by a meaningful chunk on most days, in the same direction: the access-control system consistently said there were fewer people in the building than the occupancy sensors did.

Both systems had been operating correctly; they were just counting different things.

The access-control system counted unique badge-ins per door per day, with an exit credit if somebody badged out. It treated the building as a single zone and counted heads.

The occupancy sensors counted people moving through a sensor’s field of view, by floor, by hour. They counted movements, not unique people. Somebody walking from the kitchen to the bar and back was two movements. Somebody who visited three floors during a shift was a person at every floor.

Both numbers were correct and neither was wrong; they were measuring different phenomena, and the difference between them wasn’t a calibration issue but a definition issue.

Worse, and this is the bit that still bothers me, nobody had told us the access-control system existed. It hadn’t come up in the brief. Nobody we spoke to in scoping had connected the existing badge data to the new requirement, because the access-control system belonged to facilities and the people-count brief had come from HR. The two departments worked on opposite sides of the same building and didn’t talk about counting.

How we handled it

We sat down with HR, facilities, finance and operations in the same room. It took about an hour. We laid out what each system measured, in plain language, and asked which of the two numbers the group actually wanted to make decisions from.

The honest answer was: a third number that didn’t exist yet. They wanted unique-person counts per floor per hour. The access-control system had unique persons but no floor granularity. The occupancy sensors had floor and hour granularity but counted movements, not persons.

We built a reconciliation layer. The badge-in events from the access-control system became the anchor; they gave us a confident unique-person count per day. The occupancy sensor data became the distribution layer, telling us, of those known persons, where they spent their time and at what hours. The dashboard kept the same look, but the numbers behind it were now two systems triangulated.

The accuracy got better and the reports got more useful. The labour-cost reconciliation that had triggered the whole conversation now closed within a percent.

But it was nine months later than it should have been.

What we’d do differently

The mistake was treating the people-count requirement as a greenfield problem. HR had asked for a system; we’d designed and installed one. We hadn’t asked the question we now ask on every scoping call: “what’s already counting something like this, even if it’s counting it differently?”

That question would have surfaced the access-control system on day one. We’d have built the reconciliation in from the start. The dashboard would have launched with two data sources from the beginning. The numbers would have been right the whole time.

Instead we built a system that was internally consistent and externally orphaned. Six months of decisions got made off numbers that didn’t reconcile to the other system in the same building.

We’ve changed our scoping template since. For any measurement project, whether people-count, asset-tracking, energy monitoring, dwell-time, or anything similar, we now run a “what already measures this?” pass before the kit list goes near a customer. Facilities, security, finance, operations, HR. Five conversations. They take an afternoon. They surface the existing systems that the original requester didn’t think about, because they don’t sit in the original requester’s part of the business.

Practical lessons

A few things worth carrying into any project that involves measuring something:

  • Two systems measuring “the same thing” almost never measure the same thing. Access-control counts badges. Occupancy sensors count movements. Wi-Fi association counts devices. CCTV analytics counts detections. They produce different numbers. Surface the definitional difference before the install, not nine months later.
  • The requester is often blind to the other systems in the same building. HR didn’t know facilities had badge data. Facilities didn’t know HR had asked for headcount. Operations sat between them and assumed they were talking.
  • Run a cross-departmental scope pass before the kit list. Five conversations across the function silos. It’s the cheapest hour of the project and it pays back many times.
  • If two systems exist, the dashboard should reconcile them, not pick one. Reconciliation usually means triangulating both, not picking one.
  • A clean kit list isn’t the same as a clean spec. If you’ve got the right cameras pointed at the right places but you’re answering the wrong question, the install is still wrong.

Where Consulting Services sits

This is the kind of work the Consulting Services practice exists for. Not the install itself (the install was fine) but the upstream scoping pass that surfaces the existing systems and reconciles the definitions before any kit ships. We’ll do that work directly, or we’ll sit alongside the in-house team writing the spec and make sure the question that didn’t get asked, gets asked.

If you’ve got a measurement project in flight, or a capacity report that doesn’t quite tie out to another system in the same building, that’s our Consulting Services practice. We’ll do the upstream scoping pass that reconciles the definitions and surfaces the existing systems before any kit ships. Drop us a note at info@jmopartners.co.uk and we’ll talk it through.

JMO|Partners · Enterprise IT, sized for SMEs.