Articles

Assurance - Know when to stop

A few weeks ago I gave a Masterclass for the Rail Industry Safety & Standards Board (RISSB) on the role of the Independent Safety Assessor (ISA) on Major Projects. If you missed it there's a recording on YouTube here.

LinkedIn iconEmail icon

One of the slides I showed was my 'Four Stages of Assurance' model and I've had a lot of feedback on this, so I thought I would explain it further.

I discussed what assurance is in an earlier article which you can find here, so I won't go into the detail again; but to summarise:

Assurance is the act of gaining justified confidence that something that has been done by another party has been done correctly. It's not about checking everything they have produced, but doing enough to be confident in how it has been done.

This model applies to any type of assurance whether we are looking at safety, engineering, finance, etc.

The principles below apply to any party undertaking assurance activities on your behalf, whether they be an ISA, Independent Reviewer, Technical Advisor, or your own internal team.

The Four Stages of Assurance

1 - Adding Value

The purpose of assurance is to gain justified confidence in the work that has been undertaken by another party to the standard that you engaged them for. Assurance is simply a risk management activity to make sure you are getting what you paid for, and that all minimum requirements are met. This adds value by helping to manage your risk.

Once you have been able to establish justified confidence that what they are doing is what you expected, i.e. that it is 'Good Enough' then the job is done. Your risk is managed, and you don’t need to do any more.

I call this 'The Sweet Spot' and it is when you should stop.

Assurance is about gaining justified confidence that the work is 'Good Enough' and no more!

2 - Chasing Perfect

Sometimes people use assurance to try and get something more than was requested, this is often called 'Gold Plating'. When you engaged the party to undertake the work for you, there was a clear expectation of what was required (i.e. Good Enough) but by raising preferential requirements and by seeking more or to make it 'a little bit better' then you are technically trying to get them to do more than you engaged them for, or effectively asking them to work for free.

One of the examples I hear a lot is the “make it more SFAIRP" comments to a party to try and get them to make something safer than what they were contracted to do. (Let’s not go into how non-sensical the term “more SFAIRP” is).

Assurance comments should never be preferential or require anything more than the minimum expectation that was included in the contract.

3 - Admin Overload

Another issue with assurance is that people feel the need to undertake detailed reviews of submitted documents or the application of the process. The most common types are:

  • Commenting on minor quality issues that do not meaningfully impact the delivered outcome.
  • Demanding to see evidence behind the process or for any decisions made.
  • Identifying issues as 'non-conformances' without giving any details of what they do not comply with.
  • Grandstanding statements that can’t be answered e.g. “this is how I do it”.
  • Over-inflating ratings to make even minor comments the highest criticality.

None of these add any value to the assurance process, but what they do is take up lots of time and effort to manage. The process becomes about administration of comments and then endless rounds of reviews trying to close them out.

This becomes a significant issue when there are so many comments, that any important ones get lost amongst the weeds and real safety issues can get overlooked.

Assurance comments should be limited to those that materially impact the delivered work.

4 - Crossing the Line

The worst behaviour of all is when assurance comments are not asking questions but telling the provider what to do. These can often be presented as "I'm not telling you what to do, just setting my expectations" but when the process requires these expectations to be met, they are de-facto instructions.

The problem here arises because when you instruct a provider what to do, then the liability for any impacts from those decisions now rests with you. These instructions could result in program delays or additional costs being incurred, at which point they could claim those from you. In some cases those decisions could contribute to an accident when the supplier could point some, or all, of the blame to you.

When you use the assurance process to direct the other party you have crossed the line, and your assurance model has broken down.

The assurance process should never be used to direct the other party on what to do.

We need to get this right

Assurance when done effectively is an important risk management tool. When done poorly it just becomes a waste of time and effort that adds no value and can start to make things worse. Instead of managing risk you are increasing the risk.

When this is a safety issue, those directions actually weaken the safety argument and become counterproductive.  If those directions contributed to an accident, they could result in criminal liability.

There are times when you genuinely need to provide the other party with a specific direction.  When this occurs use your change control process, assess the risks of your decision, and ensure that your internal governance processes have been followed.

Do not use the Assurance process to do this!

Please add your thoughts to the comments and feel free to send me a message if you would like to discuss anything privately.