Mission: Control
Jan 10, 2011 12:00 PM,
By Patrick Barron
How to put together an accurate bid for a control system programming contract.
Control system programming is a challenging task that starts before the first line of code is written or the first graphic is drawn on a touchpanel. The first step is to determine the cost for programming. There are multiple factors to consider when figuring out the costs associated with control system programming. The salesperson typically bids all aspects of the job and is usually a nonprogrammer, so good communication is crucial to the accuracy of the initial bid. An accurate quote at the onset of a job helps to ensure success and profitability for everyone. Whether the programming is done inhouse or by an independent programmer, you need to consider the same factors when preparing a bid.
Scope
A bid needs to take into account the scope of work and how it affects programming costs. What functionality is needed of the system is vastly more important for programming than how many pieces of hardware are in the system. Some people attempt to use formulas that assign a certain number of hours for each type of control device in the system. They might assume that an RS-232 device takes two hours to program and an IR device takes 30 minutes to program. That method might be better than throwing a dart at the wall, but it is not particularly accurate. Some equipment may be extremely difficult to control and have complex functionality. A complex piece of equipment such as an audio DSP can have dozens or even hundreds of individual control points to adjust volume, mutes, routing, and presets. Equipment should be evaluated on a case-by-case basis, and the requirements of the system should dictate the time allotted. Bidding a job using a fixed amount for a single piece of complex hardware would cause the quote to be extremely low and not enough time allocated to accomplish the programming needed.
The opposite situation could also happen. Some equipment may be extremely simple to control, and duplicating the same equipment many times could be very easy to accomplish. A system might have 35 projectors and 20 LCD displays, and the only control needed might be to turn each of these displays on and off. This is fairly simple to program compared to writing code for an audio DSP with several hundred volume adjustments. Using the method of a fixed amount per piece of equipment with simple hardware would create an artificially high bid and might be the difference between winning and losing a job. You can’t just tally up the physical number of hardware pieces in a system and come up with the time it will take to write the code. The end result may either overcharge the customer or under-allocate hours to complete the programming.
With the abundance of equipment available with IP control, there have been cases in which equipment has been overlooked completely. This can be easy to do when a person bidding the job looks at a control drawing to determine the equipment in the system. In many cases, the system controller is shown on the control drawing with all of the equipment connected directly to it via RS-232, IR, or relay. Often the network drawing is on a separate page. If you create the bid based solely on the equipment shown on the control drawing, a serious error can occur. Systems might have any number of pieces of equipment controlled using the Ethernet port. There are projectors, DSP processors, lighting systems, digital media players, video processors, and much more that can be controlled over IP. It is crucial not to overlook these when considering the programming. There is another example of when the X-dollars-per-control-port bidding method certainly will not work: Ethernet is just one port. You could easily have dozens of pieces of equipment all controlled from an Ethernet port; if you do not notice this when preparing the bid, there could be a serious error in the final figure.
User Profiles
A significant factor to consider is the end-user and what level of functionality on the control panel is expected. Is the user an executive who wants only the most basic functions to set up a presentation? Is the user a tech guru who wants to have every control possible available on each piece of equipment? Communication is the only way to find out what types of user will be using the system. You should determine from the client who will be using the system and what their expectations are regarding the complexity of the controls. The most well-organized and thought-out system can be useless if it does not have the controls the client needs. Highly complex controls in a system will take a great deal more time to program, and you should determine this in the bidding phase.
If there will be multiple users, the best solution might be to provide different levels of access within the same system. Different ways of providing multiple levels of user access might vary from having a password, biometric scan, or even different panels for each user. Programming for a single basic user is much less time-consuming than creating a completely separate interface and writing code for a variety of different users. Whether this is accomplished by having all of the different user levels on a single control panel or by providing a separate interface, this is information that should be provided before finalizing the programming quote.
Mission: Control
Jan 10, 2011 12:00 PM,
By Patrick Barron
How to put together an accurate bid for a control system programming contract.
A key question to answer would be whether custom graphics are expected or whether the user wants a standard simplified interface to reduce the overall costs. The time to create the user interface is not a trivial part of the process. Having clear expectations of the style and complexity of the user interface is a key component of the overall bid. A cookie-cutter GUI typical of others the integrator has done is very different from a highly complex custom interface created specifically for the project in question. Talk with the programmer to find out what options are available regarding the overall look and style of the interface. If the end-user wants any specific graphics, this should be conveyed during the bid process so the programmer can be aware of this expectation. The time required to create the GUI can be adjusted to factor any customizations that the client might require.
Monitoring
The bid also needs to take into account the type of monitoring and diagnostics that the control system should have. Does the system in question have CrestronRoomView or AMXResource Management Suite (RMS)? Does it have remote login and control capability? This is a very common element that is often overlooked until the project is almost complete. If a project is bid without considering advanced remote monitoring or a specialized computer-based room-management system, the time allocated for programming can easily be depleted before this can be implemented. If remote monitoring using remote desktop, VNC, or some other web-based control is needed, it could factor into the programming time. If the user wants to control the system from an iPhone or iPad, an interface will need to be designed with the limited space requirements in mind. If it is important that advanced remote monitoring and control will not interfere with system operation from the primary control panel, a separate and unique interface might have to be created. You will need to account for this when estimating the time required for the project.
Aim for Accuracy
How does a programmer handle a system with too little information to quote accurately? Many times a request for proposal comes in from a consultant with vague requirements. The integration company could bid high to account for a worst-case scenario and potentially lose the bid. Or the company might decide to bid what a typical system would entail and take a chance of it being much more complicated and lose money on the project. Neither situation is desirable, but every effort should be taken to get the scope and requirements clarified before a final bid is completed. If no answers are available, the programming quote should include what assumptions were made regarding the scope and reserve the ability to edit the quote if necessary.
There are several keys to creating an accurate programming quote. The most important is communication to find out as much information as possible. Determine the exact requirements of the equipment that will be needed on the user interface and don’t simply count the number of pieces of equipment used. Find out who the end-users of the system will be and what technical capabilities the users have along with their expectations. Ask questions to establish if there are different user modes in the same system, as well as any expectations about the graphics in the interface and whether custom graphics must be incorporated. Don’t overlook IP-controlled equipment. Remember to get information on the need for remote diagnostic, monitoring, and web-based control. The control system bid will be a much more accurate if you consider all of these factors. Accurate programming quotes are essential to make the project successful and profitable.
Patrick Barron, owner of Barron Systems, is a 20-year veteran of the AV industry specializing in control system programming and audio and system design. Barron Systems is located outside of Dallas. Patrick has worked on a wide variety of high-profile jobs throughout the U.S. and abroad.
