Why work programs work

The short of it

Audit work programs work because they require you to think about what you are going to do before you do it. They take away the stress of worrying how you should approach a certain audit issue for 90% of the time, because you have thought about it before your audit team was on the ground, facing the problem.

The practice of writing good audit workprograms is disappearing

I scout the internet for new audit workprograms quite often. My first traditional port of call is Auditnet. They provide a good selection and I understand their premium program is very good. Still, with constrained budgets there are other acquisitions which get priority, so I look around.

I don’t necessarily look for work programs I need right now, I like to have the feeling that somewhere in my dropbox library is an audit work program for most of my standard audit needs.

The problem is that even though the internet is growing, I feel I am getting less and less relevant audit work programs in my google search results. Perhaps the art of writing good audit work programs is disappearing?

Defining an audit work program

An audit work program to me has always been a detailed description of the audit procedures to be executed to adequately cover a certain aspect to be audited. It is a step-by-step overview of instructions which allow for even a person with limited training to execute specific steps in an audit.

Audit work programs are not written for stupid people, although the first time you see one, you may think they are. Rather, they embody some of David Allen’s key GTD principles … by getting your tasks out of your head and on paper (or whatever medium) you reduce part of the stress. In order to get to that point, you need to make the investment of developing audit work programs. But what’s the real added value?

The relevance of the audit work program

Internal auditors can encounter significant stress. There is a limited timeframe to execute the audit. Requested documents are not always ready on time. Unexpected findings come up and need to be dealt with. Auditees are stressed and react negatively to the auditor. And now I’m only describing daily audit situations. At times like that, it’s good to know that a lot of what you need to be doing is well explained in a structured and executable set of instructions. If you don’t need to think about how you need to do what you do, you can spend more time understanding what is going on based on the information you gather.

Beating procrastination

There’s another advantage. Auditors are (like) people. Like everyone else, we can succumb to procrastination, to postponing what needs to be done and chasing the interesting finding. On occasion, we can even chase our own tails. But then the work is not getting done.

The point of the audit work program is to describe the work to be executed in such manageable chunks that the threshold to execution diminishes to the point where the resistance to doing the work is low enough to push us forward. Again, we are protecting ourselves from our own procrastination. And we ensure we do our job: providing the audit committee and the board with information on due diligent behavior of our auditees.

Happiness through workprograms

It may seem a bit bizarre, but in my professional life there are few situations I’ve been consistently more happy than when developing and executing a good work program. It holds you with your nose to the ground and close to the work. It requires some deep thinking on how you can most effectively and efficiently execute an audit step. It helps you focus on the facts and the figures, not the narrative surrounding them. It helps you to see clearly.

Of course I had my epic project proposal wins when I worked as a consultant. Of course being involved in a green field brainstorming and suddenly seeing the way to a solution is a kick. And taking a group of people through a discovery process really gets the blood flowing.

But for professional satisfaction … nothing beats a good, well developed audit work program. When I’m in the middle of development or execution, it always brings a smile to my face. Because I know that whatever comes out of the audit, our work does not go where our minds have not gone before.

Simplifying risk models

A brief history

The relevance of using risk models as the basis for risk management was disputed in the beginning of this century. It actually remains disputed as an approach by a number of authors. In the early ‘00’s, leading risk management advisory companies did not see the reason to use models. They felt it impeded organizations from assessing the entirety of their risks. In the late 1990’s, Arthur Andersen was the first company to start structuring risk models as a basis for the structural implementation of enterprise risk management. Some of their risk models remain as risk models you can for example find in Protiviti’s Knowledge Leader.

The wider adoption of risk models

Risk models really came to the fore towards the end of the ’00s, when experiments in implementing enterprise risk management or ERM systems showed a significant flaw in the prior reasoning: people did not share a mutual understanding of the term ‘risk’ and even failed to agree on a common definition for the most traditional of risks.

A solution wasthe development of risk models: industry specific structured overviews of potential risks which could occur in companies active in a certain industry, with a clear definition of what the risk means in agreed upon terms. Agreed upon terms would be adapted to company specific terms, in order to limit the risk of misunderstanding and thus mistreatment of a specific risk.

The challenge of today’s risk models

In our quest to increase the transparency and the unified interpretation of risk models, I fear we may have overcomplicated them. Overcomplicating a risk model – or any model for that matter – lowers the adoption rates by users. Therefore, while the move towards a more complex set of risk models was necessary to develop enough detail in the risk models, we now need to make the reverse move. This move should not be towards no risk models, but towards a list, an overview of possible risks.

The added value of risk management

Because what is the actual added value of risk management? It is the optimization of our response to priority, identifiable risks if and when they occur. Risk management should NOT be a central pillar of a management system. It adds to better risk response, and can be added to ways in which an organization is run, but should not be the central element.

In essence, even if no management exists, this would not preclude risk management systems to exist across an entity or a group of entities.

Let me explain: we see the demise of certain (types of) corporations, especially, but not only in the services sector. These are being replaced by decentral, distributed networks of independent contractors which come together on a project-by-project basis. Perhaps more than ever, these decentralized networks need risk management, but they inherently do not have a management structure to, well, structure their risk management.

The trigger list in Getting Things Done

So, how do you manage risk in a distributed, decentralized environment, or in any type of environment for that matter, in an as cost-effective way as possible? You develop a risk trigger list.

Actually, this idea is not new. I borrow the central idea from David Allen, who in his excellent book called Getting Things Done refers to an incompletion trigger list as an essential tool for the brain dump, in essence a way of clearing any issues in your head and getting them on paper, for further processing.

The trigger list is a very powerful tool: it is small enough (David Allen’s trigger list covers at most 2 modest pages) to be used on a regular basis and yet complete enough so all elements you may have forgotten can be dealt with.

The Risk trigger list

In order to enhance adoption of risk management as a tool, in order to make it usable on a regular basis and complete enough to deal with most risks one could forget, I would suggest to develop a risk trigger list per project, process, organization or even industry. This trigger list, which should not be more than 2 pages long, contains trigger words, words that will result in a comprehensive listing of most of the relevant risks which can occur in that process, project, organization or industry.

You may be surprised. At least per industry, I believe at least 50% of the risks will be the same across organizations. The list will partly be generic, and partly specific to the organization, the process or the project. Developing a risk trigger list should be one of the first responsibilities in any new process or project.

The relevance

By simplifying the comprehensive risk models we’ve developed in the past 10 years and condensing them into risk trigger lists, we may reach the critical threshold to wider adoption of risk management principles, which will in turn lead to better managed processes, projects, organizations and industries.