The Importance of Scope
Anyone who has spent time in the AV industry is familiar with being assigned jobs that have not been adequately explained. Jokes about napkin drawings are plentiful, but sadly they are real. One such example involved a client who drew out a system on a white board, took a picture of it and submitted as their programming definition. The drawing was better than nothing but not sufficient to answer questions about how the system would operate. Since programming is a fancy way of writing an operational instruction set, information needs to be precise to be coded properly.
The reality is that often salespeople and systems engineers simply do not have all the information needed to adequately define programming details when quotes or estimates are requested. To do their job, they gather the information they can and move forward making certain assumptions that they hope are accurate upon gathering the outstanding details later. Additionally, since the rate of an opportunity becoming an active project can be less than 50%, the amount of time spent on each opportunity must be put in perspective. Unfortunately, once a project gets rolling those further details can often fall by the wayside leaving a void that a programmer needs to sort out. Unlike other positions involved in the project, the programmer cannot wave off specifics or implement generalities. They will need to understand all the pieces of the puzzle to produce a favorable result.
In some cases, it is possible to work off a standardized functionality design where a base set of needs and requirements have already been established for a specific client. For projects with new clients where relationships have yet to set a precedent for expectations, even the simplest of systems require more details, drawings, and guidance. People will often say to “do what you usually do” or “it should be obvious how it will work.” Rarely is there ever only one way to approach a system, making it almost never obvious how it should work. To that end, a functional description should always accompany the drawings and equipment list.
The need for details and programming information is not limited to integrated systems. The same concerns apply for module/driver/plugin development. There is usually more functionality in an API than a manufacturer needs to include in a module/driver/plugin, without knowing exactly what should or should not be included can have an implication on costs, development time, and meeting desired needs. Specific requirements or practical purposes can be reasons for expanding or limiting the scope of a module/driver/plugin that may not be obvious to a programmer. As a result, this should be clarified with product managers before beginning driver development.
A system narrative helps the project manager and programmer clearly understand the needs and wants of the client which in turn leads to defining the scope. Eliminating the guess work of what is critical or important to the client will help keep the project focused and on the right track. Once the scope has been agreed upon by all parties and not beforehand, the process of software development can begin in earnest.
Too often, a scope document is thought of as a way of restricting a client from getting what they want and protecting a programmer from having to make changes or adjustments that may not have originally been considered. While there may be some truth to this, a clearly defined scope primarily provides protection for the client to hold others accountable for delivering an agreed upon result.
If a client believes a job is incomplete or not working as it is supposed to be, they can turn to the approved scope as a reference. It also provides a fall back for the programmer if a client asks for substantial changes that were not accounted for when planning the project. While most of the time programmers are inclined to make small changes for the good of a project, referencing the scope helps the client to realize the additional value being providing even if it is being done at no charge. When handled well a solid scope of work should leave everyone feeling satisfied at the end of a project.
At Control Concepts, we have developed a signature tool at the onset of our business in 1997 that has become a staple for every project and client. Our Control Functionality Specification or “Control Spec” is a vehicle to formalize and present our interpretation of the proposed system functionality. Whether for an integrated system, module/driver/plugin development, or custom software application, a Control Spec provides a blueprint for the end product that can be used in three distinct ways – a collaboration mechanism during the design phase, a set requirement during the development phase, and testing criteria during the implementation phase.
Our Control Spec has become the backbone of our project process and has proven to be a great asset to ensuring successful outcomes with clients. A sample Control Functionality Specification can be found in the Resources Section of our website.
Joe Volpe is Control Concepts’ Technical Operations Manager. He is responsible for interfacing with clients and helping our team execute projects in a successful and efficient manner. He is also involved with training, managing and overseeing projects, and technical sales. Connect with him on LinkedIn!
