By Ann Brigida
A while back, I was chatting with a bunch of AV experts from every corner of the industry about a hot topic: project documentation. We were working on an ANSI standard for verifying the performance of an AV system. The basis of that standard was documentation. In other words, in order to accurately verify performance, you had to know what the system was supposed to deliver in the first place. You would base your performance verification on the system documentation that all involved parties agreed on.
But each time we entered this conversation — about accountability based on promised delivery — we’d also have a long conversation about workarounds, necessitated by this simple question: What if there was no documentation? The group wanted to provide some guidance for verifying a system when no project documentation existed. They mentioned it every time we talked about the structure of the standard and what we needed to define.
I was stumped. Why did they insist on negating their own requirements, which were to align verification of a system with its promised outcome, by adding a “get out of jail free” caveat that would effectively render useless the rules they were about to write? And it made me wonder: Is it ever okay for a project to be undertaken with no documentation? And if it is, how do you verify the performance of that AV system? What would you be measuring against?
So at our next standard development meeting, I asked this group of knowledgeable, highly-respected, experienced AV gurus a few questions. I wasn’t trying to be difficult; I just needed to understand:
Me: So, can you tell me, honestly, how many AV projects don’t have any project documentation?
Them: Hmmm. A lot. Say, 60 percent.
Me: Everyone agrees?
Them: Yup, that sounds about right.
There was some conversation about whether an equipment list alone qualified as “project documentation.” They decided that it didn’t.
Me: And of those projects with no project documentation — out of the 60 percent — how often is it okay not to have any documentation?
Them: Never. It is never okay to have a project without documentation.
And they were unanimous on this point. They all agreed that project documentation is necessary 100 percent of the time, yet they also agreed that 60 percent of the time, there wasn’t any.
There’s a standing joke in AV about sketching out a system design on a napkin and then using it as the installation plan. It’s just a joke. Really.
But it’s no joke that too many systems are put together without proper planning or consideration for the way they’ll be used, which leads to all kinds of mistrust and misunderstanding. The AV practitioner is often left with two equally unacceptable choices: save a business relationship and lose a bunch of money or quit now and lose a client. And it doesn’t have to be this way.
InfoComm is in the process of creating a standard that lays out minimum AV documentation requirements. In coming posts, I’ll explore some of the issues around project documentation and other standards-related topics. But I ask you now, as I asked my esteemed colleagues: What do you expect from AV documentation? Is there a Top 5 list of documents you’d like to see for every AV project you work on? Share your thoughts, and together we’ll raise the bar for our entire industry.
This blog was reprinted with permission from InfoComm International and originally appeared here.