How to avoid making mistakes with management of safety projects

Without effective functional safety assessment and audit, you may never know whether your safety system will perform when it is really needed. That is perhaps a bold statement, but read on if you think you disagree...

Automated systems have been used in safety applications now for a few decades. As a result we should have some good collective experience for handling projects that involve using these systems to reduce risk.

The safety systems I'm writing about in this blog are variously called ESD, HIPPS, BMS, IPS, ICSS, SIS, SRECS [1] or possibly some other multi-letter abbreviation that I've forgotten to mention. These systems typically use discrete (on/off) or analog sensors to detect hazards, programmable logic to decide how to act, and final elements that take action; usually without human intervention.

More...

The technology itself is not that new; which is a good thing for safety. "New" often means unpredictable. What we really need from such systems is predictable behaviour. If there is a fault, then we want that fault to be revealed and not hidden. When a demand for action happens, we want the system to respond with a level of integrity and speed that is way beyond human performance. That should be achievable given that modern systems have very high speed logic processing, very high reliability and predictable failure modes. We can even buy "off the shelf" Safety Integrity Level - "SIL capable" devices from suppliers who have designed these products for safety applications.

That paints quite a rosy picture, so where's the problem?

My personal experience stems from having completed independent functional safety assessment and facilitated SIL studies on many different projects in the past 15 years. These projects have been in different applications and for many different organizations in different countries. As a result, I think I'm fair in concluding that my experiences are not just unique outlying cases.

There are some common themes in these projects when it comes to how functional safety is managed, or in some cases poorly managed.

1. Planning.

You may know the saying "if you fail to plan, you plan to fail". I'm not certain, but I think I should attribute that to Winston Churchill. I never fully understood this saying when I was younger. Surely it is possible to complete tasks perfectly adequately without a plan? Well, yes possibly, if everyone knows exactly what they are supposed to be doing and are practised in doing it. Unfortunately, this is not the case for most safety system projects which tend to be very unique.

In my experience there is always a project plan, often even a generic safety plan, but these typically do not get into the detail required to achieve the required goals for safety systems. Individual companies do have their own plans for their own scope of work, but the overall planning to get different companies to interface together correctly is often lacking.

A good safety system project plan (or functional safety management plan) must include all the expected detailed activities, procedures for completing tasks, who is responsible for each task, who is required to authorise them, and who else needs to be informed along the way. An RACI (Responsible, Accountable, Consulted, Informed) matrix is often one very good way of communicating accountability and responsibilities at the top level. If you've not seen one before, take a look at the short video introduction from our online learning.

Of course, such a matrix is not the only thing required, but as a tool to clarify responsibilities and track progress it is simple and practical to implement.

2. Competence assessment.

Incompetence is defined as "inability to do something successfully; ineptitude." When I ask myself if I have seen that during a functional safety assessment then the answer is very clear. Not on every project, but yes, I have seen it. Sadly, several times.

Competence is a tricky item to assess. None of us are competent at everything. Engineers and technicians specialize into disciplines and we often trust that the specialism of the discipline means that the likelihood of competence is increased. We also put people into multi-discipline teams for important studies like HAZOP/LoPA/SIL determination. We do this precisely because we know that the outcomes should be better than giving the task to an individual who will have limited knowledge.

Setting and achieving safety integrity levels (SIL) in safety system projects actually works across several different disciplines. The focus tends to fall on the electrical, control and instrumentation  (EC&I) discipline, but I think this is a mistake. Of course, design of an automated safety system will rightly involve EC&I, but it should not end there. Process engineers, safety professionals, operations personnel and others must recognize their part in setting correct requirements for the system. Operations and maintenance personnel must recognize their job in sustaining the delivered system. All have parts to play. Any of the parts that involve incompetence will act as a potential weak link that could eventually lead to an incident.

So, what can be done about competence if people are unaware of what they don't know? Managers have a responsibility to put competence at the forefront of safety system projects. They must put in place a competence management system which both sets minimum expectations for each role, and then measures each individual against it. Any gaps in knowledge or experience must be identified and get higher attention for review and oversight.

3. Procedure control.

Some projects I have worked on have used very poorly written procedures.  If you are the hazard owner (or duty holder) of the hazard, then it is my firm belief that you should be responsible for either providing, or at least carefully reviewing and approving the detailed procedures used on your safety system project. Some of the larger companies in the Oil and Gas industry are good at controlling this. They have experienced what can happen when poor procedures are followed. Sadly, the story is different on some of the smaller projects and on almost all projects where there is limited experience of safety systems and functional safety.

