I Love (and Hate) Standards – You Should Too

I confess to having a love / hate relationship with standards. On the plus side, having an agreed way of doing things is incredibly attractive.  There is no need to spend long periods trying to design a system; shared terms, concepts and processes; easy collaboration between different groups.  So when they work well, standards are great and definitely have a lot going for them.  Yay!

However, there are also drawbacks.

Sadly, many standards are badly written and difficult to follow. Sometimes this is due to the complexity of the topic which makes it hard to boil things down into a simple one-size-fits-all document.  Sometimes, the people writing the standard are experts in the subject but not experts in writing standards which means that the expertise is lost in a confusing, poorly written document.

If you understand your field but don’t understand the standard, you probably aren’t the problem.

Alternately, the lack of clarity could be because the standard was the work of a committee and, by trying to accommodate everyone’s ‘pet’ ideas, the overall standard becomes incoherent. Worst of all, it can sometimes feel as though the standard is deliberately vague.  In these cases, you might also find that the issuing organization also sells training courses to teach you how to use the standard….  Grrr!

In light of this, we need a way to maximize the upside (more love) and minimize the downside (less hate).

Note: when I say ‘standard,’ I mean a recognized reference document which provides a definition, structure, top-level guidance and key processes for an activity.  These can be internal documents or something developed by a third-party like an institute or international body.  From a risk perspective, ISO 31000, the enterprise risk management standard, is probably the most recognizable.

Maximizing the Upside of Standards

For all of the positive reasons above, I definitely think it’s worth your time becoming familiar with whatever standards might be applicable for your organization. However, because of the negative elements I have outlined, I appreciate that this can be hard.

Luckily, Riskacademy is all about making things simple so here are three ideas to reduce the negative elements of working with standards. The DCDR risk software project means I am having to work with a wide range of  standards, no matter how awful these might be, and this is what I’m doing to minimize the pain.  Hopefully these three tips will help you too.

To Comply or Not to Comply?

Before we go any farther, I must stress that if you have regulatory obligations or are required to adhere to standards by law, you have no choice: you must comply.  Deliberate non-compliance almost always ends up with some kind of legal process.  Even if it doesn’t go that far, you are still creating a negative, toxic culture.  If management sends the signal that the organization will pick and choose which regulations to follow, people farther down the organization will follow suit and begin to ignore any guidance they don’t like.  This cannot end well and will create a whole host of risks that you don’t want to deal with.

To paraphrase Nike, when it comes to regulations, just do it!

Note: even when a regulation is mandatory, some of the following points still apply, so read on.  You may find that the ‘must do’ sections of a regulation are not as bad as these first appear.

Identify the Core Principles

Most standards will include many different sections but the core principles are, in my mind, the most important.  These principles boil everything down into simple statements that you can use to guide your work.  For example, the second principle in ISO 31000 states:

“Risk management is an integral part of all organizational processes”

ISO 31000 (C) ISO

From this, I know that ERM has to be integrated.  It has to embed across the whole organization and it is part of routine processes.   A common question when considering ERM is ‘when and where do we apply this?’ and principle two answers this neatly: everywhere and all the time.

Exactly how I make this happen will depend on my organization. I know that ISO 31000 also contains suggestions to help me with ERM integration but that is just my guidance and is not mandatory.   I can use this guidance to best suit my needs, but I don’t need to slavishly follow the standard word-for-word as long as I am adhering to the overall principles.

This leads to the next suggestion…

Always Check the Small Print

In many cases, the standard will contain words similar to these.

“The user must follow the general SRA method but may use customized methods to conduct the SRA.  As long as the process is consistent with the following five steps, the method considers all normative language in the standards, and the end result meets the same objective. “

The American Petroleum Institute (API) STD 780 Security Risk Assessment (C)The API

This gives you enormous flexibility “so long as the process is consistent with the following five steps, the method considers all normative language in the standards, and the end result meets the same objective”.  This is not dissimilar to how we apply principles: you have to still meet the same objective but the standard gives you flexibility as to how you achieve that.

Many standards have a clause like this or definitions somewhere to help you determine what is mandatory versus what is simply guidance.  Some documents which look like standards may even include clarification to stress the contrary.

As a guide, this British Standard takes the form of guidance and recommendations. It should not be quoted as if it were a specification or a code of practice and claims of compliance cannot be made to it.

BSI 1120 – Crisis Management – Guidance and Good Practice

Differentiating between the mandatory elements of a standard and what is simply guidance gives you a lot of flexibility during implementation.  Even if you plan to implement the whole thing eventually, beginning with the mandatory elements allows you to take a layered approach instead of trying to tackle everything at once. The key point is that this is totally permissible – it says so in the standard itself.

This also allows you to work around flaws in the standard which, as I mentioned in the introduction, are sadly too common.  For example, most ISO standards seem to include the ‘Plan, Do, Check, Act‘ cycle whether it is applicable or not and the API standard mentioned above is confusing and hard to follow.  Being able to identify the mandatory elements will allow you to overcome shortfalls in the document and still benefit from the positive elements of the standard.

This ‘pick and mix’ approach leads to the last point: why are you using the standard in the first place?

What’s the Standard for Anyway?

The most important question to ask before you start implementing a standard is ‘what are we trying to achieve?’.  Sometimes there is a regulatory requirement to adhere to a standard.  However, most often, organizations are trying to implement ‘best practice’.  This is an elusive concept which usually means ‘let’s do what everyone else is doing’ – i.e. common practice – rather that deliberately seeking out what is good and implementing that.  A well researched, thoughtful and well written standard should offer a template for what good practice looks like but trying to achieve full compliance with a standard might not be as useful as it seems.

I recently spoke with Andy Cuerel of AC Business Continuity, a business continuity management consultancy, and this was one of the topics that came up.  Andy has over 15 years of experience implementing systems, primarily around ISO 22310, the business continuity management standard.  He stressed that aligning with a standard is a much easier and faster way of improving an organization without the difficulty of full compliance.  In this sense, aligning means that you are adopting all the same work practices and processes outlined in a standard but without taking the final step of being audited for compliance.

Andy noted that in his experience, implementing 75% of a standard will generate the majority of the benefits with significantly less cost and  disruption compared to full compliance.  He also cautioned that the last 25% of implementation required for full compliance can be hard to achieve.  It can even be detrimental to the overall operation of a business if not approached carefully.

This ratio is similar to the Pareto’s Principle or the 80/20 rule where 80% of the effect or benefit comes from 20% of the cause or input.  I am also a strong believer in this approach having seen it’s effects in many situations. I apply the 80/20 rules to a lot of the Riskademy material and it also underpins the DCDR app.

Be sure to think about what it is that you are trying to achieve before you charge forward and try to become fully compliant with a standard. Remember that the purpose of a standard is to improve an activity, not simply to receive a certificate of compliance.

Be a Lover, not a Hater

As I said, I have a love / hate relationship with standards but I have applied these three rules successfully to maximize their usefulness and to minimize the pain.  I hope these also help when you are considering how to best implement a standard or regulation.

Remember, when it comes to standards, be a lover, not a hater!

What standards are applicable to your business? Send me a quick email to let me know.  It would really help me know what I should be reading up on.