×

What is a PDK or Programming Scope Document?


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:

  • Documentation
  • Client communication

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:

  • Descriptions of each subsystem being integrated and how these systems will be operated through the control system
  • Descriptions of each type of user interface in the client’s home
  • How to operate each of the different types of user interfaces in the system
    • Pictures of each page of a UI and what every button does and how to navigate through it
  • The shapes and colours that will be used for the interfaces
    • Keypad engraving fonts and colours
    • Touch panel button shapes, sizes, and colours
    • Active and inactive states and text colours and fonts
  • Images or logos used on the user interfaces
  • Smart phone applications and how to operate them
  • Automated event descriptions and how they function

 

Why is a PDK document so important?

  • Your client will know what to expect when you turn the system over to them
  • They will know exactly how to use the system and will feel that it is “their system” that they helped to create and customise
  • You will have a signed agreement with your client of how the system operates and what systems are going to be controlled
  • It will help you discover any bottlenecks in the systems or possible failure points prior to implementation
  • It can serve as a protection document against scope creep if your client requests additional system operations that weren’t discussed
  • It will serve as a user manual for your company, the client, and any possible future tenants of the space it is installed in

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.

 

ZenArray.net