The Onsite Programmer
Jun 7, 2011 11:34 AM, By Patrick Barron
Defining the role of the newest AV team member.
The role of the programmer onsite has become more prominent and important than ever before. Gone are the days of keeping the programmer in the back room secluded and isolated from the end-user. The programmer is a vital part of the overall system integration in the AV industry. The programmer is often asked to interact with the end-user to determine what functionality is needed from a system. At the conclusion of a job, the programmer may be tasked with verifying that everything is working properly. Identifying how the programmer is expected to interact with project team members at a jobsite is crucial.
Working with Customers
The first step is to determine how the programmer should represent himself or herself if they are not employees of the company implementing the system. The integration company should explain its expectations to the programmer in advance, so they can present themselves to the project team properly. Some integrators prefer that all parties involved in a project act as their direct employees. In this instance, the programmer should act the part and blend in as if they are a part of the company. The programmer may even be asked to wear a shirt identifying him or her as part of the integration company.
Before going onsite for the first time in a new job, the programmer should have an in-depth conversation with the project manager about their expectations on how to act on the jobsite. When a programmer is onsite dealing directly with the end-user, there should always be a clear hierarchy of personnel involved in every aspect of the job. There usually is a scope of work that has been previously defined, and this scope will be the guideline for what expectations the operation of the system should have. Deviations from this scope of work should follow the proper channels, and the programmer onsite should know where to direct questions from the end-user. The programmer should answer questions from the end-user cautiously because the he or she may be asking for things that are not in the scope of the bid in hopes that the programmer will go ahead and do it.
When onsite to verify the functionality of a system and attain the final acceptance, it is highly recommended to document the acceptance process while referencing the established scope of work. If everything is in writing, there is less potential for confusion or miscommunication at a later date. Any open items that need to be address should be clearly identified in writing. This will help to prevent any last-minute requests from the client that are not in the scope of work. The project manager should work with the programmer in this process, and all members involved should signoff on the final acceptance document. If the integration company does not provide a sign-off document with an itemized list of expectations, then the programmer should provide this to insure that all parties involved agree that the job is complete. This document serves as a demarcation point as well because any future requests can be treated as a change order with a separate scope of work. The sign-off process is important because it identifies that a job is complete since most payments are made only after the programming is complete.
Understanding the Job
The role of a programmer in the overall job process has also changed greatly in recent years. With the introduction of programmable audio processors, video, and lighting systems, many of the analog systems that used to be handled by video and audio engineers are now being brought into the domain of the control systems programmer. This is so prevalent that many companies and individuals have dropped the “control” moniker from their title and simply call themselves “system programmers.” A programmer now needs to wear many different hats to be able to handle all the aspects of the job. They are asked to understand and perform the tasks of a designer, installer, salesperson, audio engineer, and network specialist while still understanding all aspects of control system programming.
When a programmer is presented with a new project, one of the first tasks is to review the system drawings and formulate a plan for writing the control system. An important part of this process is to review the design to make sure that it actually will work. A control system is able to automate and make certain processes easier to accomplish, but it cannot make a system work that is fundamentally flawed. A modern programmer needs to understand enough about how a system works and how video and audio signals flow from the source to the destination to determine if the design is going to accomplish the desired task. If the system doesn’t work, the customer will not be able to sign off and accept a system even if the control system programming is written perfectly. And at this late stage of the process, it might be extremely difficult to change the design to correct the problem. It is much easier to make corrections in the system design at the beginning before the equipment has been ordered and installed. A wise programmer will want to make sure that a system design is fully functional before accepting work to complete the programming. Many problems can be avoided just by checking that the design of the system is sound before proceeding with each step of the job.
Acceptable Use Policy blog comments powered by Disqus