Standardisation just makes sense. Having an agreed set of minimum requirements, from pool fences to electrical installations, and thousands of other things in between, is the best way to strive for consistency, value, and safety. A strong, used set of Standards underscores confidence and reliability for users of the item.

I have been involved in Australian Standards (AS2885 in particular) for almost 20 years. The suite of Standards for petroleum pipelines are well-written, usable, and kept current through frequent updates. There are several committees looking after the pipeline Standards. Committee work is hard and challenging work, but fun, as well.

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

Knowing your own competency is essential, especially in high-risk endeavours 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. On the other hand, you can have an ethical, principled person who keeps making mistakes. Neither is a good situation.

When I went to university, at the University of Alberta, there were only a handful of engineering disciplines to choose from: civil, mechanical, electrical, mining, or chemical engineering. I chose civil (and loved it). My first job out of university was with a pipeline operations company.

I’ve met all types in this industry, and each engineering discipline brings a unique spin on the problem-solving and trouble-shooting that any kind of engineering involves.

Working in the pipeline industry isn’t something most of us daydreamed about, but those who end up here find it to be fun, challenging, and worth the effort.

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.

People who work with pipelines understand that the pipeline goes through other people’s backyards. The ‘people’ working with pipelines could be engineers, technicians, lawyers, construction workers, administrative staff, and so on.

And by 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’. The pipelines are safe and are basically invisible to the public. And they should stay that 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

Many years ago, when I had been working as a pipeline engineer for about 10 years, I started asking the question, “just what is a pipeline engineer?” I wasn’t really sure if I was one. Because I was doing so many different things on so many (pipeline) projects.

Pipeline engineering isn’t an engineering discipline, like civil or mechanical engineering. It’s 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.

Pipelines are buried out of sight and out of mind. They crisscross our cities and farmlands and deserts. They carry energy or water or slurries or other liquids and gases from source to destination. Designing, building, or operating a pipeline should be straightforward: dig a trench and put the pipe in it and let the contents flow. And yet it is much more complex than that.

Steel pipelines for the transport of energy have had a stellar century, with millions of kilometres of pipelines now installed all over the world.

It’s a fascinating time to be in the pipeline industry.

July 1st is the national day for Canada, recognising the creation of the country in 1867. I know there are some tough times going on there, with some deep introspection underway about its history. It is a journey that many modern societies are going through.

The forming of countries is only a recent phenomenon in the realm of humankind. In creating a country, we establish a boundary, and a governance framework. It also establishes an identity and a way to pigeonhole (apply biases) when you meet someone new.

Bring on the hockey, maple syrup, and getting oot and aboot, eh.

It’s been noted a few times, by a few different people, that while lessons learnt sessions are valuable, the greater challenge is the storage and sharing of the outcomes of those sessions.

Ideally, the lessons learnt are recorded in a record-keeping database, which is easily searched and sorted to find the exact right lessons for the next project.

While good in theory, the reality is that database lists and libraries lack context. And dare I say, they lack the humanity of the lesson. The lessons are related to a story. Get the story told, as well as the data captured.

In addition to “lessons learnt” sessions at the project conclusion, another good project management strategy is the ‘pre-mortem’ session. The ‘pre-mortem’ is undertaken before the project starts. The project team thinks about all the things that could go wrong, in an attempt to manage them before they eventuate.

Using the lessons learnt from the previous project is an efficient and sensible way to kick off a pre-mortem, by reviewing the lessons learnt from last project’s problems. Even if the scope of work isn’t exactly the same, the lessons can usually be extrapolated into new contexts in a pre-mortem facilitated workshop.

I’ve been a keen supporter of the idea of “lessons learnt” sessions. Getting the team together to review the project afterwards sounds good in theory.

Being currently involved in a well-planned project that was thought through in detail, but has still gone (slightly) bad, makes me appreciate how hard a “lessons learnt” session would be, for those who experienced the lessons.

