After a few hundred clients or so, even the most stubborn A/V integrator should have gotten the message of repeatability by now. Those early years of uniquely written code with cool trick functionality for each and every individual client were really nothing more than uniquely generated opportunities for the software bug generation, with requisite hours upon hours of on-site time and projected-cost over runs. Those days are clearly gone.
One of the aspects of the Internet age is that all clients are far more educated on the ins and outs of our industry than they ever could have been a few years ago. Sure weve all suffered greatly with the erosion of equipment prices, because clients can take our product recommendations and merely search the net for competitive pricing. But the upside to all of this is standard functionality expectations. We are no longer creating or defining client expectations, but instead we are merely fulfilling their pre-defined expectations on what is to be delivered for the components that they have selected to have installed.
With all clients knowing what to expect, we find ourselves in a different sales environment. The real issue is that most of your competition can do these things just as well as you can. Therefore, the best way to stand out is by demonstrating the proven repeatability of your designs. This repeatability can only occur with well-defined and well-enforced standards and procedures. These policies help define what happens in any client project, from first contact through concept development, design, software implementation, and deployment. Such policies are indeed tedious and time consuming to develop, and even more troublesome and difficult to maintain and keep up to date.
The transition to being a procedures-based company, however, is nothing more than a natural growth pattern that our industry has followed. Silicon Valley-based businesses long ago realized that to consistently and repeatedly put out good, solid product year after year, took well-defined and well-followed procedures. Deploying products in the field took well-documented policies, and error corrections and updates-mandated procedures and practices that had to be obeyed. Next-generation products could only be defined and built when procedures for their definitions and enhancements were in place. So our nicely open-ended, totally unstructured industry has now evolved to where we absolutely need all of the structure and procedural regimentation that real, normal businesses have had for years. What a revelation!
The interesting thing about how we got to this point is that our clients have driven it there as much, if not more, than we have. Most of them are successful businessmen and women who routinely expect defined specifications for systems that are to be delivered and that demand documented performance goals that will be evaluated upon completion of any project. Certainly, it has to be obvious that if two possible A/V integrators present roughly similar proposals, these clients will feel far more confident in the company that has documented procedures, that can show past specifications and that has committed to providing such documents as part of the package.
Such documentation, procedure and specifications writing usually takes some getting used to, and its certainly not something for which just anyone can sit down and generate a viable structure. It will most likely be someone who already has experience at writing such things, perhaps someone out of the hi-tech domain. Such a person can be hired on a temporary or contract basis to generate the needed documents. But once initially generated, a priority must be maintained within the organization to keep them current and adapt them. Otherwise, they will quickly grow stale, become ignored, and therefore useless. That usually means that someone within the organization must be tasked with this responsibility. Maintaining good procedures and policies is now just as important a competitive issue as providing quality work and bug-free software coding.
Carl Easton (firstname.lastname@example.org) is the director of systems engineering at Axiom Design Inc.