Unplanned Outcomes, Stories, and the Intent of our Standard

by Ted Metcalfe

It may have been Einstein who famously said “The more I learn, the more I realise how much I don’t know.

More simply put, “We don’t know what we don’t know”.

Photo by Iva Muu0161kiu0107 on Pexels.com

Gaining awareness of things which have not turned out well for others helps us to get better at what we do so that we don’t repeat mistakes others have made.

Industry codes and standards record the wisdom and experience accumulated by many engineers over many years for the benefit of all engineers, and these need to be updated regularly for various reasons including knowledge of things which have not turned out well.

In his book The Making of an Expert Engineer, Prof. James Trevelyan states at Page 57:

Technical standards have been created through the experience of other engineers and are carefully negotiated within each specialised engineering discipline, striking a balance between restrictions to promote safety and ease of use, while also avoiding constraints that would inhibit innovation and design freedom.

That’s an excellent description of what the engineers on our Standards committees do all the time.

In the Australian pipeline industry we have an excellent Standard (AS 2885) to work with because we revise it regularly to keep up to date with new information.  Awareness of poor outcomes is one of the things that has informed the continued evolution of the Australian Standard in a way that pipeline engineers in other countries envy. 

Here’s some examples of links between past events and the current Standard:

Part 1 Clause 13.2 (a) requires project design records include as-built data. 

Example: Due to a contractual issue, the as-built survey data for an HDD was not provided to the client. A few years later, during third-party works near the HDD, the original design drawings were assumed to be accurate. They were not. The third-party works punctured the pipeline far below the surface, and the client ended up replacing the entire HDD string.

Photo by Pixabay on Pexels.com

The AS2885 suite requires detailed attention to SCC and Fracture Control.
In 1982, a major rupture of the Moomba Sydney Pipeline over some distance prompted a lot of research and investigation associated with Stress Corrosion Cracking and the importance of Fracture Control to arrest running fractures. The outputs of the research and investigations have resulted in revisions to AS 2885 in several areas.

Photo by Monstera on Pexels.com

AIV and FIV (Vibration)
AS2885.1 now includes clear delineation between “linepipe” and “piping”, and makes specific reference to AIV and FIV as potential failure modes. The unexpected discovery of an integrity threat on a relatively new pipeline system, and the research associated with mitigation of that threat, have now been incorporated in to AS2885 as revisions in several areas including the vibration Appendix.

Photo by Anni Roenkae on Pexels.com

Knowledge of such events leads to a better understanding of the intent of the Standard, but sometimes the background for changes in the Standard is not widely known by those who use it.

Sharing of stories about things which have not turned out as planned is one way to increase awareness for better understanding of the intent of the Standard.

Sometimes that requires sharing stories with others about things that we ourselves have not done well, which can be embarrassing.

Despite the reluctance to share such stories, the AS2885.info team and others believe that we can and should get better at helping others learn through sharing stories.

If you are intrigued by the concept of sharing stories to help others better understand what went wrong and avoid making the same mistakes, please contact us.

Gaining Confidence

by Ted Metcalfe

Do I know what I’m talking about?

Photo by Rodrigo Souza on Pexels.com

Experienced engineers are able to make engineering judgements with confidence. Some of the reasons why pipeline engineers using AS2885 may benefit from asking a question in relation to confidence include:

1) Maybe you are required to make a decision in relation to application of the Standard, but just don’t quite have the confidence to do so, and a second opinion would help.

…I don’t know enough about this, but I’ll bet someone else around here does…

2) Maybe you have been told by your supervisor or an experienced colleague that a certain clause means one thing, but their interpretation does not seem quite right to you, and you would like a second opinion without openly challenging your colleagues.

…that’s not what I think it means; I need more guidance here…

3) Maybe you have witnessed what you think might be an incorrect or inappropriate practice, and before making any fuss about it in your own workplace you would like to quietly get a second opinion from an independent source, without disclosing why you are asking.

…I’m pretty sure this isn’t right, but I need confirmation…

4) Maybe you are involved with modifications to a rather old pipeline for which not all of the usual design and inspection material is available, and you are unsure as to exactly how the current Standard should be applied.

…this pipeline is older than me, and it needs help… and so do I…

5) Maybe you are afraid that your question will be considered by other as a dumb question, and you don’t want to ask in the office and risk looking silly for not knowing the answer already.

