The never ending plight of the control system programmer is to program a system with nothing more than a set of drawings and a best guess at what the system should do.
Why is this such a common occurrence?
Because of the problematic approach of designing the system first, then worrying about what it should do later!
The first question any programmer asks when approaching a project that is already designed is, “How do you want the system work?” In many cases this becomes one of the most difficult questions to resolve, leading to responses like “use your judgment,” “the client is open to suggestions,” or “provide what is typical.”
The end result of these conversations is a solution that is too complex, too simplified, too flexible, too restrictive, or too far out of budget. What the client really needs and wants to pay for is “just right” but that can’t happen if there isn’t a conversation about functionality needs.
This situation happens way too often but it can be avoided if we change the discussion in the beginning. If we shift from conversations that begin with what equipment should be used to conversations about what the system is intended to do, what need we are trying to satisfy, what challenge the system will resolve, and what top functions the user wants, we are better able to produce solutions that deliver what the client needs.
Related: Steve Greenblatt’s Top 10 Takeaways from InfoComm100
The answers to these questions help to shape system functionality and define system operation.
Moreover, conversations early in the project that get to what the user actually needs on the most basic level lead to other conversations about features and custom software solution options.
When we define system functionality and user requirements from the start, system design follows naturally to support the operation. The question, what should the system do, is now removed from the discussion and we avoid delays, misfires, and costly errors at the end of the project.
Allowing functionality to shape system design ensures:
- Proper devices are selected with the necessary number and types of inputs and outputs.
- Ample signal paths are established to support system operation and future needs.
- Feature sets of selected equipment provide proper control to support the defined operation.
- User interface size, resolution, and type comfortably supports necessary functionality.
- Control methods and protocol enable effective integration of all equipment and provide the expected user experience.
Again, this demonstrates how a project and client benefit from involving the AV programmer in the early phases of project discussion. Early AV programmer involvement means well-defined functionality executed efficiently.
For more details on the benefits of connecting with the programmer early, ways to learn from others’ experiences (good and bad), and how to define an effective scope of functionality, we have created a community exclusively for Technology Mangers called TechTalk.
Join us for our inaugural event during InfoComm week on Tuesday June 17 in Las Vegas.
