The scene:
Project manager training, major integration firm.

Dramatis Persona:
A project manager, new to the wonderful world of commercial AV
A veteran of the AV industry

The Dialog:
“I’m worried about this bid we just won. There’s no way we can do all of this.”

“Why, what’s wrong? It looked like pretty standard conference spaces to me. ”

“In the spec, they’re asking for all kinds of tests, measurements, analysis. I don’t even know if we have the tools for half of this!”

“Don’t worry. Nobody ever checks that stuff anyway. The people who wrote it probably don’t even know it’s in there.”

So went one of my first industry discussions on specs and what is often wrong with them.

How did we get to this point, at which the most experienced person in the room counsels ignoring published system specifications and, more importantly, how do we solve it?

It’s time to talk about specs.

At best, a system specification gives clear and complete details on how a system is to function, what equipment it should include, how users should interact with it and how its completion and performance can be verified. At worst, it’s an equipment list and single-line drawing sandwiched between indigestible stacks of boilerplate. I’ve seen too much of the latter in the industry and have been working very hard to produce the former.

There’s an old joke that, in the entire history of the industry, there has been written only one specification, in the history of the industry. Whenever a new project arises, the designer crosses off the old name, pencils in the new one and calls it a day. While an exaggeration, there is an element of truth and even wisdom to this approach; quite a few elements of a properly-created spec do apply to more than one project. Applying these to later projects takes advantage of the valuable development work that went into the first project, increases accuracy and avoids wasting resources on duplicate work. The client gets language that has been fine-tuned and tested, the specifier gets to save hours of work. It works well for everyone, until it doesn’t.

The situation alluded to in the above dialog comes from being too thorough and doing our initial work too well. We try to plan for everything, so a specification (or a standard) included everything. Verifying phantom power, for example, is a standard part of not only many specs but also the AVIXA system performance verification standard. If a project has no microphones this will simply add another “not applicable” item. If too much of a spec, standard or other document isn’t applicable, then it loses credibility in its entirety and creates the impression – perhaps accurately – that the specifier copy/pasted some boilerplate rather than spend time crafting appropriate project documentation. It sends the message alluded to above, that even the team ostensibly writing a spec hasn’t actually read all of it.

What’s a better approach? We can think like programmers and create various “spec modules” each defining certain functionality. Is there to be touchpanel control? Then we’ll need to include a process for GUI development and submittals, touch panel installation and testing. Will there be local voice reinforcement? In that case we will need that phantom power specification, along with loudspeaker coverage, gain before feedback, etc.

Better yet, a modular specification suggests a certain organization that can make a spec easier to read. I’ve written three-part specs with literally dozens of sections, the first half of which simply define terms and subsystems. “Acoustic Echo Cancellation.” “Video Matrix Switching.” “Wired Microphone System.” “Wireless Microphone System.” Once all of your modules are defined with clear, precise language room descriptions are simple. Now your room descriptions will have phrases like this…

• Include 65” Flat panel display per Section D.1
• Include video sources as follows:
• Wireless content sharing per Section S.1
• Video Input plate per section S.3
• Include Video Extension with auto-switching V.2

…where sections D, S and V define display devices, source devices and video transport respectively. Not only do you have an easy way to include the parts you need – and only the parts you need – you’ve also accomplished something else: Specific technology functionality is isolated from room descriptions. That means that a change in an equipment spec – say from FHD to UHD resolution – only needs to be made once and will propagate through the document.

That, of course, is only one approach. What is most important is the same as with any exercise in writing: Do it mindfully, think about you’re your audience will be and include only what they need.