Can We Make Internal Auditing "Agile"?

The Idea: Companies and IT developers are increasingly using agile, rather than “waterfall,” methods to create systems and applications. “Where the waterfall approach is based in predictability and processes, an agile approach focuses on adaptability and response time to changing requirements.” Could we do the same for internal auditing?

The Execution: Wikipedia’s entry on agile software development notes: “So-called lightweight agile software development methods evolved in the mid-1990s as a reaction against the heavyweight waterfall-oriented methods, which were characterized by their critics as being heavily regulated, regimented, micromanaged, and overly incremental approaches to development.”

As an auditor, I understand and appreciate the need for agility and less needless red tape/documentation/control. Getting stuff done (faster, cheaper, better) is everyone’s goal! However, I also understand the importance of quality controls and standard processes to achieve the objective of delivering reliable IT systems.

Similarly, our internal audit clients expect us to have a consistent and standard audit approach in order for them to deem our findings credible. And our staffs need a framework in which to operate. Having a methodology that enables delivery of quality work is the heart of our professional standards. Without a standard methodology, how could we be rightfully called “internal auditors?”

And yet, our audit cycle times can be longer than desired. Our output may be different from what our stakeholders expected. Our quality assurance processes may introduce constraints to efficiency that fail to produce more value-added insights.

I’ve been thinking a lot about “agile governance” (and by this I mean the governance of agile projects rather than more responsive/flexible oversight processes). Can these terms be squared or is agile governance an oxymoron? What should agile decision making, documentation, and oversight look like?

To improve internal audit’s adaptability and response time, we have begun a project to look again at our methodologies, in particular our approach to large program governance (project health checks (PHCs)). While our engagements are intended to be an objective perspective on risks to a project’s successful outcome, our stakeholders are sometimes confused about our objectives, scope, testing methodology, and deliverables. Mistrust and conflicts can develop. Staff members assigned to these projects seek step-by-step procedures for working in an undefined, changing environment. We need to find a way to standardize our approach to oversight of strategic projects and gain our stakeholders’ acceptance of our role.

In the end, we decided to have an objective facilitator walk us through a “lessons learned” process, first internally as an audit team and then — the scary part — to ask those who have worked with us on PHCs to participate in a workshop to vet our draft updated methodology. We are still in progress, but I hope to report to you that we achieved a focused, risk-based PHC methodology that is responsive and flexible to stakeholders’ requirements for assurance on strategic project risks. We should also improve collaboration among our IT and corporate project management offices (PMOs) — the IT PMO is leading the lessons learned workshop! I urge you to look for every opportunity to improve trust and collegiality when you’re not doing an audit so that when you are, you have a relationship to lean on.

Posted on Jul 2, 2014 by Carolyn Saint

Share This Article:    

Leave a Reply