Project Management

The following is a very brief overview of the project management of SCADA projects. If you wish to discuss any of this in more detail, please email me (see links on this page).

All project management methodologies involve breaking a project down into phases, usually with approval gateways at the end of each phase. A further breakdown into tasks is used to produce a work breakdown structure (WBS).

Typical Project Management Phases of a Typical SCADA project

Identification.

Initiation.

Definition.

Design.

Acquisition.

Project Closeout.

Identification

The identification of need may have arisen out of some other activity eg development of Corporate Strategies, review of plant condition, or from the aftermath of coping with a major incident.

Typically SCADA will be required for some of the following reasons.

To reduce power costs.

To reduce staffing.

To reduce future capital requirements.

To improve level of service.

To avoid environmental incidents.

To comply with regulators requirements.

It may not be possible to run the business without SCADA.

To obtain a competitive edge

To replace an existing aging system

In any event the decision as to whether to proceed with SCADA will often arise directly out of the management philosophy. A progressive management will create a climate in which staff will actively seek ways in which to improve the productivity of the organisation. In other organisations, every such proposal will be treated with sceptism. The key to this is for management to have developed a vision of how they want the organisation to run in the future. If they have this, then it is likely this will encompass automation, SCADA etc in order to become more efficient. The world of the 1990's requires organisations to become leaner and more efficient. It is difficult to imagine these trends reversing in the next few years.

This phase is a crucial one in any SCADA project. It is here the business case for the project is fleshed out to determine initial feasibility. The scope of the project is essentially defined at this point. For example if you do not look at the benefits of use of off peak electricity tariffs to reduce pumping costs, it is unlikely you will include this in the SCADA project at a later date. Go to the top

Initiation

A common mistake at this point is to go into too much technical detail. It is surprising how often detailed I/O listings for example are produced at this stage. The work at this stage should be concentrating on the functional (or user) requirements, and the technological requirements should only be looked at to the point of enabling cost estimates to be produced (and only to within -30 to +50%).

The emphasis should be on ensuring that there is a common understanding within the end users of what functionality the system will provide. If the system is being introduced to improve productivity, then it is important that user management understand how they can use the SCADA system to change work practices.

It is important at this stage that the project team include someone from the end user part of the organisation to begin to build a sense of ownership of the system. This involvement should continue throughout the project so that the system can be handed over on completion to an operator who is committed to using it to its full potential.

Although the work should be concentrating on the functional requirements, it is necessary to keep an eye on the technical capabilities offered by suppliers as "off the shelf" in your industry. Restricting the amount of custom software that the system will require is probably the biggest single action you can take to reduce costs, risks, and minimise the project timeframe.

Some preliminary idea of the contracting strategy will have been developed. eg to use consultants, to use design and construct contracts (recommended) and so on. This can have a substantial impact on costs and in particular a decision to use consultants requires funding to proceed to the next phase.

The decision to use consultants must be taken with care. A consultant may have preconceived ideas as to how the project should be managed. Some decisions such as the use of design and construct contracts may not be in a consultants interests, as they may wish to carry out the design for example. They can normally point to a track record of "success" for their approach. Care must be taken in the selection of the consultant to ensure that you get what you want. Therefore you must be clear as to what your priorities are before selecting the consultant. Do you want to take a low risk approach to your SCADA acquisition to avoid purchasing an expensive boat anchor. If so, then an approach which stipulates extensive testing at all phases of the contract may be best for you. Involvement of consultants in the design gives a second perspective. and so on. Most consultants are comfortable with this approach (low for them too). If however you want a low cost solution, and are comfortable with the technology, then design and construct contracts are for you. Be sure to select a consultant who is familiar with this contracting approach.
Go to the top

Definition.

At this stage the project is starting to get serious. A project team is in place, and organisational and reporting processes are established. The scope is being finalised (which sites, which functions, etc). Firm decisions are being made on contracting strategies such as design and construct, etc.

The work at this stage should still be concentrating on the functional (or user) requirements, and the technological requirements should still only be looked at to the point of enabling cost estimates to be produced )and only to within -15 to +25%). Site audits should normally be conducted at this stage to avoid nasty surprises in the future.

