One of the areas that can really get out of control in any systems integration business is programming. We are in the custom business, but our profit margin depends on our ability to standardize as many aspects of our work as possible, minimizing the hours that we spend on each project. This conflict is no more apparent in any area than it is in control system programming.
Good programming involves creating a control philosophy, combined with sound architecture and planning. The key to good planning is consistency, and the best way to achieve consistency is to standardize as much programming and menu design as possible.
To standardize menus, my company tries to make sure that key buttons, such as volume, mute and lighting scenes are always in the same place on all menu screens. It is tempting to treat each menu as an individual example of our best work, functionally and aesthetically. But it is more important that everyone who uses our control systems feels comfortable in operating them. People will be more confident if they know that the buttons they need will always be in the same place, in any room, on any menu. The downside is that we are not able to maximize every menu in some cases, opting instead to reserve real estate to insure consistency.
Consistency can make the difference between elegant integration and operation of the homes systems and a technology nightmare. We have been asked to evaluate and/or redo a number of residential control systems over the past few years. The most common problem is poor programming design and execution. We find inconsistencies not only in the way similar systems operate in different rooms, but also between how various house systems function. Most amazing is how often there are buttons on touchpanel menus that dont do anything. In some cases, menus are duplicated regardless of whether the systems that they control are exactly the same. We have heard explanations like they put those buttons on because they said we can add that function later.
One way that we standardize our work is by using a library of completely custom menu graphics developed for our Crestron systems. Organized as themes, these graphics are similar to the skins that are interchangeable on some PC programs. Each theme includes custom templates, colors, buttons and menu structures. Our themes allow fully customizable functions, buttons, text and menu flow. If a client wants to modify an existing theme or create an entirely new one, we offer that service at our normal programming rates.
Another advantage of creating custom themes is that our offerings dont look like standard, generic graphics. We have been awarded contracts as a direct result of our clients comparing our touchpanel menus to those by our competitors.
If we started our programming from scratch on every project and billed for 100 percent of the time that we spend doing the programming, our prices would be considerably higher. The only equitable plan is to use our previous work as a base, and then we charge for the time that it takes to perform the project-specific programming. This approach has worked well for us over the years, and our library of graphics, interfaces and modules keeps growing with every job we do.
We recently created a change order for a project after the client decided to change some of his Crestron touchpanels to newer versions. When he noticed that we included an extra 10 hours of programming, he asked if we were charging him for the time that it will take us to get up to speed on a new product. I said that, in effect, he is paying us to get up to speed. We base our prices on the estimated time it will take to do each job, and that each client pays for the required hours for his project. Although he might be paying a little more in this situation, he is benefiting from the little bit extra that our past clients may have paid for their systems. It all works out fairly in the end. He saw the logic in our position and agreed to the change order.
Perhaps the single-most important suggestion that I have regarding programming is the same as I suggest for all contracts: promise little and deliver a lot. That way it is hard not to succeed.