…I’m not dumb, but I feel that way…

This last point prompts me to describe how I learned a very important lesson about asking questions quite early in my career when I was working in a sour gas processing plant:


Amoco Canada processed a lot of highly toxic hydrogen sulphide gas and the gas plant where I was working had experienced a serious accident. As a very junior engineer I was allowed to attend the meeting of management convened to examine the causes and work out a way forward, but I didn’t understand everything that was being discussed.

At one point I bravely put up my hand and said “Can I ask a stupid question?”

The plant manager replied calmly from the other end of the table “Son, in this industry, there are no stupid questions, only dead people who failed to ask the questions, so how can we help you?”


Ever since then I have had the confidence to ask a question when I didn’t understand something.

You can ask the AS2885.info team any questions which might help you be a better pipeline engineer – that’s what we’re here for.

Asking Questions is the Easy Way to learn

Be a better pipeline engineer – ask the question!

by: Ted Metcalfe

Photo by Ksenia Chernaya on Pexels.com


We learn new information in many ways, and for many different reasons. Even when we are not trying to learn, or don’t think we need to learn, we seem to gather valuable information.

For some people, lessons are really only learned if they are learned the hard way, from the bitter experience of having done something wrong with unexpected (sometimes embarrassing, painful or expensive) consequences.

It’s a lot easier to learn by asking questions.

In the Introduction of Part 0, it is acknowledged that AS2885 sets out specific requirements in some areas, but notes that these do not replace the need for appropriate experience and engineering judgement.

In Clause 1.5.7 of AS2885 Part 0, competence is defined as having an appropriate combination of knowledge, skills and experience to safely and effectively perform the task required as requirements for users of AS2885.

Users of AS2885 are required to apply engineering judgement.

It can be said that engineering judgement requires a combination of both knowledge and the confidence to make decisions, where:

– Knowledge is the accumulation of relevant factual material, and

– Confidence is the self-courage required to interpret both the relevant circumstances being considered and the application of the Standard to those circumstances, and to make decisions on that basis.


Experienced engineers have learned that one of the easiest and most important ways to learn is to simply ask questions, and for pipeline engineers, that’s one of the main reasons that the AS2885.info wiki was created.

We’re here to help you learn, and we look forward to having users of our Standard ask questions.

Accumulating Knowledge


by Ted Metcalfe.

Ask the question!

Photo by Pixabay on Pexels.com

Some of the reasons why pipeline engineers may benefit from asking a question in relation to accumulating knowledge include:

1) Maybe the matter you are working on is a bit out of the ordinary, and you are not sure exactly which part of the Standard should apply.

….Which clause covers this?

2) Maybe a clause in the Standard that you were previously familiar with has been changed or has disappeared, and you want to know what clause applies instead.

….Where’s that clause gone, what do I do now?

3) Maybe you have learned about some innovative new product or material that does not seem to be covered already in the Standard.

…Can I use this new-fangled approach?

4) Maybe you have an innovative idea that you would like to implement, but to do so might be stretching the intended scope of the Standard.

…Can I change the way we do this and still conform to the Standard?

5) Maybe the wording of a clause seems confusing, or could be interpreted two different ways.

…whaaaat?

6) Maybe you simply want to learn more about a particular topic in pipeline engineering, construction or maintenance, but don’t know where to look for additional information.

…I’m new here, where do I start?


This last point illustrates that while good experienced engineers always work within their limits, those limits can be expanded by additional training, study or participation in events.

If the AS2885 team can’t help directly with any of the above, someone in their wide networks of industry contacts probably can, and we will make the introductions for you.


Failure is Normal …. and Bridges can fail more than once!

APGA has advertised for our next technical webinar, via an email sent today (Monday 16 May).

The webinar will be on June 15, 2022, at 12:30pm AEST presented by Ted Metcalfe.

Get on over there and sign up via the APGA events website.

https://www.apga.org.au/events/technical-webinar-failure-normal

The title is: “Failure is Normal”.

This is a concept that might be hard to agree with. Especially since engineers are generally tasked with preventing failure.

What we’re trying to address here is the idea that engineers should consider failure is ‘normal’, so that then we do everything we can to prevent it.

The email sent by APGA on Monday 16 May included dates for the bridge failures which weren’t quite correct. (“the Quebec Bridge in 1915 and the West Gate Bridge the late 1960s“).

