Getting systems `right first time’ when working on any project is a matter of attending to structured, detailed and communicative methodologies by Richard Long

Experience tells me that many organisations expect to suffer `teething problems’ or worse when a new system is put to work. This is true for both large and small companies – and the problems can vary from late delivery of improved throughput to complete disasters – even with whole projects scrapped!

Teething problems can last for months or even years – during which time, production time is lost. Project costs soar; users become dissatisfied; and frustrated managers cast about for someone to blame. And yes, the accusing finger points unswervingly at the consultant engineer.

The point is there’s absolutely no need for this. It is possible to get it right first time, and to ensure that immediately on commissioning, a new system delivers exactly what is required of it.

How? Well, first we must be clear that usually, fault or blame is not the exclusive right of any one party! Project consultants must accept at least a shared responsibility, with the true origin of the problem often resting with a failure to observe what I believe to be fundamental procedures.

Both client and consultant must, from the outset, share a clear understanding of the project brief, its aims and methodology. The spec must be clearly documented to provide a concise reference for the project. This requires approval by all parties before implementation. And, the understanding must reach all managers; it must not remain a well preserved `confidential communication’. It is not unknown for a project to be agreed at top level – yet the details, objectives and implications fail to reach the managers and operational staff!

Consultant engineers must maintain on-going project dialogue with client management to check progress step-by-step – and to be aware of any deviations from, or amendments to, the project brief. Failure in this area is a proven recipe for problems later. Regular project review meetings, involving all key managers will eliminate misunderstandings and consequential system difficulties. It’s essential to nominate a lead project manager to whom the client can refer.

It’s equally important for the client to name a manager to assume the lead role on his behalf. Neither party should be excluded from critical decision-making information.

System testing can be overlooked or by-passed in a frantic drive to recover lost project time. And, the result can be disaster! Bugs always reveal themselves at a time when all concerned have their expectations fixed on total success!

Next, the system documentation must be carried out by members of the project as it progresses to ensure that the client has a clear, usable reference describing all aspects of the system. Too often this is left to remaining staff after project delivery; leading to an unintelligible, incomplete document of little use.

Purchasers have a responsibility to ensure that decisions to progress the project are made and the supplier has sufficient time to implement the solution. Orders are sometimes placed when deadlines have passed – in order, apparently, to protect cash flow! This forces the supplier to cut time scales – usually by reducing system testing – thus causing problems and inefficient solutions implemented after delivery.

Observance of proper disciplines can eliminate the majority, if not all of the problem areas which too often obstruct the delivery of a project on time and right first time. To illustrate how they can be applied look at the following two projects.

First, on an unmanned water treatment plant control system, scope of the project was to design and implement distributed control on a plant consisting of two nodes communicating with each other and a PC-based MMI using TCP/IP over Ethernet. Starting point was a functional specification. This was a stand-alone document providing a complete project reference.

The areas where all details were available were agreed and approved, allowing these to be implemented. Other aspects of system implementation were carried out when their areas of specification were approved. Functional specs had to be available and approved before they were needed by the project team.

Software methodology was based on traditional object-orientated design techniques. It was carried out by separating the plant into a number of objects (areas) and defining the interfaces between each. These were also sub-divided (plant I/O, MMI and sequence control) and for each object detailed design was carried out and the interface between objects specified.

Database, graphics and control system software were all fully tested as separate entities before being integrated for in-house acceptance tests. All known faults were then rectified before customer tests. Using this methodology, user acceptance tests ran smoothly – with the system delivered on time and to budget. Project scheduling and control were carried out using MS Project to determine critical tasks and ensure that milestones were adhered to.

The system worked first time on-site, with the contractor able to install and start-up the control system without the supplier’s presence. In fact, commissioning consisted of a minimal period for tuning PID loops and making minor software mods.

Next, lets look at an emulsion flocculation batch control application for a photographic film manufacturer. The process follows gel preparation and comes before the digestion process in producing emulsion for the coating of high grade photographic paper. Repeatability of production is essential, and the project was implemented on a DCS using its own batch control package.

Method of working and scope of the work were defined using Cytek’s quality procedures – in line with TickIT under ISO9000. From a functional description of the process an overall plan, using MS Project, was produced which included milestones for key stages. But right at the formative stages, an acceptance criteria document was developed and agreed – reflecting all the functional requirements. Early production of the document was important since it focused attention on the actual requirements and enabled good practice, inherent in the STARTS methodology, to be utilised.

Detailed design of the batch control sequences and user graphics were carried out and approved by the user. Actual implementation of the code was then performed under version and change control procedures. An acceptance test specification was then produced, detailing the tests to be performed at customer acceptance, and this approved by the user.

To ensure the system was `right first time’ it was initially tested by Cytek to ensure compliance to specification. Customer acceptance testing was then successfully performed. In this case, `right first time’ was not only the objective but a production necessity. This project was on a live plant, where a loss of production capacity would effectively stop production from all associated plants.

The software was tested on the new plant production equipment, whilst the existing plant continued production. The new plant was brought on-line when testing was completed, during a process plant shutdown.