Local Authority Internal Audit Virtual Forum

25 November  

Please note:

• All Institute responses are boxed and highlighted blue
• Where the CEO comments in that capacity, the box is blank but outlined
• Where the Chair comments in that capacity, the box is highlighted in yellow
• For confidentiality, the identities of all delegates/attendees are anonymised 

Key takeaways

• Agile auditing is built on the principle of continuous communication and collaboration, both among the audit team, but more importantly with stakeholders who gain an early awareness of observations.
• The agile mindset is about go small, limit focus and listen to feedback.
• Being agile = mindset + tools
• Go small in audit planning
  • continuous/rolling audit planning not an annual rigid plan
  • smaller audits
• Go small in audit team =
  • Incremental or iterative audit reporting, sharing earlier
  • Cyclical ways of working rather than linear (known as sprints)
• Limit work in progress =
  • Start less to finish more
  • Auditors are knowledge workers - it is inefficient to change focus
  • If you work in audit teams, keep them stable to maximise performance
• Listen to feedback =
  • Use the go small techniques to improve stakeholder engagement
  • Introduce rapid feedback loops – discussions, information sharing and building to report writing
  • Course correct (adapt) the audit approach and flex the scope as necessary
• Principles of ‘test and learn’ ‘inspect and adapt’ help create rapid feedback loops
• It is important to go smallto deal with unpredictability, volatility, uncertainty, complexity and ambiguity
• Agile auditing is an alternative delivery approach – it delivers an audit through incremental, iterative work stages, known as sprints.
• Deliver value faster to your stakeholders – introduce a metric to reduce time to valueby developing an agile mindset
• Turn up the dial on what you already do today
• Agile auditing is a change of mindset, not a new audit process.

Click here to access the presentation slides from this forum.

Chat box comments

Q The challenge for me would be around the organisation supporting this approach - it requires management being prepared to have continuous engagement and dialogue, which often can be difficult at the best of times.

A Start small, find an audit to do where stakeholder engagement is already good, having an advocate is useful, signpost at the start of the audit what you are doing, taking a different approach, what it will mean for them particularly their time commitment and the benefits such as no surprises. Once you’ve done one, you can demonstrate the value and build from there.

Q How does the approach of doing one audit at a time sit with potential inefficiencies for example caused by client unavailability?

A There is a strong case for doing two audits at a time to overcome inefficiencies with client availability, making one a primary and having a secondary audit on the go in case the main one stalls. Try not to slice time between the two though, do the work in chunks.

Q How agile does the client have to be to enable the audit/auditor to be agile?

A Stakeholders need to be more available, not necessarily more agile. It requires a level of commitment. If engagement levels are not good between internal audit and management, introducing agile can be a challenge - chip away and turn the dial up as you go.

Q I like the theory of focusing on one audit at a time. An issue we have is getting what we need to complete audits from the services, so we end up juggling multiple audits. Does Mark have any practical experience or suggestions for getting services on board for the focussed approach?

A Talking about an audit team, typically need to get engagement from leadership and oversight, a pre-meeting can be useful. Continuous engagement is at all levels.

Other comments

• I think we could definitely start building our reports as we go along instead of waiting until the end of all the fieldwork
• This has been great - we have done parts of this - what do you think about what it means for providing assurance - some stakeholders can perceive this as a means not to get an opinion!
• How does QA get applied in an iterative reporting regime?
• At present we write the recommendations for identified risks. If the onus were put on stakeholders to do this would this be a form of agile auditing?
• Where is the place for Agile in shorter 10-15 day audits?
• Have you found that there is a risk that agile auditing (i.e. smaller audits) may sometimes result in missing the bigger picture? Typically, complex systems have so many interlinking elements that smaller audits may not allow auditors to really add the value. At worst audits may suggest auditors don't understand the organisation/challenges.
• In support of Mark's comments - In a previous career I was a process engineer. It is generally recognised in this world that context switching (or picking up and putting down as I called it) normally results in a loss of 10% of a person's day and that the amount of time lost increases with the complexity of the tasks involved. The challenge is therefore how to release this time to productive work.