I’m experiencing the pain and frustration of having done plenty of planning, and still, things haven’t gone to plan. Putting these ‘lessons’ up in front of a crowd of peers, for all to evaluate, would be a daunting thing.

This evening, the Queensland Maroons team lost (again) to the NSW Blues team, in the annual State of Origin best-of-three game of rugby league. It was hard to watch.

Games have rules, a start and finish, and clear winners and losers. Everyone playing the game agrees on when it starts and stops, and how a winner is decided.

Business isn’t like that, not entirely. There is no agreed start and stop to business activities, not really. And while there are rules in place, how they are applied is sometimes left up to interpretation.

Games are for entertainment, that’s the difference.

Anyone who gives advice about making decisions has to also recognise the inbuilt responsibility associated with any decision. Giving advice about decisions is also giving advice about taking responsibility.

The hard reality is that decision makers are taking responsibility for the outcomes of that decision. It can’t be any other way. People in roles that require making tough decisions carry a lot of responsibility. And that can and should be worn with dignity and pride: You make the tough decision, and then you wear the consequences. Shirking that responsibility might be part of the problems of the world (and politics).

It’s easy to talk about how to make a decision, or to give advice about it. There are textbooks about the science or psychology of decision-making. There are website articles outlining strategies and step-by-step frameworks.

But when managing a project, no theory prepares you for the volume of decisions that need to be made. Some have minor consequences, while others have major, make-or-break consequences. Sometimes the consequences of the decision are equally bad. Or equally good.

The thing about decisions is, the anxiety in the lead-up is usually worse than the aftereffects. Once the decision is made, the clouds clear.

Today I was on a house-build site, where some young labourers were moving a pile of dirt, as well as a dozen crates of decorative fence stone.

It took much longer than it should have.

It would’ve been valuable to spend a bit more time planning where the dirt and stone needed to be moved, and the route it would take.

So, while their enthusiasm is appreciated and admired, the lack of planning and foresight caused multiple handlings of the material. They also almost ran over the portable toilet.

That’s why it’s good to balance youthful enthusiasm and wise experience.

I’m sure there’s a joke in there somewhere, if this is about how to be a chair.

A chair can be comfortable and soft, or squeaky and inappropriate. It could be loud, or, it might be understated. The metaphors abound.

The word “chair” is morphing into meaning a role or job title, as much as it is something to sit on. I like it –it’s easier than saying chairperson.

In a meeting, the chair is a facilitator. And the facilitator role is there to smooth the process of achieving the meeting’s objectives.

Good meeting chairs are neutral, timely and effective.

There are only two reasons to have a meeting: either it is for brainstorming, or it is for decision-making. This comes from a book by Al Pittampalli’s, which I learned about from Matt Church.

The first type is for divergent thinking, where there is space and time for new ideas. Think muffins and beanbags, flipcharts, and lots of time. The second type is for convergent thinking, where decisions need to be made, and attendees come having read the minutes, and knowing the agenda. It should be quick and clear.

People often show up to a decision-making meeting expecting to brainstorm.

As a project reaches the commissioning stage, the role of the pre-commissioning engineer and/or the punch-list manager is to get the kit working, with a strong focus on safe operation. They may need the close-out paperwork for the role, but not after the kit is operational. The process engineer just wants to design the next fancy new process solution, not put all the paperwork in place for the old one.

A ‘project finisher’ role is different: it is all about the paperwork. It’s the librarian, with quality control knowledge, some contracts expertise, and strong story-writing skills for the lessons learnt.

There should be a role called “project finisher”. This would be the person or team that comes in like a cleaning crew, once the project is in its last stages. By then, the project manager is either exhausted, or thinking about the next job (or more likely, both). The project team is also exhausted, and thinking about the next job.

It’s a different skill to gather up the project data, sort through the material data records, capture lessons learnt and write up the project case study.

Everyone knows it’s important to do all those tasks. It rarely gets done well.