Setting Up the AV Programmer for Success
An AV system brings in many devices, audio and video signals that must be sent to a lot of destinations. This kind of chaos has to be channeled through a control system — a layout simple enough for any user to handle. All but the most basic AV projects need their own control system. As an AV project manager (PM), I have to facilitate the creation of a successful control system inside the AV project for my customers.
That’s where our heroic programmers come in. Crestron, Extron and AMX have long provided the framework to manage AV devices. This world is expanding with smart home technologies coming in as well; I’m impressed with Control4. A good programmer is gold. I have to put them in a position to do their best work. To do that on a new AV project, I know I have to get a set of answers.
One question: Will the programmer have time to do the work? The installation schedule can’t be confirmed until I know the programming has time to be completed. When I ask the programmer if they have time, they will ask me how much work this job will be. Sure, the pre-sales team will have an estimate. But that’s only a guess. Neither of us will know the real answer until we can see what the job entails. We have to talk with the customer and see what we are working with.
I put a meeting on the calendar. We have to come to that meeting informed. I get the single-line drawings and the BOM to the programmer as soon as I can. Those CAD drawings will give a view of how the signal path will go and the BOM confirms how it has to get there.
Meet Customer Expectations
Every customer has their own ideas about how things should go. A signal path is one thing. Customer expectations are something else altogether. That initial conversation will start to uncover any expectations for layout. We will want to know what kind of controls the customer expects and wants. It helps to have a starting point. The sooner this conversation happens, the better. Get it down, get it confirmed and get the customer’s acceptance on the record.
“Hey PM, we need the source code,” my program readers call. I don’t have it, and I know we can’t really start if we don’t have that code. To meet customer expectations, our needs must be outlined in our statement of work. We need to specify that the source code should be provided. If we get that code, then the cost will be as quoted. But if the source code for the legacy system cannot be found, the programmer has to create a new program to match what was there. That’s a whole different story.
I have to work with the customer to get usable source code for a legacy system. It may become clear that they don’t have the file. The programmer will have to recreate the existing system’s look and layout into the new control system. It takes longer to reverse engineer existing code and put it into the new system.
Most of the time, the existing code can be located. That’s when I am likely to get a message, “Hey, does this system include ‘x’?” That legacy code will have little surprises. Maybe the customer forgot to mention that there are shade controls. Maybe there was a projection screen at one time, but it’s not used anymore (whether it was physically removed or not).
I’ll go back to the customer, saying, “Did you want to include the lighting and shade controls?”
It turns out they do. Whew, good thing we found that out beforehand. Now we can ask the right questions and be prepared. We’re the ones who are supposed to be the experts on these systems. The programmer will use that legacy source code and modify it to include or eliminate features.
Stay Involved in The Project
It’s a small world of AV programmers. Every once in a while, a programmer will be updating code that they themselves created years ago. Other times, the programmer will have to try to get into the mind of an unknown programmer. They have to decipher what that first guy was thinking so they can follow the commands through to the right outcome.
Sometimes the job calls for brand new code. It’s just as important to get the programmer in on those systems as well. The programmer knows what is possible with the system as designed. They can propose the most elegant solution between what the customer wants and what the control system can do. “Wait, that mute button, do you want it to mute the speakers in the room or your mics? What precisely do you need the buttons to say?”
Once the conversation happens, whether it’s new or legacy, the programmer must make a mockup of how the control GUI will look. The PM can get sign-off from the customer that the design is accepted. There might be little back and forth to get it right, but when the PM has the GUI signed off, there is protection against the last-minute changes.
Document the Details
Installation day might mean a customer stakeholder wanders in and has a different opinion about how it should look. That person might insist that something needs to change.
No problem, we can change most things. But it will cause delays and more work. If we clarified and got signoff early on, we can charge for that work and be protected from getting the blame for delays. If we have a document showing the acceptance of the design, the requested change might be dropped. And if it is indeed required, we have a way to charge for the extra work.
Back in the mists of time, it took a full-time AV person to manage an AV system. Now that we have programmers to help us understand how to use these systems, more businesses are willing to install them. We may all owe our careers to what these programmers make possible.
I owe much of this article to my friend and programmer Kiel Lofstrand, certified Crestron/AMX/Extron programmer for ConvergeOne, for contributing to my research in creating this article. Programmers have made this industry grow big enough for us all.