It is important at this stage to firmly identify the benefits of the system, and to develop "benefit realisation plans". These plans will identify exactly how the proposed benefits will be realised ie what changes will be made to existing processes to achieve the intended benefits. This will give management confidence that the investment is going to be worthwhile.

As the project is about to proceed to design, it is important that the contracting strategies are firmed up. The trend is towards increasing use of design and construct contracts. These are highly recommended, and will reduce costs substantially. In the past it has been common to engage a consultant (or to do "inhouse") to do the design, and then tender for a system based on this design. This meant the SCADA supplier was told how the system was to be put together, and in effect he was somewhat absolved of responsibility. If it didn't work, then it was an additional cost for him to fix up someone elses mistakes. Bundling all parts of the system into a single contract (communications, instrumentation, RTU's and SCADA system ) and using a design and construct approach can substantially reduce costs and increase the chance of the project being delivered on time. In effect you are minimising the numbers of interfaces between designer and supplier, between communications and SCADA, etc, and allowing the SCADA supplier to organise the project in the most efficient manner for him.

It is important that if you are going to use design and construct contracts, you still don't do the design. Your contract for example should not mandate the communications design to be used, but should lay down some guidelines eg must be radio, x numbers of RTU's per repeater, reliability required, must have diagnostic facility built in, and so on.

The so-called "go-no go" decision at the completion of this phase is probably the last serious chance that the project can be stopped.

When assessing risks, develop plans to manage these risks. For example if a risk was that the frequencies for the radio system may not be obtained in time, then develop plans to mitigate this risk, eg apply for frequencies early.
Go to the top

Design.

If using a design and construct approach, then this phase normally involves preparing the specification, and developing tender evaluation plans. It is probable that a prequalification phase could proceed at this time to overlap the tender preparation, and the prequalification phases. (Prequalification is used to preselect reputable tenderers who have a proven track record in this field, and should always be undertaken. Prequalification allows the selection of potential suppliers before they have submitted a priced quotation, ie on the basis of their capability and experience. Without prequalification you run risks of having to reject inappropriate tenderers in the tender evaluation, and if your tender documents are not well prepared you can wind up in a difficult position.)

A key decision in the tender documents is the extent of testing specified. In the 1980's contracts routinely specified Factory Acceptance Tests, Commissioning tests, Site Acceptance tests, and so on. This was required because the technology was new, expensive and the separation of design and acquisition meant there was a great deal of customisation. The modern approach is to use design and construct contracts, and pay for performance. A functional test at the end is all that is required from the perspective of the purchaser. If the supplier wants to run factory acceptance tests, then that is his business. I have been told by one supplier that 80% of contracts no longer specify factory tests.
Go to the top

Acquisition

Under design and construct contracts, all the detailed work is carried out by the supplier(s). Preferably one. Resist all suggestions to split the work. eg one contract for the communications network, one for the SCADA. Every time you split the work, you are taking the risks. If the radio system does not perform, are you sure the radio contractor is responsible? If it meets your specification, then you have problems with both contracts.

The key players at this stage are

The supplier's project manager
The contract superintendent
The project manager

The success of the project will depend on all three performing.

In this phase the project will go through a number of phases:

Design (culminating in a design report from the supplier for approval)
Configuration of SCADA master software
Development of custom software
Assembly of RTU's in factory, and testing
Field installation of instrumentation, communications, and RTU's
Commissioning
Site acceptance testing
Customer training

Subsequent to this, the system normally has a defects liability period, and beyond that maintenance must be contracted for.
Go to the top

Project Closeout.

The post implementation review is something that is probably rarely undertaken, but should be a mandatory part of all projects. It is important that an assessment be made of how well the system is meeting the organisations needs as they are now understood. What needs to be done now to remedy these "faults"? Remember as far as the contractor and project team are concerned, these are not faults - the system has been delivered as specified.

If it is likely that your organisation will be undertaking future SCADA projects, then the PIR can be used to document any lessons learnt to avoid repeating the same mistakes.