I know a few people out there will baulk at the idea of routines and rules around doing tasks. There’s no freedom in that, they’ll say.

But routines and rules can be surprisingly freeing. For example, having the ‘rule’ to go for a walk every day, you are now free of that decision. The decision is made. You have to make time to go for those walks.

This is really important when it comes to documents and records control. Start with an established rule for file naming. So much time is wasted on projects because of non-existent file naming conventions.

In late 2020, I realised that one of the few times I was spontaneously smiling, was when I saw a dog or cat. I don’t want to own one, but there was something to it. And so, I started volunteering at the RSPCA. Lots of spontaneous smiles ensued. The kittens don't sit still for long.

When dealing with 25 different cats each week, you learn that even though they are all cats, they all have different personalities: there’s no standard to expect. Some are cuddly, some aloof, some inquisitive.

Kind of like people. We’re all people, but we’re all different.

Writing standards, procedures, or policies is a specialised skill. I was pleasantly surprised with some conversations I had recently, in which that was reiterated. Different people, in different contexts, said the same thing: a person can be really good at doing a task, but that doesn’t mean they are good at writing it down.

Different skills are utilised to write a method statement, versus the skill to execute the activity. And then it’s something else again to audit a procedure and judge whether it’s appropriate. Reviewing an existing procedure is very different to writing the words in the first place.

Many skills in the knowledge work arena are based on knowledge and repeated application of that knowledge. Report writing, contract reviews, budget forecasts, status reports, and schedule updates are examples of project engineering activities that rely on skills, knowledge, and experience in order to be done well.

There’s another angle to knowledge work that is harder to measure or recognise: the craft side of knowledge. Traditionally, a craft is related to production of a product: weaving, cabinetry, pottery, or a canoe. It’s useful to recognise that knowledge work products have a craft angle as well: the artistic side of knowledge.

A definition for ‘policy’ is ‘a deliberate system to guide decisions and achieve rational outcomes.’

So, taking that definition apart, in the context of an organisations’ documents: a policy is a deliberate document. It shouldn’t be hidden or mysterious or hard to understand.

A policy is there to guide decisions: this is probably not appreciated enough when we read or develop policies. It should help the person subject to that policy to make good decisions.

And finally, policies help achieve rational outcomes. There’s some hidden weight to that. The purpose of a policy is the outcome being rational, and achievable.

Organisations in the transport, infrastructure or engineering arena usually have several ‘services’ departments, such as Human Resources, Finance, Quality, and Risk/Safety. These departments provide internal services to the main function of the business. Sometimes they’re seen as a cost centre, while the operations departments are the profit centre.

Unfortunately, not only are they a cost centre, it seems these internal services departments also add hurdles to the business. Perceived hurdles such as formal procedures, regular meetings, and more forms to fill out. They should rather be aiming to remove hurdles, so that the main function is efficient, standardised, and reliable.

The overwhelm of meetings is not a new phenomenon. There are many books about meetings; I’ve recently found the 2015 Pittampalli one called “Read this before our next meeting”.

He has solid ideas about meetings, and how to make them more efficient. Such as: before it convenes, decide who is the decision owner. Replace meetings with one-on-one conversations. And schedule regular meetings as ‘tentative’, so that someone has to declare it’s not tentative for it to go ahead.

These are good strategies. Also consider that some meetings are for social validation, connection, and interaction. And that should be ok too.

In the olden days, when I first started working, there were typewriters and hand-written memos. Let me assure you: there were few problems with version control back then. When you hand-write a document to get typed up by someone else, there’s no desire to have multiple versions.

It’s very different now of course. Anyone who works with documents knows the problems with version control. And it’s especially painful for documents like standards, new procedures, or at any stage of design.

Version control is a key documentation strategy. Getting the version control process right in a business saves so much rework.

There’s plenty of advice on how to lead better, how to manage a project better, how to manage risk, and many other ‘how to’s’ out there.

What is surprisingly lacking in the advice given, is what the artifacts of the task are, or should be. By artifact, I mean records and documents.

Managing risk? A risk register is an artifact. Managing a project? There are plenty of project artifacts (budget, contract, schedule are just the beginning). But what should be clear is a standardised set of artifacts defining what is left behind (besides the successfully completed project output, of course).

The ideas of “information storage” and “databases” are interchangeable. A database is used to store information. To store information for easy retrieval, we need good databases.

Databases can be as simple as a list, or a glorified excel spreadsheet. Or, it could be a complex monster of inter-related tables and datasets that might be so intertwined, no one can unravel it.

Before starting a data collection exercise, consider the purpose, usage, and lifecycle of that database.

A standardised approach early in the data gathering project means a structured starting point, and a better long term use case of the database.

