I’m sure we’ve all been there: Attacking the same problem for hours upon hours. Calling Tech Support and loading new firmware released an hour after your call (for some strange reason). Blowing through owed favors from colleagues you work with. Meeting new “friends” on the internet with some pear-shaped method to fix the problem, like sacrificing a vegan-fed chicken precisely at 7:06 PM on the 13th floor of the building. (“Bro…it works…trust me!”)
How do you know when the solution is to change the design, either with new products, new system requirements or, worst case, with a new contractor?
Be sure you understand the product and the AV principles involved.
I can’t tell you how many times a manufacturer’s device has been horrifically insulted, only to find out it was a configuration issue. (“Oh…is that how echo-cancelling works?”)
Be sure you have reduced the system down to its simplest form, one which has a greater than 90% chance of working, before saying it can’t work.
Many troubleshooting trips down the rabbit hole have been successfully ended with trying a system with one mic at a time, or one video source at a time, or one control system command at a time. Boiling large, complex systems down to empirical subsystems make uncovering problems much easier.
Be sure you have exhausted Tech Support’s…support. And be sure you have been totally honest with them.
We give Tech Support a lot of lip, but they have the toughest job ever. More often than not, they are trying to diagnose a problem blind, over a poor cell phone connection, with nebulous descriptions, from people who might have no business configuring these complicated systems. Not only that, but they have no way of knowing if you are actually doing what they are telling you to do, nor if you are implementing it properly. Who in the room has lied to Tech Support? Raise your hand. You know you’ve done it.
Don’t be afraid to call it, but respect the decision.
While it is true that sometimes you have to take the system out back and put it down, it always comes at a price. You risk making some people on the team lose face (the designer, the engineers, the manufacturer and, most importantly, the client for delaying the project and incurring more cost). You risk someone else coming in and fixing the problem you said was impossible to solve. However, you also don’t want to sit in front of a screen for days doing nothing productive, blowing through the meager profits of the project. Sometimes, for many reasons, systems cannot perform as intended.
And that’s where the AV9000 Standard comes in to play. It lays out a plan to catch these “challenges” as early in the process as possible. There’s a design review, a shop staging and ultimately a commissioning. It also requires test equipment to make troubleshooting at these milestones measureable and meaningful. The idea being that the closer to the design stage you catch issues, the easier it is to remedy the problem quickly and quietly. That is also the difference between quality control (check at the end…when it could be too late) and quality assurance (checking the system several times at key milestones along the way).
What’s your process for “calling it”? Who on your team can declare a system problem, in its current state, inoperable?