West Australians or visitors - visit the Margaret River wine region and rent a fabulous beach house in Dunsborough as a base.
Adelaide Rd, Dunsborough
Geographe Bay Rd, Dunsborough - pure luxury
Optimised for 800x600
These pages have the
An indexed archive of the SCADA mailing list
Please provide feedback if you think the production of the full version of this archive is worthwhile.
SCADA project management
Submit new link
or update existing one
Advertise on this site
SCADA Search engines
-Search individual sites
Ian Wiese's Home Page
Submit new link
or update existing one
SCADA Mailing list
Advertise on this site
An expert is a person who
avoids small errors while
sweeping on to the
grand fallacy. "
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).
Prepare Preliminary estimate. Costs to within (-50+100%)
Obtain approval for funds or resources to proceed to the next phase. This phases is normally informal, and does not require a lot of resources.
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.
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
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.
InitiationValidate project need.
Establish concepts and scope.
Establish Summary Work Breakdown Structure.
Conceptual estimate (-30 to +50%
At this stage some small amount of funding has been approved to undertake the preliminary investigations, and prepare a preliminary project management plan. It will be necessary to firm up on the scope, identify the main technologies to be used, and gain agreement and approval of the potential users of the system. Sufficient work needs to be done to enable a cost estimate to be prepared that is accurate to within -30 to +50%. Similarly sufficient work needs to be done to establish the benefits of the system to enough accuracy to convince management to give approval to proceed to the next phase.
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.
Definition.Appoint key team members
Establish a preferred option (if not already done)
Develop baseline and schedules for project management
Studies (eg value management, economic)
Develop contracting strategies Develop implementation strategies
Definitive estimate -15 to +25%
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
Definition Report Reviews
Design Estimate -10%+10%
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.
AcquisitionSpecification and working drawing preparation
Pre-construction estimate(after receipt of tenders) -5%+5%
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 success of the project will depend on all three performing.
In this phase the project will go through a number of phases:
Subsequent to this, the system normally has a defects liability period, and beyond that
maintenance must be contracted for.
Project Closeout.Project Final report
Closeout of any outstanding defects and nonconformities
Post implementation review (PIR) as required
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.
to these pages since 9th March 1997