Audits and assurance. What’s the difference?

What is the difference between an “audit” and “assurance?

I was recently asked, “What is the difference between an “audit” and “assurance”? I like simple questions like this as they can tease out a lot of hidden meanings and misunderstandings. These two words are used frequently and in many different contexts; most of the time people understand what is meant . . . but not always. It is only when the question is asked, that you have to put your brain in gear and start thinking.5-going-ok

As project management has grown as a discipline, a lot of organizations have come up with their own definitions or uses of these words, which were already in use in other disciplines. The terms are often qualified such as:

  • Business assurance – checking the project is viable in business terms
  • Technical assurance – checking the solution is the right on and will work
  • User assurance – checking users get what they need.
  • Quality assurance – ensuring standards and procedures are used
  • Configuration audit – keeping track on all the bits of the solution
  • Financial audit – checking the financial figures reflect reality

You also find the word “review” is often tacked on to “assurance”, hence “assurance reviews”, which can add whole new dimension.

What do the words mean?

It is always a good idea to use words which have a commonly understood meaning, as it makes communication and understanding so much easier. Most people don’t have the time or inclination to understand jargon and nuances which are used to make academic distinctions. Dictionaries are the guardians for this and so, do use them; here are some dictionary definitions of the words:

  • Audit: 1) an official examination of accounts 2) A systematic review or assessment of something.
  • Review: a formal assessment of something with the intention of instituting change if necessary
  • Assurance: positive declaration that a thing is true.

“Audit”, being associated with financial accounts and independent auditors, has an “official” connotation; audits are usually planned, formally undertaken events. In the case of financial audits there are very strict rules on how they are conducted. People are often very wary when told the auditors want to see them; they often think in terms of “passing an audit”. Personally, I have found in healthy companies people welcome audits as it gives them a chance to raise issues which they have found intractable.

“Review”, on the other hand can have a softer meaning, more “helpful” meaning and can imply less formality, although this is not always the case. PMOs often use “review” so as not to scare people! This is how accountants use the terms:

  • Audit — an intensive examination with the highest level of assurance.
  • Review — some analytical procedures conducted with limited assurance

“Assurance” is different, you can have an “audit” or a “review” but you do not have “an assurance”. It is more of a state; you are assured that your project will meet its business objectives. Audits and reviews are simply two forms of assurance related activity.

Where does risk fit into this?

The terms “risk” and “audit” are often linked; Risk based internal audit (RBIA) is an internal method which is primarily focused on the inherent risk involved in the activities or system and provides assurance that risk is being managed, by the management team, within the defined risk appetite level. It has had a very high profile since the collapse of companies like Enron and the introduction of Sarbanes Oxley in the USA. In this connection, you’ll probably come across what is often termed “three lines of defence”:

  • 1st line: business operations, who own and manage risks; risk and control in the business, ensuring the identification and treatment of risk is built into standard management practices.
  • 2nd line: oversight functions, who design policies, set direction, introduce best practice and ensure compliance to ensure the whole management effort works as an integrated whole.
  • 3rd line: independent assurance providers such as internal audit and external assurance providers.

So what can you do in practice?

So what does this all mean for you in a programme and project management context? As always, it depends. You are likely to have this problem if you are responsible for a company-wide programme and project method or if you are responsible for a major programme. If you are a programme o project sponsor then “assurance” is a key aspect of your role. You will be the one asking for audits and reviews . . . although your senior management may also call for them.

In a company context, check how the terms are already used; make contact with the internal audit department and the risk group and work with them. In a programme context, decide how much you want the programme to be driving audits and reviews and how much should be driven externally, always remembering that at a programme level, you’ll need to fill any gaps in corporate capabilities. If there is no corporate audit or review capabilities, the programme team will have to design everything, except the 3rd line of defence assurance, themselves.

 

Case study

Here is how I approached it in one major company:

The programme and project management method included roles definitions which included assurance and risk management accountabilities. There were three supporting procedures relating to these:

  1. a single risk management procedure for use at any level in the programme from work package upwards.
  2. A procedure for auditing a programme or project;
  3. A procedure for reviewing a programme or project;

The programme and project management risk procedure dovetailed into the corporate risk management process, using the same terms and activities (based on ISO 31000). This ensured ease of transfer of risks across boundaries and simpler tools support.

The audit procedure was based on group internal audit’s formal auditing process. This was only used on major programmes which had their own quality and assurance departments. By mirroring group internal audit’s approach we ensured that the method could not be challenged, ensuring that the findings and recommendations were the focus.

The review process was designed to be used by programme and project management practitioners, not directly involved in the work, to review the work of others, based on a brief given by the sponsor. It was simpler and quicker than an audit as it took a less formal approach and was supported by (but not limited to) check-lists and tools.

Portfolio management – the next frontier?

