SMS preparation

The most prolific commenter on this blog is Chris Hughes of OSD who is passionate about good pipeline engineering.  Chris and I communicate regularly off-line as well, and he has offered the following for me to reproduce here.  I’ll add a comment or two at the end.

Far too many people in the pipeline industry seem to think that the SMS is a workshop where a group of people sort out the design of the pipeline from a safety point of view, whereas the workshop is only one stage in an ongoing process of ensuring the integrity of a pipeline and the safety of the operators and the public. 

AS2885.1 Clause 2.2.1.1 states very clearly:

For new pipelines, or modifications to existing pipelines, the detailed design and the safety management study are undertaken as integrated iterative processes. The output of these processes is a design (generally shown on alignment sheets), and a safety management study document (generally recorded on a database)

In other words the design process should at all times be considering the threats to the pipeline and how to best mitigate those threats, and documenting all the reasoning behind their decisions.  The first part of 2.2.1.1 makes this clear by saying:

All aspects of the safety management process shall be documented with sufficient detail for independent or future users of the safety management study to make an informed assessment of the integrity of the process and its outcomes, including the identification of threats and the reasoning behind the assessment of the effectiveness of the control measures applied.

I have lost count of the number of times I have turned up to facilitate an SMS workshop only to find that there was no pre-populated list of threats, let alone a detailed assessment of how the design was intended to mitigate those threats – I have even been asked to bring my own list of generic threats.  How anyone thinks they can design a pipeline without knowing what the threats to it are is beyond me – except of course they probably think they can use AS 2885 as a design cookbook to avoid having to think.

The workshop phase of the SMS is for validation purposes only: it should never be used to populate the threat list.  And the mitigations need to be thought through properly for each threat and not just cut and pasted from threat to threat: I have seen SMS threat and mitigation lists presented to a workshop where DBYD and patrolling are listed as mitigations against a truck bogging in the trench.  The validation workshop should be just that – a validation of a properly thought out SMS prepared as an integral part of the design process.

The normative Appendix B states in B3.2:

The safety management study shall be undertaken by personnel with expertise in each component of the design, construction and operation of the pipeline, including, or with the support of, personnel closely familiar with the land uses and environments along the entire route.

In other words the pipeline designer needs to be aware of how the pipeline will be constructed and operated, and also must take into account the needs and requirements of the owners of the land across which the pipeline is laid.  Again in many cases I have seen the construction, operation and land use specialists invited to the workshop only for them to tell the workshop that the pipeline can’t (or won’t) be built or operated in the way the designer assumed, and that the landowners do things that the designer had not anticipated: the designer should be acquiring this information during the design phase rather than at the workshop so that the design takes all these factors into account.

So please remember and appreciate that the SMS process starts the moment the contract is signed for any design work to commence, be that feasibility, FEED or detailed design, and is not just an irritation stuck on to the end of the design process.

—————

On first receiving this I was a little taken aback by one paragraph, because I routinely run workshops where there is no pre-populated list of threats.  In fact in many cases the value of the workshop is in the synergy of group brainstorming to identify threats that might otherwise be overlooked.  However SMS workshops are run for a surprisingly wide range of purposes, and for a detailed design SMS, undertaken when the design is mature, I agree 100% with Chris that the workshop is indeed just a validation review of work that should have already identified and mitigated all conceivable threats.

For workshops run for other purposes, such as conceptual design, early FEED phase, encroachments or operational review there are several reasons why a fully pre-populated threat list might not be the best approach.  In the early stages of design the workshop brainstorming is valuable, and will identify many more issues than could be found by a design engineer sitting alone at his desk.  For an encroachment situation involving external stakeholders the workshop is a very effective means of getting all the parties to understand each others’ positions and then identify threats and negotiate solutions accordingly.  None of which contradicts Chris’ view that the detail design SMS requires all threats to have been fully identified and mitigated before the workshop starts. 

Re-read Chris’ last paragraph above – I couldn’t agree more.

Advertisements
This entry was posted in Pipeline design, Risk assessment, Standards. Bookmark the permalink.

