Configure AV programmer to succeed – rAVe [PUBS]
Ask the right questions
An AV system brings in many devices, audio and video signals that need to be sent to many destinations. This kind of chaos has to be channeled through a control system – a layout simple enough that any user can handle it. All but the most basic audiovisual projects need their own control system. As AV Project Manager (PM), I have to facilitate the creation of an efficient control system inside the AV project for my clients.
This is where our heroic programmers come in. Crestron, Extron and AMX have long provided the framework for managing AV devices. This world is developing with the arrival of smart home technologies; I am impressed with Control4. A good programmer is gold. I have to put them in a position to do their best. To do this on a new AV project, I know I need to get a set of answers.
One question: will the programmer have time to do the job? The installation schedule cannot be confirmed until I know the programming has time to complete. When I ask the programmer if he has time, he will ask me how much work this job will be. Of course, the pre-sales team will have an estimate. But this is only a guess. None of us will know the real answer until we know what the job entails. We have to speak with the client and see what we are working with.
I put a meeting on the calendar. We must come to this meeting informed. I send the single line drawings and the BOM to the programmer as soon as possible. These CAD drawings will give a view of how the signal path will go and the BOM confirms how it should get there.
Meet customer expectations
Each client has their own ideas of how things should be. A signal path is one thing. Customer expectations are quite another thing. This initial conversation will begin to uncover all the layout expectations. We will want to know what type of control the customer expects and wants. It helps to have a starting point. The sooner this conversation takes place, the better. Get it, have it confirmed and get the client’s acceptance on file.
“Hey PM, we need the source code,” readers of my program call. I don’t have it and I know we can’t really get started if we don’t have this code. To meet customer expectations, our needs should be described in our statement of work. We need to specify that the source code should be provided. If we get this code, the cost will be as shown. But if the source code of the legacy system cannot be found, the programmer has to create a new program that matches what was there. It’s a whole different story.
I have to work with the client to get some 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 look and layout of the existing system in the new control system. It takes longer to reverse engineer the existing code and put it into the new system.
Most of the time, existing code can be located. This is when I’m likely to get a message: “Hey, does this system include ‘x’?” This legacy code will have few surprises. Maybe the customer forgot to mention that there are shading controls. Perhaps there was a projection screen at one point, but it is no longer in use (whether or not it was physically removed).
I come back to the customer saying, “Did you want to include the lighting and shading controls?”
It turns out they do. Phew, good thing we found out in advance. Now we can ask the right questions and be ready. We are the ones who are supposed to be the experts on these systems. The programmer will use this legacy source code and modify it to include or remove functionality.
Stay involved in the project
It’s a small world of audiovisual programmers. Every now and then a programmer will update code that he himself 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 this first guy was thinking so they can follow the commands to the right result.
Sometimes the job requires a whole new code. It is equally important to involve the programmer in these systems. The programmer knows what is possible with the system as designed. They can come up with 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 room speakers or your mics?” What exactly do you want the buttons to say? “
Once the conversation has taken place, whether new or inherited, the programmer needs to mock up the look of the control GUI. The PM can get customer approval that the design is accepted. There may be little back and forth to get it right, but when the PM has approved the GUI, there is protection against last minute changes.
Installation day can mean that a customer stakeholder is walking around and having a different opinion on what it should look like. This 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 have clarified and got approval early on, we can charge for this work and be protected from blame for delays. If we have a document indicating acceptance of the design, the requested modification can be abandoned. And if it is indeed necessary, we have a way to charge for the extra work.
In the dawn of time, it took a full-time AV person to run an AV system. Now that we have programmers to help us figure out how to use these systems, more and more companies are ready to install them. We can all owe our careers to what these programmers make possible.
I owe much of this article to my friend and programmer Kiel Lofstrand, Crestron / AMX / Extron Certified Programmer for ConvergeOne, for helping with my research into the creation of this article. Programmers have made this industry grow enough for all of us.