By Ian Bryant, ZenArray (CEDIA Member)
I recently led a discussion panel about large integration projects, how to manage them, and the pitfalls that accompany them. The panel featured representatives from integration companies that are creating some of the largest home integration systems in the world. We covered a lot of topics, but the conversation almost always came back to two key items:
How can a company document and convey the operation and function of a large and complex integration system in someone’s home? That is where the PDK (Programming Design Kit) or Programming Scope Document come into play.
When an integrator is conducting client interviews or is in the discovery phase with a client, they are asking lots of questions about that customer’s home life, how they use their current technology, how technology could help simplify their daily routines, what areas of their home they use the most, and many other questions. This gives the sales and design team a starting point to suggest what technology could be implemented to help make the client happy about being in their home. Once the technology has been selected and designed, the next step that sometimes gets left out is the fine detail of how the integration system will look, feel, and operate. This system may not be fully customisable and configurable, it may not even be one of our own — it could be the client’s smart phone or tablet. But this must be discussed before the client signs the dotted line agreeing to a design that they will live with for long time.
This is why integrators should create and present a PDK or Programming Scope Document to their client. Whether the project is a million-dollar theatre or a small integrated home, every client should receive this type of document. The document will vary in size depending on the complexity of the system that it is being written for, but it should be utilised in every integration.
As an example, one might think that a small integrated home utilising a smart phone application for each of the subsystems would not need such document, but that is not correct.
Your client does not know how these applications work, look, or feel. Making sure that they understand the capabilities, limitations, and usability of these applications is necessary. Your client may see these and decide that they want to upgrade to a unified control system or they may decide that some of these products are just not giving them the level of control or ease of use they need. This is where the documentation and communication you have with them is key.
On the other end of the spectrum, the larger and more complex home integration systems with unified control systems and customisable user interfaces must also have these documents. Your company may have UI (user interface) layouts that you use for all of your jobs and that have stood the test of time for your clients, and system designs that are easy to operate and cover all bases. However, even if this is the case, it is still important to run through this with your client and document it for them. With the price tag that comes with these larger, more complex systems, also comes a client that feels very passionately about this system and how it looks and operates.
So, what should be in a PDK document? Some of the more important items are:
Why is a PDK document so important?
There are many sample documents out there that can be customised for your application. Some manufacturers have downloadable kits to use or you can create your own. Whatever direction you decide to go, just remember to document everything and keep an open line of communication with your client.