Standards and procedures are created, written, and managed as documents or artefacts. In other words, they are written outputs to represent a thought process. The most important part of standardisation is in the processes that they represent. It’s almost impossible to cover every possibility, and yet the standard has to cover enough for it to be useful.

Standards and procedures make knowledge, skills, and decision-making visible. They are physical artefacts attempting to represent complex thought processes, which happen instantaneously and in a non-linear way. They codify a process, including decision-making and application of judgement in the face of incomplete information.

When standards or procedures are working well, they are almost invisible, and maybe even are taken for granted. When they are referred to often for ‘the answer’, that means they’ve achieved their goal. It means they are simple but elegant, and more importantly, understood and used. Good standards or procedures clearly represent the technical knowledge of the users who apply them.

Standards and procedures are good when they produce a reliable result. That’s the point of having standards and procedures. But like all elegant things, it’s not easy to achieve. Getting to reliability includes dealing with a lot of ambiguity.

Peter Morville writes, in a book called Ambient Findability (2005), about the slippery slope of semantics (the meaning of words):

“It’s all about words. Words as labels. Words as links. Keywords. …And words are messy little critters. Imprecise and undependable, their meaning shifts with context. One person’s paradise is another person’s oblivion. Synonyms, antonyms, homonyms, contranyms; the challenges of communication are part of the human condition, unsusceptible to the eager advances of technology.”

When designing structures to organise knowledge or to store documentation, or when trying to standardise, there is an inescapable link to the words. Those messy little critters.

There are only a few guidance documents out there about how to write procedures and standards. There are many more opinions out there than there are reference documents to learn from.

The context in which standards and procedures are written is obviously complex. This is especially true when we consider the broad technical, and organisational, issues that standardisation has to deal with.

There are competing vocabularies to contend with, and meanwhile technology comes along offering advanced machine-based standards and procedures. These don’t take into enough account the human reality of work and the workplace, even if it is mostly online.

When I went looking for the theoretical side of knowledge management, I didn’t expect to find a whole book about it. “Organising Knowledge” was published in 2007, and it is 260 pages long.

It’s a deep dive into classifying information, categorising knowledge, and developing standards and procedures to organise the storage environment. It includes the concept of findability. Being able to find information is too often left unconsidered, when building any filing or document management system.

Even though it was published 14 years ago, and technology has swept through our lives, the fundamentals of organising knowledge haven’t changed that much.

Last week our TV broke. Granted, it was a 15-year-old Sony Bravia, which had been through 3 moves with us, including an international one. But this isn’t about the TV: it’s about what we’re doing in the evenings instead.

We now play cards after dinner. Gin Rummy. And besides getting us talking to each other, it’s making us use our brains in the evening, in creative and mathematical ways.

There’s been enough written about turning off the screens, I don’t need to repeat all that. There’s something to analogue entertainment. We’re considering looking for a Bridge club next. How 70s!

Here’s a simplified, almost pithy, summary of a recent Cal Newport newsletter, “lessons learned from teaching career advice to thousands of students”.

Newport wrote the excellent book Deep Work, and many others. His advice for top performers follows along his advice for career development (also the title of another book): be so good they can’t ignore you.

• Be reliable and do what you say you’ll do.

• Find existing paths before forging your own.

• Do real work, using skills requiring interaction with others.

• Do higher learning only if there is good evidence you need it.

• Ask about others’ career success stories.

Working with procedures and standards over the years has forced me to learn that there are many ways to interpret words, or a combination of words.

For example, whether a “report” and a “record” are – or aren’t – the same thing, has been the subject of much deliberation.

Procedure writing needs to be precise, and succinct. Sometimes in achieving that, though, meaning and interpretation is lost. It’s an ongoing challenge for those writing the words. My hat’s off to all of you in the middle of these experiences: learn from it, enjoy it, and most of all, don’t take it personally.

The more we set up our business to be audited, in the safety, quality, or technical realm, the more we think about the process, rather than the process outcome.

The business of auditing has evolved to focus on auditing the business processes: auditors check that the process is in place. The scope of an audit is often about the process, rather than the process outcome. An example is the setting up of processes to be easily audited, but not really considering the outcome of the process. It’s like measuring the number of meetings instead of the achievements of the meeting.

The whole “start with why” concept has a lot of merit.

Business cases should be written with the ‘why’ in mind: know why the customer would want to buy. When starting a new habit or routine: it’s valuable to have a clear idea of why. If you don’t know why, the habit may not stick.

It’s the same with documents, procedures, and reports: ask yourself why it is being written. Sometimes it hurts to admit that maybe that document doesn’t need to be written. But if it does, in thinking about why, you’ll have a good concept of your audience.

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.