11 Responses to SMS preparation

  1. Mark Coates says:

    I agree with a pre-defined list of threats, however I also appreciate the brainstorming opportunity of a workshop to uncover items which may not have been considered. (For those who remember the 1997 launch of AS2885.1, we ran though a half-day workshop on Safety Management and part of this was an interactive brainstorming and assessment session.)

    In the past I have completed full desktop SMS reviews (threats, assessment, controls) as either stand-alone exercises, or as a pre-cursor to a workshop. I have also been involved with SMS workshops where limited threats indentification had been done – more appropriate to brainstorm based on actual conditions (which is good for modifications to exisiting pipelines).

    Having the preparation done to suit the type of SMS workshop is important. Having the right people around the table in the workshop is just as – or more – important.

  2. Chris Hughes says:

    Peter and Mark have made valid comments regarding threat identification in the early stages of a project, where a brainstorming type session is useful to identify threats that a design engineer may have overlooked. However such sessions are just a useful part of the SMS process and not (in my opinion) a formal validation session which is really only required once a design, operational change, land use change, etc, has progressed to a point where the intention is to lock the design and proceed forwards: there is very little point in validating something which you know may change as a result of information not yet available or complete. My comments largely come from my experiences as an independent facilitator where the validation workshops have almost invariably been at or near the end of the design process.

    Whilst typing this I have received an email from Soheil Taherian who says “Another thing that bothers me is: sometimes engineers and client (both) think SMS workshop is a design validation workshop conducted by a third-party person and they have to defend the design without any interest to sit back and have a think about the risks and mitigation measures. They believe that less actions out of SMS is a win for them!!!” Unfortunately that is often true.

  3. Lynndon Harnell says:

    Might I chip in with a statement that the detail design SMS is only a part of the process. Prior to this, there is the first SMS at Preliminary design and approval stage, then as per Appendix B of AS2885.1.

    B2.1.1 General
    Safety management studies shall be undertaken at intervals during the pipeline design,
    construction and operational phases to facilitate periodic re-assessment of threats and the implementation of controls as knowledge of the threats is gained over time.
    As a minimum, a safety management study shall be undertaken during the following phases:
    (a) Preliminary design and approval The initial design is typically developed as part of a feasibility study undertaken early in the life of the project. It is also generally used as the basis to obtain regulatory approvals for the project. The initial design shall generate sufficient information to allow the initial safety management study to be carried out effectively.
    The initial safety management study shall—
    (i) identify high consequence events that impose major risks to the project, community and environment, and their proposed controls;
    (ii) deliver sufficient information to allow stakeholders involved in the regulatory approvals process to make informed decisions about the risks associated with the project; and
    (iii) recognize that detailed design will identify detailed threats and develop specific
    controls.

    Following the Destail Design SMS, there is a .Pre-construction Review, and then a pre-commissioning review as required by AS2885.1 stated below.

    12.5 SAFETY MANAGEMENT STUDY REVIEW
    The safety management study undertaken prior to construction shall be reviewed against the constructed pipeline to consider design changes and additional threats discovered during construction and their treatment.
    Corrective actions required to ensure pipeline safety through the commissioning and initial operation shall be completed prior to introduction of fluid into the pipeline.
    The review shall confirm that the requirements of the safety management study have been incorporated into the pipeline management system.

    In other words, this review should look at risk mitighations identified in the SMS against as-built data (amongst other things). Typically this would encompass burial depth, allocation of heavy wall pipe, signage, marker tape and the like, but may include an extensive range of other aspects.

    The final aspect of this review, is that it essentially forms a set of driving instructions to Operations wrt the SMS process, e.g. “incorporation into the pipeline management system”. This aspect seems to be overlooked for the most part.

    • Chris Hughes says:

      Lynndon, you’ve committed the sin which I am trying to cure people of, when you say “Might I chip in with a statement that the detail design SMS is only a part of the process.”. This implies that the SMS only refers to the workshop – that is the thinking I am trying to abolish.

  4. Lynndon Harnell says:

    BTW, I have coined an acronym for this last review, RSPC (R)eview of (S)MS (P)rior to (C)ommissioning. 🙂

  5. Chris Hughes says:

    Let’s get back to the fundamentals of what the SMS is all about, which is managing the safety of the pipeline and as I said before it is (or should be) a process which commences as soon as you start looking at a new pipeline route in the concept or feasibility stage and continues through until the pipeline is decommissioned and abandoned. During this process there will be many occasions when it is advisable to get together a group of people with varied special areas of expertise, but these need not be considered as ‘validation’ workshops, just brainstorming sessions conducted as part of the design process. It may still be advisable to have a facilitator who is not directly concerned with the project,simply to ensure that everyone’s voice is heard and listened to. And it is certainly likely that new threats and associated mitigations will come out of such meetings – indeed it is hoped that they do, as otherwise there is little point in holding the meeting! Minutes of such meetings need to be recorded and kept as part of the project documentation as required by 2.2.1.1.

    I believe that a ‘validation workshop’ is a different and higher level affair, and it is at this stage that all threats, mitigations and risk levels should be recorded prior to the workshop. there are, as Lynndon has stated, three major points along the design path where a formal validation is required.

    1. At the end of the feasibilty stage, to confirm that there are no major risks associated with the proposal which may adversely affect regulatory approval or financial committment. At this time only big ticket items such as the route and environmental concerns are likely to be considered as design details will not have been developed sufficiently for consideration.
    2. Prior to construction, to ensure that the final design meets or exceeds the necessay criteria, and
    3. Prior to commissioning to ensure that the as-built details and any design changes during construction have not adversely affected the safety management.

    Following commissioning then any changes which occur during operation will also need to be formally validated.

    That’s my view anyway, and regardless of whether or not you agree with it I think that the process as laid out in AS2885 does not adequately distinguish between the different types of SMS workshop which need to be held. Peter, over to you for consideration by your working party!

  6. Chris Hughes says:

    I realise that readers may infer that I want the threat list for a formal validation to be pre-populated and then fixed in stone. Not at all, the workshop will always be able to suggest other threats which the designers may have overlooked or not had the experience to appreciate: what I object to is the workshop being presented with a threat list that has just been dragged in from elsewhere (or supplied by the facilitator!) with no thought given to its relevance to the specific project and no pre-assessment of the valid mitigations and the risk levels involved.

  7. petertuft says:

    Thanks to all for the discussion – interesting! Some of it illustrates an issue that I hope will be resolved in the next revision of AS 2885.

    When risk assessment was introduced to AS 2885 the focus was exclusively on design of new pipelines. In 2007 it was re-named SMS and broadened somewhat (eg. regular review) but the actual requirements were still largely written around new design. However now we find the SMS process being used for as many as six (!) different purposes: new design, remaining life review (Part 3), change in location class (Part 3), construction activity on or near the easement (eg. new road), hydrostatic testing (Part 5) and even a risk-based approach to general engineering problem-solving.

    The details of SMS application to each of these situations will vary. Chris is completely right about the detail design SMS. However variations, perhaps major variations, are appropriate in some of the other situations. As usual, the Standard must be applied intelligently rather than blindly.

  8. Philip Venton says:

    Peter,
    Never was there a truer statement.
    The SMS is the designers document which should be essentially complete for validation at the Workshop, which is lead by the Facilitator.
    Chris,
    Agree with your comment regarding the early SMS. AS 2885.1 sets specific objectives for these.
    Historically the SMS was developed because Regulators wanted a QRA as the basis for Approving a project. The initial SMS is intended to identify high level risk that could influence an Approval decision, recognising that a detailed SMS will be undertaken in detail as part of the detailed design. Consequently the initial SMS approach is somewhat different from the detailed one.
    However I do consider that the initial SMS really benefits from the thought provided by the designer before the Workshop and properly documented. The design team’s knowledge of the project, and solutions considered should be documented prior to the workshop to “seed” the discussion and so facilitate the brainstorming you mention.
    Phil Venton

  9. Pingback: San Bruno – organisational analysis | Pipelines OZ

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s