In previous blog posts I introduced Agile project management for auditing firms. Agile is a methodology often applied in software development. The concept behind Agile is that over time requirements change, some features loose their importance and teams are self-managing using customer input. In auditing projects are also executed in teams. These teams are in a way self-managing and an engagement consists of tasks (features) with changing requirements and importance. This blog series is based on the Agile Manifesto. The third and last adage is:
Customer collaboration over contract negotiation
No, you definitely need an engagement agreement. You do need to write down budget arrangements. One of te ’53 measures’ (5.2 in ‘In het publiek belang, het kan echt beter!‘ a council document for Dutch auditing firms) is the budget analysis in advance and afterwards with insight for the customer in the way the time is spent. That’s often a problem with budget arrangements. The conditions aren’t clear to the customer and the teams doesn’t communicate on additional work outside the arrangements.
This is where Agile steps in. Using an Agile approach the most important tasks are executed first and periodically the customer receives feedback on the project progress in a ‘sprint evaluation’. In Agile software development projects sprint evaluations are parties. Everyone is welcome to join. Of course the development team is present but when a coworker, a boardmember or the client wants to be present that’s ok. The more the merrier. During the evaluation there is a demo of the progress and celebrated afterwards.
Imagine applying this on audit engagements. The biggest risks in the engagement are identified in advance. There are activities planned to mitigate the risks. The outcome of the activities can go to ways: The risk is reduced accordingly or additional tasks have to be executed, in other words additional work that’s not part of the budget.
By discussing the progress the customer becomes enthusiastic about the way the project advancement and involvement. Furthermore it’s less difficult to address problems in the execution and the need for additional work. There might be other ways to prevent budget overruns. The customer will be involved in the decisions that must be made on new insights that arise during the project. Maybe the customer can accelerate in delivering information. Maybe the customer can hand over digital financial data for analytics. In some cases the customer just has to accept higher costs because the project had become more complex than foreseen. These discussions are needed between those who are involved (customer collaboration) in order to overcome the unseen problems. One cannot just rule these discussions out in a contract negotiation.
Focudis for customer involvement
First of all Focudis allows you to actively involve the customer in the audit. Tasks can be assigned to the customer or employees of the customer. It’s also possible to share the analytics dashboard with the customer.
Furthermore Focudis by design handles tasks based on priority. The biggest risks are addressed first and the most effective tasks are executed first. That way it’s very easy to show progress to the customer during a periodical meeting like a sprint evaluation.
And last but not least Focudis registers progress not only in the number of completed tasks but also in the percentage of mitigated risk. When you show your customer you were able to mitigate 50% of the risk with only 25% of the budget, everybody has a good vibe.
If the project doesn’t go very well, you can show the customer that his endeavors can capture a large portion of the risk in a faster way. Even when the situation is insoluble, the customer has insight in everything you did to prevent a setback and understands the seriousness of the situation.
In these three blogs I applied the basics of Agile project management on auditing. I explained how the concept of Focudis supports an agile way of working. Applying Agile principles isn’t limited to the use of tools. How you design the audit plan, which tools you use and whatever checklists you apply doesn’t matter for using Agile basics. In the next blog I’ll summarize what we’ve discussed on Agile so far.