Some repetitive activities don’t need to start each time with a blank page. From the iteration of previous experiences, there’s bound to be a framework, checklist, or guidance posts to help accomplish the task in a reliable, repetitive way.

This applies to the obvious things like quality control processes and measurement accuracies. It also applies to bigger picture activities like forming a new project team or writing reports. These tasks have been done before, by someone, and so there no need to start with a blank page.

Sometimes the freedom of a blank page is absolutely appropriate. Sometimes, it’s not.

The metaphor of the iceberg shows, with a recognisable image, how we sometimes only see a small part of something bigger.

What we see is above the surface, while an enormous amount of substance and depth to the issue is unseen, below the surface.

Any masterpiece we create can take on the image of an iceberg. Whether during the regular achievement of our daily tasks, or finishing a report, writing a new process standard, or coming up with a breakthrough innovation that will change the world: the product is not always indicative of the iterative process involved to get there.

Standards allow us to set expectations. A standard gives us criteria for a basis to make a judgement. There is a model or a pattern, for repeatable outcomes. With expectations set, and agreed to, we can have confidence in the reliability of the results.

Standards are relevant in our personal and our professional lives. Minimum standards are applicable in the right context. Other times it’s reasonable to strive for higher standards.

A minimum professional standard is called competence. Higher professional standards build a career. Minimum personal standards are basic societal behaviour expectations. High personal standards represent ethical and principled behaviour.

A standard is ‘an agreed way of doing something’. The ‘something’ can be the agreed way of making a product, managing a process, delivering a service, or supply of materials. Standards also apply to an ‘agreed way’ of societal things like how we drive, how we interact online, or how we learn new things.

Standards exist within businesses, within ourselves, and within our professions. Standards can be spelled out clearly, or can be unspoken and mysterious.

Setting high standards is both a help and a hindrance. It helps achieve great things, but, can lead to disappointment when they aren’t met.

“Life is what happens while you’re making other plans.” John Lennon said that, to encourage experiencing life in the moment. Ok, maybe sometimes.

Plans are important to making progress. Those who spend the time to make plans tend to have a certain standard of expectations: for themselves, and for others. Those who plan tend to know what needs to be done. Those who don’t make many plans (and there are plenty) live for spontaneity. Ok, but then you can’t know when you’re making progress.

A gold-standard plan is, basically, a proposal for doing or achieving something. Sounds good to me.

Did you read the title as “resume”, as in, restart, revive, begin again, start again? That’s what I meant. Or did you read it as “resume” as in, CV, curriculum vitae, summary, what you send with a job application? Maybe it’s a colloquial thing, as the dictionary didn’t have that definition.

The English language is funny that way, with homonyms like this. Both are applicable for me today. It’s October 1st so I’ll “resume” the ole 100 words a day habit, and, being self-employed means an ongoing effort at summarising my background and skills, in a “resume” sort of way.

I grew up and went to school in the northern hemisphere (Calgary). I moved to Brisbane in 1997, so I’ve now lived in the southern hemisphere for 24 years.

In the northern hemisphere, September marks the beginning of autumn, and the new school year. It’s a time to hunker back down to work after the summer holidays.

It’s hard for me to shake the feeling that September represents a ‘new beginning’. That feeling is baked into me.

#100wordsaday is taking a break for the month of September. It’s a good time to put some of the 100-words into a book.

It’s baffled me for a while, trying to differentiate between project engineering and project management. Because in my experience, when you’re doing project engineering, it sure feels like you’re managing.

In reading this competency for Pipeline Project Engineering (but it could be for any type of project), I’ve now figured it out: the “project engineering” is the expertise around managing the project documentation.

This could be the contractual, regulatory, or technical documents. It could be any of many documents such as the design basis, approvals documents, execution plans, QA plans, variations, or the all-important closeout/handover documents.

Project engineering is documentation.

The inspection and testing of the steel pipe for pipelines is a key step in the manufacturing process. And while an engineer working with pipelines mightn’t undertake the inspections themselves, we certainly should understand the process of appointing inspectors and overseeing the program.

This is definitely an area of expertise that deserves more attention from Australian engineers and materials scientists.

To understand inspection requirements, we should understand the chemical composition of line pipe steel, the writing of the pipe specification itself, and manufacturing methods. There’s a lot to know, and it’s a fascinating area to be working in these days.

This contemporary competency applies no matter what industry you work in. In our context, it’s for pipeline construction crews working in remote areas, in some designated FIFO arrangement (28 days on/9 days off was my experience).

In addition to knowing the symptoms, factors and consequences of fatigue, engineers working with pipelines should also understand a few other things particular to pipelines. There’s often a camp environment involved, long driving travel times, dusty work conditions, and repetitive tasks.

Managing these risks is easy to write but hard to enact. Try strategies such as work cycle planning, task rotation, and fatigue recognition.