Testing systems ahead of time is critical to a successful deployment.
Photo Courtesy: Peerless-AV
Before investing large sums of money in sprawling AV deployments, a considerable number of enterprises are mandating proof of concept projects (POCs)—and they’re willing to pay for them. For the client, the logic is this: by testing out a system in a controlled environment, chances are the full deployment will be a success. For AV design and integration companies, the opportunity to contribute to a proof of concept strengthens their relationship with the client, which in turn means they’re more likely to be hired for the long haul.
Make no mistake, however: proof of concept projects aren’t like conventional AV deployments. “You can’t go into any kind of proof of concept with the assumption that you’re building something that’s going to work, unlike when you are doing a normal facility design [and] you’re using methods and technology that you’re pretty assured are the right thing, because you’ve done it multiple times,” said Dave Van Hoy, president of Advanced Systems Group, an AV design and integration firm based in Emeryville, CA. Because POCs are usually an exploration of the unknown, he says that it’s important to establish clear goals for the project—and to get them in writing. “Being clear on goals is super-important, [as well as] having them documented, and then having your testing methodologies well-documented.”
Dave Van Hoy, Advanced Systems Group
This isn’t always evident because it requires AV firms to develop testing methodologies for something they may not have done before. Once again, this is why it’s important to establish goals up front, Van Hoy underlined. “In general, the testing methodologies have to roll back to the eventual performance goals,” he said. Hammering out definitions of what is success and what is failure is definitely a challenging part of the process, but a necessary one if the process is to arrive at a conclusion. For example, if the proof of concept proves that the deployment will fail, have all parties agreed to continue iterating until they succeed? Or, at that point does everyone agree to throw in the towel? “If that’s not well defined, you can end up in these situations where you’ve agreed to do these tests and you find yourself iteratively troubleshooting and, quite frankly, not getting paid for it, which is a definite business proposition problem.”
The bulk of proof of concept projects that Advanced Systems Group conducts are for enterprise-level clients, Van Hoy said. He believes these organizations favor this approach largely because of how their budgeting cycles are structured. “By the time they arrive at an approved budget, they have to be ready to execute,” he said. “And so that means having done all the work to prove that whatever it is that they budgeted for and got approval for is, in fact, going to work.” He said this is especially true for large companies where managers’ performance is, in part, measured by how successful (or unsuccessful) they are at meeting budget and execution goals.
Brad Calderwood, Sensory Technologies
Brad Calderwood, design engineer at Sensory Technologies, a system design and integration company headquartered in Indianapolis, IN, noted that it’s wise to alert manufacturers when a proof of concept is in progress so product is available for the eventual deployment. “The worst thing you want is to do a proof of concept, and then you find out that you can’t get the product you picked for the [30 facilities you’re rolling out],” he said. He advises systems integrators to get aligned with vendors early on to iron out any wrinkles in the product procurement chain.
Van Hoy warned that one issue with proof of concept projects is that they are often confused with demonstrations, and that it’s up to AV designers and integrators to educate their clients on which is which. “A demonstration is: we’re going to come and show you this technology, this system—whatever it is. There might be discussion about how it might work for you, but there’s no process for proving that it’s going to work for you,” he clarified. A proof of concept project, on the other hand, is a paid engagement that has defined goals and deliverables attached to it. If a client is requesting a “proof of concept” on a new switcher, for example, the AV firm should do some probing to find out if what they’re really seeking is a demo.
Mary Ann de Lares Norris, Oblong Industries
Mary Ann de Lares Norris is accustomed to proof of concepts in a product development context at collaboration technology developer Oblong Industries. As VP EMEA, she said that Oblong applies discovery-driven growth methodologies—which act as a filter through which to assess concepts—to guide its teams through the process. “We find this to be really useful, because oftentimes we, as a company, get really attached to certain product features or something we want to develop, and this process is really brutal,” she said. “Because when we go through this process and we do discovery in the marketplace with our customers, and we find there’s no traction for this thing that we’re really excited about, we have to kill it. We have to be ruthless.” While AV design and integration firms may not apply all of the practices involved in discovery-driven growth, she counsels them to be ready to throw out what may be great ideas if they don’t serve the goals the project is supposed to achieve.
For Van Hoy, proof of concept projects require that everyone understands the goals and recognizes the value of testing a concept before rolling out a large-scale deployment. He also said that all players involved should recognize that it’s okay if the concept proves to be a failure. “A POC may or may not be successful in terms of the actual concept, but even failure is a success,” he said. “Because that means you’re not going to deploy this thing and fail.”
Carolyn Heinze is a freelance writer/editor.
Paying for Later
Drawing up estimates for any project is a challenge, but what makes pricing for proof of concepts even trickier is that, in many cases, the AV firm involved is breaking new ground—and thus, has less historical information to rely on. Dave Van Hoy, president of Advanced Systems Group, said that in cost discussions with clients, he points out that many of the expenses they’re incurring in the proof of concept won’t reappear during deployment, such as engineering hours. “One of the things that we stress with clients is… you’re paying for that now, but what it’s going to gain you is on execution you’ve already done this work, so you’re not going to pay to do those particular things again,” he said. “Most of the time POCs save them money overall, because they prevent mistakes. Anything that you spend in the POC—whether it’s successful or unsuccessful—is really money that you saved in your deployment.”