Mea culpa, the ad copy I sent was an incoherent hybridised version of the dates … which was just confusing, for those paying attention.

Here’s the real story:

  • The Quebec Bridge actually failed twice during construction, first in 1907… and then again in 1916 when they were trying to rebuild it!
  • The West Gate Bridge was of the innovative box girder design, and in the time period 1969 to 1973, there were at least four failures of box girder bridges during construction around the world.  The design was so innovative that the bridges were failing faster than the design engineers could improve the design!

Tune in on June 15 to learn more about why building bridges is a challenge and what lessons we can still learn today from those events. And, how the failure themes on these bridges might apply to pipeline engineering, or, just being a conscientious professional engineer in whatever work you are doing.

Principles

One of the difficult things about being an engineer (…besides everything you’ve just thought of…) is being able to recognise your own competency. 

Knowing your own competency is essential, especially in high-risk industries like pipelines and other potentially hazardous industries.  Similarly, knowing the competency of the others around you is essential too.

Not often contemplated is that there are two kinds of competencies:  knowledge, and behavioural competencies.

A person can be very competent in knowledge, but behave terribly: unethically and without principles.  That makes the knowledge, while useful, perhaps less value. On the other hand, you can have an ethical, principled person who keeps making mistakes.  Neither is a good situation.

Pressure

The contents of pipelines are, more often than not, flowing under pressure. A factor in the design and operation of pipelines, is whether it is designed to operate at “high” pressure or “low” pressure.  The lines into our houses operate at a very low pressure.  The cross-country transmission lines flow at a high pressure.

Those of us who work with pipelines are also, often, under pressure.  Sometimes low pressure, and sometimes high pressure.  There are budgets, schedules, compliance, and safety issues to face. 

It’s a pressure we are proud to bear: we are serving society and responding to customer needs. But often we’re faced with difficult situation and scenarios, that test our principles, test our ability to handle the pressure.

Guidance

There’s now a reference resource to help. The Australian Pipeline and Gas Association (APGA), in conjunction with the Future Fuels Cooperative Research Centre (FFCRC), have published a guidance document to help with the scenarios we face. It was put together by a group of industry leaders – many of whom are part of this AS2885.info wiki and blog.

The publication can be found here: Public Safety in the Pipeline Industry: Engineering Practice Guide.

Pipelines / Pipeline Engineers / Pipeliners / Project Engineers working on pipelines

Many years ago, when I had been working as a pipeline engineer for about 10 years, I started asking the question of people around me, “just what is a pipeline engineer?”.

In asking the question, I wanted to understand what was meant when they asked for a pipeline engineer… what were the expectations? 

I wasn’t really sure if I really was one, even if my business card gave me that title. 

Not because I didn’t know what I was doing, but because I was doing so many different tasks and roles on so many (pipeline) projects.

Pipeline engineering isn’t an established engineering discipline, not like the traditional disciplines such as civil or mechanical engineering. 

Pipeline engineering is a combination of all the engineering disciplines, as well as land management, environmental studies, sociology, and economics.  The most ambiguous statement you can make is, “I need a pipeline engineer for this”.  You’ll need to be more specific than that.

And then there are the project engineers who are (sometimes) working on a long-distance, large-diameter pipeline project. It’s not a full time gig as a pipeline engineer, but suddenly you’re a project engineer on a pipeline project, and there’s a need to know all kinds of things about cross-country pipelines … even if your last project was a wind farm, or an offshore platform, or the process piping in a fenced-off industrial plant. Is being a project engineer on a few pipeline projects enough to make you a pipeline engineer? Do you need to “be” a pipeline engineer to work on a pipeline project? What’s the minimum a project engineer on a pipeline project needs to know?

All good questions.

So, at the moment, never mind: welcome to the pipeline engineers here, and the project engineers working on a pipeline project, and the land agents and the environmental managers, and the corrosion specialists and the designers and the operators and cost estimators and the construction engineers. Maybe we’re all just pipeliners in the end.

This blog, and the associated wiki (AS2885.info) are here to make the journey a little easier, especially when it comes to using and interpreting the masterpiece that is AS2885 (laying it on a little thick maybe).