Take the example of a LOPA - layer of protection analysis study. There are many consultants that work in this field. An inexperienced duty holder may accept a procedure coming from a competent consultant. This would seem to be reasonable. For instance, we wouldn't tell a hospital surgeon what detailed procedure to follow for a complex operation he's going to perform, because we accept that the surgeon probably knows better than we do! However, we're still very likely to ask the surgeon what is involved with the procedure, what the risks are and what the outcome is likely to be for us when the operation is finished. We will ask these questions in advance of the operation, not after it when it's too late.

My point is that when duty-holders blindly accept a procedure, like a LOPA procedure, from a third party consultant, they typically do not ask any detailed questions before the study. They make the "they know best" assumption. Unfortunately this leads to many project issues when, for instance, the LOPA does not produce expected outcomes. I have used the example of a LOPA procedure, but this is only one case. I have experienced issues with many other procedures that simply did not achieve what the duty holder needs, but were still blindly accepted on the project.

The solution for the duty holder is fairly clear. A group of detailed procedures should be developed for the safety system project which are good quality and which create a "joined-up-thinking" approach. The duty holder should be responsible for ensuring that the procedures are accepted by all parties involved and actually followed on the project.

4. Information control.

In any safety system project, there are always multiple people involved. Very small modification projects might be limited to a few people in your own organization, but even quite a modest-sized modification or new-build project will involve multiple people, and probably multiple departments and multiple companies.

Most projects know the benefits of producing controlled versions of documents for drawings, specifications, action lists and reports. Usually, the company assigned as main contractor will control the project documents until hand-over. In good projects, the main contractor appoints a document controller who places released documents in a document control system. In better projects, the document control system can be accessed by everyone who needs access by topic or package area, whichever company they are from. This kind of document control is certainly part of good information control, but sadly it does not solve all problems.

Day-to-day communication still tends to be done by email on most projects. This creates silos of the latest information that simply get locked up in individual computers. It also provides the opportunity to "hide" sensitive information when a problem is found between parties. Some might think this is contractually savvy, but in fact it tends to lead to bigger problems further down the line.

So what are the potential solutions? With the advent of cloud computing, collaborative project tools are certainly one thing that could easily be applied. I have not tried them all, but you can search on the internet and find many collaborative cloud solutions for general project management which include secure file sharing. Instead of everyone working in silos with their own version of the truth, an open collaborative approach could really benefit many safety projects in our industry.

There are also several specialized safety life-cycle software tools available from companies who work in this sector. I'll be featuring a more detailed blog on the merits and challenges of using such tools in the future, but some of the ones I'm aware of include aeSolutions aeShield, exida exSILentia, HTS Engineering SISSuite and Mangan SLMv2 . There are possibly other tools out there, but these ones are cloud-based, which has to be the future for collaborative projects.

5. Independent assessment early in the project.

Most safety system projects in the process industry sector fall short of the requirements of the standards they attempt to conform to. That sounds like a sweeping statement, but I can only go by my own experiences. This does not mean that all project outcomes are unsafe. However, it does mean that many projects waste significant money in re-work and fixing problems after independent assessment.

The IEC 61508 [2] standard very clearly recognizes that functional safety assessment (FSA) should be independent of the project team. Depending on the severity of consequence, safety integrity level and the scope of the assessment, perhaps even an independent organization will be required. IEC 61511 [3] recommends that FSA is started when the safety requirements specification is complete. However, it does not require this timing, so companies are able to choose to assess a system at the validation testing stage, which will be way too late if there are problems.

The above standards do very little to recommend the best timing for project activities. One way of approaching this challenge is to engage competent functional safety management and functional safety assessment much earlier in the project. A good functional safety manager will know the standards intimately and will know what problems are likely to arise before they happen. They will plan, guide and coach a multi-discipline team who may be less experienced. An independent assessor will be able to make a judgement which has much less impact if they can do this while problems are still easy to fix.

In conclusion. there are some practical and very simple things that can be done to make safety system project outcomes much more successful. I hope some of this advice proves useful.

If you would like to learn more about functional safety management, follow a recommended online course by clicking on the link below.

Functional Safety Management

Online self-paced course (1-2 hours)

REFERENCES:
[1] ESD: Emergency Shutdown, HIPPS: High Integrity Pressure Protection System, BMS : Burner Management System, IPS: Instrumented Protective System, ICSS: Integrated Control and Safety System, SIS; Safety Instrumented System, SRECS: Safety Related Electrical Control System.
[2] IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related
systems.

[3] IEC 61511: Functional safety of safety instrumented systems for the process industry sector. This standard is now variously known as IEC 61511 edition 2:2016 or BS EN 61511:2017 in UK and ISA 61511 in the USA.

About the author

Jon Keswick, CFSE

Jon Keswick is the Founder of eFunctionalSafety and author of the IChemE accredited "SIS Foundation" online training course.


>