Agility in Internal Audit (Part 2)

In Part 1, we outlined our thoughts regarding traditional audit methodologies and documentation requirements, and said that those are being adapted by IA functions that want to remain relevant. We also mentioned our experience with a project that adopted a prototyping approach, rather than the traditional waterfall-style (the latter is roughly how audits are currently structured - e.g. plan, scope, execute, report).

Let's now look briefly at how the prototyping approach changed our delivery outcomes, the project admin/tracking mechanism and then some initial thoughts on application to IA.

We had 12 weeks to deliver a proof of concept. Here is how the project progressed:

Traditional approach

With a traditional waterfall approach, all requirements are gathered first and the other activities follow in sequence, with limited ability to effectively adjust as the project progresses. The first draft deliverable would be available sometime after week 7, when testing commenced, with the final set of deliverables produced at the end of the project.

Something like this:

Alternate approach

The program team that we were working with suggested an alternate approach, involving six 2-week sprints. This meant that we would deliver some functionality during each fortnight, then add more functionality for the next sprint, iteratively.

So the project looked more like this (imagine a further equivalent 6 weeks at the end):

How did this enable us to deliver more than we would have?

• Enhanced refinement: Requirements gathering was simpler, faster and iterative. We started with a simple analysis of public perception. Once we showed the "users" what was possible, further refinements and requirements were identified. Our users said that without the early view, they may not have identified some of those - so with the traditional approach, we may not have got to the level of refinement in 12 weeks that the prototyping approach enabled at week 6.
• Change in deliverable: Some initial requirements were found to not be feasible - we worked through these during sprint 3 and determined quickly that the result would not add value. So we killed it, dropped another story in, and then worked on this new one in sprint 5, delivering unanticipated benefit at week 10, then refined in the final sprint.

What about project admin/tracking?

The program team selected Trello - there are many alternates, but it's the concept that we liked. No heavy project management software with detailed Gantt charts, etc.

Having been forced to use traditional project management tools on other projects, with limited benefit and significant overhead, this was a welcome change and worked for us.

It looked something like this:

Application to Internal Audit?

The benefits of such an approach have been discussed at length, so we won't go into that, but can this be applied to an internal audit?

We think that the iterative approach, combined with a lightweight enabling tool, can enhance IA's delivery of value, by:

1. Allowing for iteration - if BAU, projects, risk profiles, regulatory demands, etc. are undergoing regular change, an iterative approach allows us to flex accordingly
2. Removing unnecessary overhead - document only what we need, no fluff
3. Remaining on track - use of a lightweight tool can reduce the admin burden, but still keep a shared understanding of backlog, next steps, current activities, etc.

Will this work for your Internal Audits? Do you already do this?