By the way, you might be a pipeliner if you:

  • – know the difference between piping and a pipeline
  • – have a sticker that announces “I heart pipelines”
  • – have stood in a paddock looking around and towards the horizon
  • – know what the dope gang, pig launcher/receiver, scraper station, and joints are
  • – have a picture on your phone of a really steep slope.  Bonus points if there’s a sideboom in the photo too
  • – miss the heady days of the expansion of 2010-2015 (that one’s Australia-specific)
  • – can’t help but notice the “Danger- Pipeline” signs when you’re out driving
  • – know there’s more to pipelines than you’ll ever know

Working with pipelines

Those of us who work with pipelines, pipeline engineer or not, understand that those pipelines go through other people’s backyards, public places, and where most of the population doesn’t know they are there.

The ‘people’ working with pipelines could be engineers, technicians, lawyers, construction workers, administrative staff, and so on. We, the pipeline people, have responsibilities to the public.

Other people’s backyard: that means the public.  The ‘innocent bystander’.

They don’t do a hazard analysis or risk assessment before stepping out their front door to walk the dog.

We have a deep ethical requirement to consider public safety in our work.  The goal every day is that ‘nothing happens’.

Our pipelines are safe and are basically invisible to the public.  And they should stay that way.

Learning from the Mistakes of Others

From Ted Metcalfe – a longish read but well worthwhile and thoughtful as always …

We’re not good at sharing stories in the Australian pipeline industry, and in my opinion that is a weakness we should address.

I recently drafted the short article which is now available on AS2885.info, setting out some examples of how awareness of unplanned outcomes has already influenced the continuing improvement of the AS2885 suite of Standards.

My objective with this post is to initiate a conversation in order to identify what level of interest there may be in sharing stories, and maybe even development of an online repository of information about unplanned outcomes in the world-wide pipeline industry with particular focus on lessons learned relevant to Australian pipelines.

Why Share Stories?

The value of articulating lessons learned for the benefit of others has been well-known for many years.  

In his 1998 book “What Went Wrong? Case Histories of Process Plant Disasters” it was Trevor Kletz, (the man who invented the HAZOP process), who set out five very good justifications for sharing stories, paraphrased here as:

  • Moral – If we have information that might prevent an accident, then we have a duty to pass that information on to others who face similar circumstances.
  • Pragmatic – If we tell others what we have learned, they may return the favour by similarly informing us about what they have learned.
  • Economic – In a competitive world, if we tell others about things we have done to prevent further accidents, they may spend as much as we have to protect themselves.
  • Industry Perspective – If one company has a serious accident, the entire industry suffers loss of public esteem, and any new legislation arising will affect the whole industry, driving up costs.
  • Impact – Nothing reads and sticks like an accident report.  Mere cautionary guidance is easily forgotten, but we will remember reading about the consequences of getting it wrong.

Sharing stories is just another form of communication and collaboration, which James Trevelyan emphasises as important for the engineering profession in his book The Making of an Expert Engineer.

For me personally, my interest in sharing stories derives from reading a book many years ago called “Set Phasers on Stun” by Stephen Casey.  It’s a collection of short accounts of many different disasters, all caused in some way by human error or by failures in design of the man-machine interface.  There have been many more similar disasters since the book was written in 1998, so I hope he does an update.

Since then, I have read extensively about failures of complex engineered systems. The human error component contributing to those failures has prompted even more reading about how people think and make decisions.  I have reviewed over fifty failure events overseas and in Australia in pursuing this hobby.  

Yes, I admit to being hooked on “disaster porn”, but I believe that with increased awareness of things that have gone badly wrong, I have learned a lot about what works and what doesn’t work in design and operation of complex engineered systems.

Why are we reluctant to share stories?

We are all aware of stories which probably ought to be shared with others.

How do I identify what stories ought to be told?  When I hear about something that went wrong, I just put myself in the position of those directly involved and ask the question: 

If I were in their shoes, would I do things that way again?” 

If the answers that come to mind are “probably not” or “hell no!”; then the story should be shared so that the lessons get passed on to others.

Until recently in the pipeline industry there has not been widespread support for story-telling as a means of passing on knowledge, but the EPCRC researchers documented some research around story-telling as a learning tool indicating positive benefits from doing so.  

Our Pipeline Operators Group maintains a reasonably complete database of incidents of damage to pipelines in the Australian pipeline industry, and from conversation with those administering that database it is clear that some operators are reluctant to admit “own goals”.  

