Review of the Energy Institute Element 12: Management of Change and Project Management Guidance

by | Dec 8, 2016 | MOC Module Blog, MOC Module | 0 comments

Review Element 12: Management of Change and Project Management

Introduction

I have just been reading an excellent guidance note from the Energy Institute entitled “Element 12: Management of Change and Project Management“. I think that it was authored mostly by Martin Ball and was published in September 2015. It is part of a series of guidance notes that set out a 20 element framework for Process Safety.

My Interest

MOC is a passion of mine. I did my first MOC as a young Engineer with ICI in 1993 (anyone remember the pink MOD forms? ) and over the last 6 years I have been responsible for leading the work on a commercial web based MOC application – http://focul.net/moc . Our application had been shaped by best practices from my time in ICI, the best practices from our customers and the guidance in the AIChE book “The Guidelines for the Management of Change for Process Safety”. I wanted to write this note to see how this new guidance compared to previous guidance and to our MOC product, I find that I take the detail in better if I try and critique it.

Initial Impressions

The document is very impressive and an excellent starting point for anyone wanting to know more about Management of Change for Process Safety. It is quite readable although as with any detailed material you will need to read it several times. The guide progressively introduces the reader to a 19 step framework for delivering a Management of Change process. There is an initial description, then a flowchart and then detailed guidance on each step of the flowchart. There are also very helpful appendices with example proforma.

Part 2 – The Detail

Part 2 of the document sets out 17 attributes or expectations that can be used to determine how well your existing MOC process fits with the suggested framework ( section 1.2 ). These 17 attributes are then mapped to the 19 step MOC process. The 17 attributes are fairly obvious but there are three that I have often seen missing in MOC processes. 12.5 – MOC considers human and organisational factors 12.6 – temporary changes do not exceed initial authorisation for time or scope without review 12.15 – Identify and manage risks associated with mothballed and decommissioned assets

MOC flow charts

MOC flow chart The flowcharts are key to understanding the proposed process. There is an overview flowchart showing the 19 steps and then a more detailed flowchart of the Project Management sub process ( Step 4 ) showing a further 14 sub steps. The whole document is titled “Element 12: Management of Change and Project Management” so the contents is a mixture of MOC and of Project Management. In my experience it is very important to clearly distinguish between the two but I will discuss this later.

Detailed description of the 19 steps

The document goes on to discuss each of the steps in detail discussing each aspect in terms of actions, deliverables and frequency of action with associated guidance notes. The steps all make sense and are well described in the document so I will just pick out the key points for me. Step 4 ( Project Management ) is broken out into 14 sub sections. On careful reading I think that the guide is trying to position this Project Management activity as a parallel but linked process to the Risk Management activities, particularly for larger or more complex changes. Step 8 is the classification of the change as High or Low risk. High risk changes are then treated with more rigor in the subsequent Risk Assessment, Control Measures and Review steps. This is a fundamental principle of the FoCul MOC application and ensures that “simple” changes do not get swept under the carpet because the level of rigor required is disproportionate. The document very usefully cross links to the Elements 3, 6 and 17 guidance documents in the PSM framework and to example risk assessments in the appendix. MOC Risk Mtrix Steps 16,17 and 18 I found these steps particularly interesting. My experience is that when people adopt our application ( typically from a paper system ) there is a clear performance step change in consistency, control, transparency and efficiency. This step change is very visible and it is easy to see that things have improved. While this is a good thing it has meant that people are less inclined to put in a formal management review process of MOC – because it is easy to see the recent step change improvement. However, I think everyone would agree that a robust Management Review process is definitely an ongoing requirement of any MOC process. Reading through steps 16 ( Performance measurement and compliance checking ), 17 ( Performance and compliance trend analysis ), 18 ( Annual Review of effectiveness and Sustainability by system champion ) and 19 ( Management Review and Control Meetings ) I did wonder if this should be a module within our MOC application. Our application already produces a dynamic set of metrics and users can click through from these bar charts to the underlying data, but what is missing is the structure of a review process. It is a bit of a philosophical point as to whether the MOC Management Review process should sit within the application or whether it should sit alongside other Management Review processes in a central process ( assuming that there is one ) – something for me to think about.

Part 3 – Compliance Checks and Performance Measures

