Efficient Lighting Control Systems Management Tips

Efficient Lighting Control Systems Management Tips

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 callbacks and substantial financial loss.

5 Phases of Managing a Lighting Control Project

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 authorized 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 are 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, and deliverables, maintaining accurate documentation, managing change orders and variations to the scope, maintaining continual communications with all parties involved, and taking the lead on minimizing potential delays.

5. Closing – A final list of any outstanding issues is created and completed, as
is customization 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.

Getting to know and communicating with all relevant parties

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.

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.

Defining the scope

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 the scope of work 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.

Programming

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 it 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 homeowner 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 and 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 workflow.

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 who knows their stuff.

On a final note, an important equation you should be aware of is as follows…

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 be presenting this course at the coming CEDIA Expo 2009 in Syndey. Please contact CEDIA for further details about this or any other course.