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.
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.
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.
Acceptable Use Policy blog comments powered by Disqus