The next 13 pages set out 11 performance measures that can be used to determine the health of your MOC process. For the most part these metrics do make sense but some are unclear. Metric 3.4 is the number of “MOC Assessments” Overdue. This phrase “MOC Assessments” is not used elsewhere in the document so it is unclear what it means. In my experience the MOC stage gate processes are not time boxed and there is no sense of an MOC stage gate being overdue against a date. A control action or some mitigation measure may be overdue in the sense that it is not in place when required but this is different from it being overdue in a time sense and I would suggest is a Project Management failure. Metric 3.5 measures overdue control measures, again in my experience assigning target dates to control measures is not common practice. What is important is that the control measure is in place for the appropriate activity. The timing of this falls into Project Management rather than Risk Management. Metrics 3.6 and 3.7 on Temporary Mods are well worth measuring and any good MOC process should have a robust process to ensure that Temporary mods get recertified on a regular basis. Metric 3.8 is around HSE Project Status – Forecast Status against Schedule. Again it is a time based metric but in this case I can see that it is a very useful measure. It obviously relates to risk but for me it is a Project Management metric or a Process Safety metric rather than an indicator of the health of the MOC process in itself. Metrics 3.9 and 3.10 are around Audit and Management Review and I think that these would help to reinforce the need for ongoing Management Review of the MOC process. Finally I really like the idea of metric 3.11 which is “Incident Root Causes which are failures of Element 12 ( MOC and PM )”. The emphasis on this kind of joined up thinking is excellent.

Appendices

The Appendices are very useful. Annex D has a useful “Management and Supervisory Field Observation” proforma. It gives a good basis to build on although for me it is a bit too broad brush – I think that you need audit MOC applications at an overview level and at the level of individual changes. Asking if all the control measures are implemented adequately is an impossible question to answer at a MOC process level, it needs to be asked against specific changes. MOC Audit Proforma Annex F and G are examples of Organisational Change Risk Assessment Worksheets. Again these are very useful addition as many organisations do not manage the risks associated with organisational change well enough. I particularly like the Resource Balance Assessment sheet. I am not sure how you would go about filling out the actual forms in detail but the principles are sound and do need to be addressed. My feeling is that where multiple roles are affected ( which is often the case ) then this methodology almost needs to be treated as a separate study in a similar way to a hazops as the volume of detail would not be easy to manage in a conventional MOC process / application MOC Resources Check 2 MOC Resources Check 1 Annex H shows how Risk Grids can be used to categorise the Risk and prioritisation of the change. The guidance suggests 3 sets of risk grids, Health and Safety, Environment and Reputation and Financial cost and Business Interruption. In my view the matrices used here should be the same as those used across the rest of your PSM framework. The examples shown are a good starting point. MOC Risk Mtrix Annexes I and J are about Project Management Scheduling

What is missing ?

The document is excellent and I can only imagine the effort that has gone into producing it ( and it is one of 20 such documents ). I think that it is very comprehensive but there are some topics that might be good to include.

  • What is a modification ?

This seems like a straight forward question but in practice it is not. In my experience there is often a degree of uncertainty in what constitutes a change. As an example is the substitution of a CAF gasket for an asbestos gasket a modification?  Similarly is the substitution of an obsolete controller with the newer model of that controller a modification? For the record my response would be “it depends” – in both cases if upfront work has been done to recognise and proceduralise the equivalence of the items then each individual substitution may not be a change – although there may have been a generic change raised for the initial assessment. There is also a grey area in many organisations where temporary process activities are authorised via temporary instructions out with of an MOC process of the type described here.

  • Criticality Ranking Context

Before I start let me say that there is not a single answer to this. When you are ranking the HSE criticality of a change and you consider the guide words such as “Likelihood of major fire-explosion” are you considering the risks during the execution of the actual changes or the new baseline risk of the plant post change ? In my experience it can be both and will vary between organisations.

  • Management of actions and records

The efficient and robust management of actions and records can make or break an MOC process. By way of example if a manual register ( excel or paper ) is how action status is managed then it is more likely that actions and records will get missed and thatthe process will be less efficient.

  • Stakeholder Engagement

The document emphasises the importance of the technical competency of the approvers but it does not address the need to include Process Technicians in the risk assessment processes. The technicians on the ground are often very well placed to contribute observations about the practicality of proposed changes. It is also important that the Permit to Work issuers are aware of each MOC in progress and can access the deatails easily.

Risk Management V’s Project Management

When I talk to a new customer about our MOC application the very first thing that I do is understand if they want a Management of Change for Process Safety application or a Project Management Application. In my experience trying to use a MOC process as a Project Management process undermines the integrity of the MOC process straight away. A simple distinction is that in an MOC application I will only attach or reference those drawing revisions pertinent to my risk assessment whereas in a project management system I may reference every revision of every drawing. This guidance document mixes advice on Project Management with Management of Change. Is that a bad thing ? To be honest I am not sure. It is absolutely the case that the two processes overlap but the fact that step 4 has 14 sub steps does indicate that trying to combine guidance on both MOC and Project management is difficult. I also think that there is a danger of not doing Project management justice as it is a whole topic in itself.

Conclusion

This is an excellent document for anyone interested in MOC. You can download or purchase a copy here If you would like to know more about the FoCul MOC application that can be used to deliver this MOC framework you can see our web site or these previous Linkedin Posts Introducing the FoCul Management of Change Application Chemoxy international MOC Case Study Notes : the images above are from the Energy Institute. They have not been reproduced in full as copyright is with the EI