A story about who should be in the room when scope gets written.

It was the third walk-around of the day. The corridor ran the length of the first floor, fire doors at both ends, a kink where it joined the stairwell, and one of those flat ceilings you get in a 1980s office where the lights are sitting slightly the wrong height. The operator from the existing security firm was pointing at the ceiling tiles.

“Cameras here, here, and one above the door at the end. Should give us full coverage.”

He’d spent six years watching feeds from buildings like this one. He knew what a useful image looked like when somebody tailgated a fire door. He knew which faces the existing cameras struggled with, and he’d built his own mental map of where the previous install had let them down. When the client looked at who to send to scope the upgrade, he’d been a sound choice.

He wasn’t the right person to spec where the cameras went.

Why the operator wasn’t the right pick

The cameras he’d picked positions for were lensed for a different distance to the one he was looking at. The corridor would clip out at 8 metres; the camera he’d chosen was good for around 4. The cable run he’d assumed available went through a fire compartment we’d be cutting holes in. The first camera’s field of view (FOV, the angle of what a camera actually sees) would lose half a metre every time the fire door opened against the wall, which in that building was almost every five minutes during the day.

None of this is something an operator gets exposed to. They watch the feed. They don’t pull cable. They don’t read FOV diagrams. They don’t argue with a fire officer about compartmentation. Asking them to spec the install is asking somebody fluent in the result to design the system that produces it. It’s not the same skill, and it’s not unkind to say so.

We pushed back. Politely. Got the operator and the building’s operations manager in the same room (the second person had door-flow data we hadn’t seen) and walked the site again. Different cameras, different positions, two added, one dropped. The spec changed in about an hour.

The wider pattern

This isn’t a security-firm problem so much as a wrong-stakeholder problem, and we see versions of it on most projects.

Finance picking the SharePoint structure. The team that lives in the spreadsheets every day doesn’t get asked. Six months later, somebody’s asking why the site map looks like a chart of accounts and where the contracts have gone.

HR specifying a people-count requirement. The brief comes back as “headcount per floor per hour”. Nobody asked whether the existing access-control system already counted that, slightly differently. It did. The reconciliation conversation surfaces nine months in and runs for the rest of the year.

Procurement scoring an internet-supplier RFI. Cost columns front and centre, SLA (service-level agreement, the supplier’s uptime commitment) and throughput in a footnote. The procurement process worked but the network didn’t.

An IT manager spec’ing their own replacement system. Easy to be charitable about who they think the next admin should be, and easy to under-spec for somebody less senior than them. The new admin walks in and the system makes no sense.

In each case the person writing the spec isn’t malicious or careless. They’re the wrong voice for the question.

Three voices for a usable spec

After enough of these, we’ve ended up with a rule of thumb. A spec needs three voices in the room:

  1. The user. Whoever uses the system day-to-day, not “somebody from their team” but the people on it. They know what’s missing, what’s annoying, what the current system fails at. They write the use-case half of the spec.

  2. The system designer. Somebody who knows the cabling, the lensing, the FOV, the licensing model, the failure modes. They translate the use-case into a set of choices the install will land on. They write the implementation half.

  3. The building / data flow voice. Operations, facilities, IT, whoever knows the things that aren’t on the user’s mind and aren’t in the designer’s catalogue. Door behaviour. Existing systems that already measure something similar. Network paths. Fire compartments. Power.

When one of those voices is missing, the spec lands somewhere that looks right on paper and goes wrong somewhere on site.

It’s not always three different people, and it doesn’t always need a formal meeting. On a small project the operations manager might cover voice 3 in two emails. On a bigger one you’ll want a workshop. The discipline is recognising the three voices and making sure they’re all represented before the kit list goes out.

Where this lands with us

We push back early when this pattern shows up. Not because the stakeholder is wrong about what they need (they’re usually right about that) but because a spec needs all three voices before it’s safe to sign off.

That’s our Consulting Services practice. We’ll do the spec work directly if it helps, or sit alongside whoever’s writing it and make sure the third voice is in the room. Either works. What doesn’t work is letting a one-voice spec ship.

A short checklist for next time

Before signing off any spec, whether CCTV, network, SharePoint, people-count, internet supplier or anything else, three quick questions:

  • Who’s the user? Are they in the room? Not their manager, not a representative. Them.
  • Who knows the system? If the use-case is clear but the system-side is hand-wavy, find somebody who can speak to lensing, throughput, licensing, failure modes.
  • Who knows the building? What’s already there that this needs to coexist with? What’s the data already saying? What runs through the wall behind the camera?

If the answer to one of those is “nobody”, stop. Find the voice before the spec goes any further. It’s a much cheaper hour than the rework that follows.

That CCTV install landed cleanly in the end. The kit list was different from the original spec by about four lines. The cost was within £400 of where we started. The corridor coverage actually works.

What changed wasn’t the cameras, but who was in the room.

The cost of a one-voice spec isn’t a line item but the rework four months in, the second mobilisation fee, the security director explaining to the board why coverage doesn’t reach the back stairwell, the install that has to be ripped out before the building insurer signs off the policy. Across the founders’ careers we’ve watched all of that land in real projects. The hour you spend finding the third voice now is the hour that saves you the project later.

Working through a project where you suspect the wrong voices are in the room? Drop us a note at info@jmopartners.co.uk. One of us will read it.

JMO|Partners · Enterprise IT, sized for SMEs.