Systems contractors looking to incorporate lighting control in their portfolio need to do some research. Harry Simidis outlines some of the main points.

After a series of technical articles explaining aspects of lighting control, it may be time to discuss another facet of lighting installation.

Let’s have a look at the management and implementation processes involved in the successful delivery of lighting control systems.

I have seen projects managed magnificently, on completion of which the client’s referrals have led to substantial and profitable ongoing business.

But there have also been projects that should have been managed more effectively – work that resulted in continual call-backs and substantial financial loss.

There are five phases of managing a lighting control project, as summarised below. Although the boundaries may blur for smaller projects, the activities are fairly common.

1. Initiation

The project is authorised by senior management and is started. A scope document is developed, as are needs analyses and budgets. The necessary teams and suppliers are assembled.

2. Planning

Initial team meetings take place. A bill of materials is generated. The project charter and schedule is developed, as is the methodology behind programming and software updates. This is generally where the client is presented with the final proposal outlining precise functionality and deliverables.

3. Execution

Pre-wire (or rough-in) and fit-off occur during this phase. Equipment is ordered, installed and programmed according to the scope and other design documents in the proposal to the client. Proposed integration with other systems occurs, as does testing and commissioning.

4. Controlling

Although occupying a numerical order in this list, this phase runs in conjunction with all the other phases right from the start. Typical activities include tracking project costs, deliverables, maintaining accurate documentation, managing change orders and variations to the scope, maintaining continual communications with all parties involved and taking the lead on minimising potential delays.

5. Closing

A final list of any outstanding issues is created and completed, as is customisation to the client’s needs. On substantial completion, the client is presented with the final documentation and payment of any residual amounts occurs. Preventive maintenance schedules may be proposed to the client. A review should take place to improve efficiency in future projects.

Although each phase warrants its own article, this discussion highlights certain activities typically found in the initiation and planning phases.

The list is a guideline only, as many businesses already have practices and procedures in place. What is discussed here should help them improve their service.

One of the most crucial activities for the initiation and planning phases is gaining an understanding of the businesses or individuals that play a central role in the delivery of the system.

The following list, in order of importance, is a good starting point:
1. Electrical contractor (for businesses that don’t offer this service internally);
2. Lighting designer;
3. Interior designer;
4. Architect;
5. Security systems contractor;
6. Audio visual systems contractor;
7. Builder.

Ensure that business cards are exchanged, enabling open communication. If cards aren’t available, the following details should be shared:
1. Names;
2. Phone and fax numbers (mobile is best, if possible);
3. Email address;
4. Best time and preferred method of contact.

Scope definition does take place during the initiation phase, but it’s largely found in the planning phase. The scope of works will ultimately describe:
• The deliverables;
• Who will be doing the work;
• How this work is to take place.

Effective scope of works documents clearly outline which services will and won’t be provided so there is no confusion. It’s probably a good idea to exchange scope of works documents with the other parties, such as the AV systems contractor, to understand how the systems will relate.

As a general rule, I include a hardware controller schedule, a switch schedule and a network layout as part of any scope document provided to the customer.

The controller schedule clearly identifies the electrical loads that will be controlled by the lighting control system, and whether they will be dimmed or switched.

The switch schedule is probably the most important and defining document, as it has to briefly outline the proposed functionality behind every button. It should be succinct, but detailed enough to give a firm description of what’s being controlled and how.

In addition, the switch schedule should be understood by the customer so they feel part of the design process. Failing to do so may lead to ‘scope creep’ during implementation in the execution phase.

The network layout diagram clearly identifies every lighting control system component, and the way in which it connects to the lighting network to ensure a problem-free fit-off stage.

There are many more documents that would be well placed in the broader scope of works document. However, each must cover a unique aspect of the system rather than repeat what previous documents spell out.

Although Excel spreadsheets are a good and basic way of relaying this information, it is to no avail if the customer cannot understand what is being proposed.

Although programming will be discussed in a future article, some points are relevant in this discussion.

The control regime used throughout the whole system must be consistent. This means switches should all have a familiar layout, even though they need not be precisely the same.

For example, the first button on each switch in each room should control the lights in that room.

The second switch may be a lower setting for that same room, used late at night to avoid glare.

The last button in all the bedrooms may be for controlling lights in the adjacent hall.

In most instances, customers may never have experienced the benefits of living with these systems. They will need a pattern in coming to terms with the possibilities at their fingertips.

Proposing too much functionality too early is dangerous. This may sound like an excuse, but you don’t want to be tangled up trying to deliver what you find personally satisfying, as opposed to what the client needs and wants.

Try to imagine the customer – not yourself – using the system. If the customer requests something seen in another home, make sure you can deliver, and ensure the system can be programmed in the required way.

Another mistake in designing lighting control system functionality is to use a dedicated button for each specific load in a room, say, of more than two lighting groups.

I have seen instances in which others have programmed every button on every switch throughout the home to control one corresponding group of lights. Unfortunately, this seems to be the general understanding that some companies have.

What’s worse is that the client is paying for it – a client who is often left wondering why they chose to go this way at all when they could easily have gone with conventional switches at a much lower cost.

Rooms with more than two groups of lights should be controlled by scenarios or scenes. This way, the home owner doesn’t have to carry a manual around just to turn on the desk lights in the corner of a room.

Taking the use of scenarios one step further, global scenarios are what augment the powerful benefits offered by lighting control systems.

Scenes such as ‘goodbye’, ‘goodnight’, ‘away’ or even ‘panic’ can orchestrate every load, system or device in a unified effort to shut down the home for the night, the day or the week. They also provide a sense of security, and help to justify the expenditure.

I much prefer to program off site then download and adjust on site. Others are much more comfortable with programming on site, as they feel more in control and are able to investigate potential issues immediately.

Whichever way is chosen, some thought should be given to remote programming. This can save much lost time in travel, and it will allow minor issues to be handled quickly, efficiently and with minimal disruption to the customer and work flow.

The testing phase is the single most important activity as far as programming is concerned. Every button on every switch needs to be tested and verified against the stated functionality.

Again, the above points are only a small part of delivering a successful lighting control project. Other activities are just as important, such as the testing and verification handover of the lighting control network by the electrical contractor.

If you are a systems contractor looking to incorporate lighting control in your portfolio, do your research, ask around and find someone that knows their stuff.

Some of the content in this article has been borrowed from the CEDIA course ESP405: The Art of Managing Lighting Control System Projects. The author will present this course at CEDIA Expo 2009 in Sydney. Please contact CEDIA for further details on this or any other course.