Similarly, poor outcomes or failures in project execution are embarrassments, too often hidden, and so the lessons are not learned by others.

In previous conversations about this concept, others have often expressed concern about getting the facts exactly correct, and a reluctance to identify the parties involved.  I take the view that it is not necessary to do either in order to pass on the important lessons in an effective manner.

Another concern often expressed by others has been fear of potential legal repercussions.  That’s probably a valid concern.  

Readers are invited to respond to this post with comments, feedback, and maybe a story or two; but given that there is some sensitivity around sharing stories, we need some guidelines.

Some guidelines for posting about this topic

If you are sharing a story about Australian events with unplanned outcomes

  • Provide enough description about what happened to put the event in proper context.
  • Focus on extracting the lessons learned which can help others avoid similar unplanned outcomes.
  • Don’t upset anyone by publicly sharing confidential information.
  • If the story can’t be written in an anonymous way so that the identity of the companies or personnel involved is protected, then it probably should not be posted.

The stories can be anything that generates a lesson that pipeliners ought to be aware of. The reasons for unplanned poor outcomes might include any of the following:

  • Inadequate competence and experience.
  • Inadequate or overly-optimistic planning (both budget and schedule).
  • Failure to adequately implement Front End Loading (FEL) practices.
  • Over-specification or under-specification in procurement of contracts and services.
  • Inadequate consideration of potential outcomes, leading to unexpected consequences.
  • Contracting and commercial pressures.
  • Poor selection and administration of contracting strategies.

I guess the above list says there’s lots of ways we might get things wrong!

Overseas disasters

There is certainly no shortage of examples of stories about unplanned outcomes in the world-wide pipeline industry.  

The USA experience is particularly frightening in this regard.  Just go to Wikipedia and search on “List of pipeline accidents in the United States”.  It goes on for many pages.

We have all heard about the big ones like San Bruno and more recently Boston, and for events like that there’s lots of links available to formal investigation reports of hundreds of pages each.  

Not many people are prepared to wade through hundreds of pages to identify the lessons.

For overseas disasters, what may be more useful for Australian engineers is a brief summary about what happened, why it happened, and how such an unplanned outcome can be prevented.   

If there is genuine interest among readers, some of us might be willing to prepare such summaries for others in Australia to read.

Would you like to see a collation of information on each such disaster which summarises what happened and why, and how the lessons learned are relevant for Australian pipelines?

Let us know by posting a response on the blog.

Australia has stories too

We may not have had any similar “disasters” in Australia (yet), but there have been some unplanned outcomes and sub-optimal projects in our pipeline industry, and not all were directly related to pipeline engineering design.  

Although it can be argued that project management and contractual matters are not issues of technical competence, it is my opinion that a solid understanding of such matters by pipeline engineers is important, and also that project management decisions ought to fully recognise technical advice prepared by engineers.  

Valuable engineering lessons can be learned from study of process plant failures as well.

The triggers for unplanned poor outcomes that I have personally witnessed over many years in Australia include:

  • Quality and System Integrity failures.
  • Contractual disputes arising from reliance upon lawyers instead of on engineering competence.
  • Aggressive cost-cutting.
  • Pushing the envelope with new technology or untried procedures.
  • Coatings and coating defects generally, and the technical and commercial aspects of long-term Field Joint Coating integrity in particular.
  • Circumstances peculiar to the recent CSG-to-LNG Boom in Queensland.
  • Acceptance of residual risk when further mitigation ought to have been applied.
  • Inadequate understanding of the technical challenges during design and planning of Horizontal Directional Drills.   

I guess this list says there’s a lot of ways we have indeed got things wrong.

Benefits to our industry

Every unplanned outcome hurts our industry in terms of supply reliability or cost or reputation or all of these.

Stories usually have a significant engineering knowledge component which affects asset integrity, and sharing such stories for increased awareness can only improve the safety and reliability of our industry.

In my opinion, if only a fraction of the legal expenses incurred in dealing with unplanned outcomes of the past had been spent instead to assist development of better skills and competence in pipeline engineering, we would be a much-improved industry today.

Over to You

Feedback, comments and maybe a story or two to share with other blog readers are welcome.

If you are keen to read some good disaster porn or better understand how people think and make decisions, I have a long list of recommended reading for you.