To increase the amount and depth of the analytics performed, steal some agile methods, and apply them to your audits.
If you’re not familiar with agile methods, check out the first 5 topics listed here (just click Next at the bottom of each page; the topics are quick to the point and full of pictures).
Briefly, agile projects are performed in cycles, or iterations, rather than in a long, linear-waterfall fashion, which is: do all planning, then field work, then reporting. Each iteration of the project creates some value and includes feedback, which is used in the next iteration to increase the value of the project.
A while back, a reader named Kyle and I had a conversation about analytics.
It started with his reading my Excel:Basic Data Analytics post where I list a number of procedures that anyone can do in Excel.
Kyle said he was expecting some “super sophisticated process & methodology that works like magic.”
In the previous post, Create a Team for Audit Analytics? Part 2, I explored the pros and cons of expecting all auditors to develop a level of data and analytic proficiency.
These auditors would continue to do audit testing that involves analytics as well as testing that does not involve analytics. In addition to keeping up their business skills, they would be learning and upgrading their data analytic skills.
In the first post of this series, I reviewed some of the pluses and minuses of creating a dedicated analytics team.
However, a third option exists, which is sort of a hybrid between having dedicated analytic auditors doing all the analytic work and requiring everyone to increase and develop their data and analytic skills.
Let’s explore the hybrid method in this post, and wrap up the series with a few final thoughts.
This is the third post of a 3-part series…
In the previous post, Create a Team for Audit Analytics? Part 1, I explored the pros and cons of developing an analytics team.
This team consists of analytic auditors who are dedicated to analytic projects; they would NOT typically manage audits or testing that did not include analytics.
In this post, let’s explore another option for managing and growing analytics in an audit department — expecting all auditors to develop a level of data and analytic proficiency.
This is the second post of a 3-part series…
Once your audit team has proven the value of doing analytics consistently, the next question is: Do we create an analytics team and have the team do all (or the majority) of the analytics?
Or should we expect all auditors to develop some levels of analytics proficiency?
Of course, this question often comes a bit further down the trail on the analytics journey, but I think the sooner it is decided, the better.
This is the first post of a 3-part series…
Here’s the 5 things I’m hoping will change in 2018 regarding ACL.
They are all related to each other and feed off each other…
A recent IIA article on building an analytics function in internal audit is dead wrong.
At least on one major point, anyway. And it’s a big one.
As the tombstone reads, this point is D.O.A (dead on arrival, or more specifically, dead on analytics).
The article, Building a data analytics program, requires IIA membership to view, and is located at https://iaonline.theiia.org/2017/Pages/Building-a-Data-Analytics-Program.aspx (that’s actually good, as it means a lot fewer people will ever read it).