Earlier this month I was speaking at the “Passion for Projects” conference in Sweden. I must say it was a really well organised event and I was delighted to have been invited to speak there. The topic I chose to talk about covered portfolios, project, projects, matrices and maturity. I’ll go into it more in some later blogs. I’ll assume you know a little about portfolio management. Just to recap, portfolio management is all about making sure you pick the right projects to do.  In “The Project Workout” i call them “business programmes” as at the time I wrote the book, the term “portfolio” hadn’t really settled down in the way it has now.  So, in portfolio management you have to make decisions on what to do and which meet the following criteria:

  1. It is aligned to your strategy
  2. You have the resources to undertake it and operate its outcome
  3. The risks are acceptable  (i.e. robust business case)
  4. The portfolo, as whole is still balance if you take this on
  5. The organisation can absorb the change.

So, the decision makers need to bbe able to make those decisions and have the data available to verify the criteria.

I was asked a question about this: “If a programme has been approved as part of a portfolio, has the programme sponsor the authority to authorise the project within the programme, or do they all have to be referred to the decision maker at portfolio level?”

My instincts were that if the programme as a whole has been approved, then the programme sponsor should be able to make the decisions . . . however it is not that simple. It all comes down to shared impact. For example, if the programme team has all their own “ring-fenced” resources, then they can make decisions relating to criteria 2. If they share resources with other programmes or components of the portfolio, then they can’t. Similarly, if they are the only ones impacting a “target user group” (change absorbtion) then they can verify criteria 5. If niot, then the decision has been elevated.

Further, the degree of to which there is knowledge of the programme, its resources and impacts at the time it was approved also matters. It may be that the first chunks of work are pretty weel known and as long as these stay in the bounds expected, decision making can be at programme level.

As you see, what appears to be a simple question is actually very complex. The more you ring-fence resources, the greater you can delegate decisions to programme sponsors but, you lose potential efficiencies for using those resources on other work. It’s a balance. Whatever you choose, remember:

  1. What ever you do must align with your strategy
  2. There is little point in authorising work that cannot be undertaken – in fact it is really damaging
  3. You need to ensure the risks of adding this to your work-stack are acceptable
  4. You nee to ensure your portfolio remains balanced, when you add the new work in
  5. There is little point in doing work, which the operational teams, customer etc cannot accommodate in terms of change.

You’ll find a lot more about this in The Project Workout, section 3. Many organisations are only just starting to “get it”; it’s all applied common sense.

 

Is your parrot (I mean project) dead?

A risk register is sometimes not enough.Dead Parrot

Projects are not simple things to manage, even when there is a book, like the the Project Workout, to help you.  So, how do you know if your project is “healthy” and likely to meet the business objectives it was set up to achieve? How do you know it’s not well and truly dead, like the proverbial Monty Python parrot?

Well, a quick look at the risk log may help, together with a view on the issues. The schedule plan updates should show you how you are doing against your baselined plan. (what do mean you don’t have a baseline?)

These are all good ways to gain a feel; they are your day to day instruments. Sometimes, though, it’s good to rise above all the detail of methods, tools, reports and logs and consider in an holistic way, “Will this project really do what we need?”.

The Project Health Check

This is where the project health check comes in. It asks five searching question on each of the following areas of project management:

Project plan
Resources
Ownership
Justifiable case
Expertise
Clear solution
Targeted control

If anyone of those is not adequately covered, then your parrot may indeed be dying.

Let’s have a look at the output from an example:

Example of an output from the Health Check

Example of an output from the Health Check

Overall the tool’s analysis suggests the project is medium risk. Well, you might say, that’s ok, isn’t it? However, if you look at the problem areas you can see they relate to:
Solution – we don’t know what we’re building
Resources – we haven’t got anyone to do whatever it is
Expertise – we don’t fully have the expertise we need.

Now this cluster makes sense. All the management stuff is okay, but if we haven’t got the expertise for the specialist work, then perhaps that’s why we don’t yet have a solution. Also, if there is no solution yet, you can’t really know what resources you need.

So is it okay? If you are in the investigative stages of the project then, yes, you could be okay, assuming you take action to fill the gaps. If however, you are in the development stages or later, then your parrot is probably going to die.

As with all these types of tools, they are there to help you think and self-delusion in answering the questions will reinforce any delusional opinions. For that reason, it’s often good to do this type of assessment in groups and gain a consensus; the value of the discussion will far out weight the paper result.

When would you use this?

I suggest that you use at as an input to every gate decision to provide the decision makers with a summary of the ares which need attention. You can also do it “ad-hoc” in response to any concerns which have been raised.

Is it worth it?

Yes. One company I work ed with employed some consultants to review 12 of their most critical projects. The consultants used their own, very extensive, tools and check lists. When they’d finished their work they took this tool and applied it to all twelve projects. The found a full correlation. In fact, they said if the company had applied this tool first, as a filter, they could have saved 60% of the consulting fee as most of the projects were fine.

You can find the tool in the CD which accompanies the Project Workout.