Reenvisioning Internal Audit: Part 2
Reenvisioning Internal Audit is a four-part series studying different approaches for internal audit leaders and audit committees to consider as they look forward and reimagine what the new normal for internal audit functions may look like.
We find ourselves at a crossroads as we look forward to the new normal for internal audit functions. How will internal audit functions pivot to follow suit? How can internal audit functions reemerge to be more effective and more efficient considering the challenges of living in a pandemic stricken world? How do audit plans get completed with remote workers and travel restrictions? Can internal audit functions effectively meet compliance requirements, such as Sarbanes-Oxley facing these challenges? The answers to these questions, and more, are at the top of agendas for chief auditors, audit function leaders, and audit committees globally.
Granted as we work to determine what the future will look like, the approach for each audit function will be driven by each business or organization’s approach to emerge and thrive in the new normal. As we study each of the different approaches aimed at reenvisioning internal audit: Lean, Agile, Innovation, and Effectiveness, understand that the right approach will vary based on function maturity, organization culture, resources, talent, technology, budget, industry, geography, and other prevailing factors. Also, note that the right approach may end up being a hybrid based on these and other factors.
Let’s continue our journey to reenvisioning by discussing the application of Agile project management practices in an internal audit function.
AGILE
So, what is Agile? Agile was originally a project management approach created for software development. Agile is an iterative approach to software development where requirements and solutions evolve through cross-functional team collaboration. The underlying principle behind Agile project management is iterative, focused, time-blocked units of work for the team. These are called Sprints. Agile was formally defined in the early 2000s by a group of programmers who wrote the Agile Manifesto and the twelve supporting Agile Principles. Agile is a philosophy that emphasizes:
individuals and interactions over processes and tools;
working end product over comprehensive documentation;
customer collaboration over contract negotiation, and;
responding to change over following a plan.
There are various focus methods within the Agile philosophy such as Scrum for project management, Kanban for process method, Lean for waste elimination and mindset approach, Feature Driven Development (FDD) and Extreme Programming (XP) for software development, etc. Our focus here will be on the Scrum framework. We will leave you to discover and pontificate the others on your own.
With stakeholders demanding more efficiency throughout the business, wanting better insights, and needing more robust controls and better processes, it makes sense for audit function leaders to look toward applying agile methods to internal auditing. Some of the benefits gained from an agile approach to auditing include a more focused risk-based approach, more in-depth insights into strategic risk areas, faster response to emerging risks, streamlined work papers, shorter audit cycles, and more timely and impactful reporting. Audit leaders must keep in mind that there is a balance between agile audit methods and adequate adherence to the Institute of Internal Auditors International Professional Practices Framework (IPPF).
Back in 2018, our friends at Deloitte developed a very robust Agile Manifesto aligned to the internal audit function. While this is one example of a manifesto, each internal audit function on the agile journey should define their own Manifesto because, as noted in the third element below - one size does not always fit all. The Deloitte whitepaper that includes this Manifesto can be found here.[i]
Deloitte Agile Manifesto. Copyright 2018 Deloitte Development LLC
How does Agile fit into an internal audit function? Just like any change pursued, there must be a change in the overall mindset. This mindset shift must include the audit team, audit leadership, organization management, the Board, and especially, the audit function’s customers. The significant themes around an agile approach include communication, collaboration, transparency, time-blocked iterations of work, frequent deliveries of work, and adaptability. Agile concepts, while being easy to understand, are not as easy to execute successfully.
In a traditional internal audit environment, auditors work off a pre-determined audit plan based on a risk assessment performed at some point in the past. The Audit Committee approves the audit plan; therefore, and any deviations from the prescribed plan would entail Audit Committee approval. Audits are performed based on the plan with pre-determined scope, approach, and timing. Results go through a painstaking iterative review process. Typically, management action plans are obtained near the end of the cycle. A final report is then prepared and reported to the Customer and the Audit Committee.
The concept of Agile Internal Audit introduces some flexibility and nimbleness to the environment. The planning process occurs more frequently than annual and focuses on stakeholder needs, audit value, and current and emerging risks. Consider Agile Internal Audit as a series of mini-projects or even continuous audits collaborated with the Customer. These mini-projects are scheduled based on risk, velocity, and preparedness. Audits have much more Customer interaction. The results of audit activities are communicated more timely. Stakeholders play a more active role in audit planning and activities. Audits can be canceled, stopped, postponed, or added based on the changing business landscape. Auditing with this approach increases focus to drive timely insights, reduce waste, and focus towards more immediate stakeholder needs.
A key success factor in understanding Agile Internal Audit is that the internal audit teams have to be empowered to make decisions related to the audit. These decisions are made along-side the Product Owner or Customer. For example, suppose during or at the end of a Sprint, it is determined that additional assurance for a task is not necessary due to its effectiveness. In that case, the team may decide that any additional work related to that Task can end. On the other hand, if a Task is determined to be not as effective, the team can decide if more work needs to be performed in that area during the Sprint or in a future Sprint. It is critical for audit function leadership to have established these parameters and guidelines upfront with the Agile teams.
Let’s dive into the structure and process of an Agile internal audit function. An Agile team has specific roles that support the success of the approach. These roles include the Product Owner, the Audit/Scrum team, the Scrum Master, Stakeholders or the Customer, and an Agile Mentor, if needed. We describe each of these below:
Product Owner – The Product Owner can be the Customer or can be a representative of the Customer’s team. This role is the liaison between the audit team and the Customer’s team. The Product Owner is actively involved with the Sprint and attends all meetings
Audit/Scrum Team – this is the core audit team assigned to the Sprint. These teams are made up of varying disciplines based on the needs and complexity of the Tasks assigned
Scrum Master – this role is specific to the Scrum framework. A scrum master is defined as a servant-leader, meaning that while the Scrum Master has responsibilities to the team, they also have responsibilities to the Customer and others outside the team. The Scrum Master is knowledgeable of the Scrum framework and supports the team with theory, practices, and rules. The Scrum Master coaches the team on overseeing Sprint Planning, managing the Sprint Backlog, efficiency in team meetings, effective interactions with the Customer, and helps to free the team from outside barriers and distractions. From the Customer perspective, the Scrum Master coaches the team on scope and goals, works to manage the Sprint Backlog effectively, and facilitates scrum events and communications
Agile Mentor – should there not be an experienced Scrum Master on the team, the team should consider bringing on an Agile Mentor from another part of the organization, or from outside, to provide guidance and knowledge to the team and to those seeking Scrum Master roles. Remember, while Agile and Scrum are easy concepts to understand, they are not as easy in practice
Stakeholders / Customer – as noted above in Product Owner, the Customer is the part of the organization that is being audited. The Product Owner would be a Stakeholder directly assigned to the scrum team. Stakeholders can include members and leaders over that part of the organization or other related parts, executive management, or even the Board.
The Agile / Scrum framework has certain Elements that are essential components to the process and phases within the Scrum. These Elements include the Theme, the Story, the Definition of Ready, the Definition of Done, and in common with other internal audit approaches, reporting including Observations and Management Action Plans. We describe these Elements below:
Theme – the Theme is the Agile term applied to the purpose of the audit or group of tasks, for example, IT Security Assessment, or Purchasing Card Review
User Story – User Stories are individual components of the audit, e.g., a single Task or sub-Task small enough to be finished within a Sprint. Examples of a User Story could be the adequacy of administrative users on the network, concerns with purchasing card limits by individual, or lost time accidents within a facility
Definition of Ready – this describes items in the audit backlog agreed upon by the audit team and the Customer as being ready to audit. Objectives, test plans, scope, and timing are agreed upon. Audit items are broken down into work segments (Tasks or sets of Tasks) that closely coincide with the duration of Sprints
Definition of Done – this defines the expected results for a set of completed Tasks. These tasks can be walkthroughs, tests, interviews, analytical results, lists of observations, a report draft, etc.
Observations – as in typical audits these are the areas that are identified in the audit that are not designed appropriately or are not operating effectively
Management Action Plans – similar to typical audits these are the action plans agreed between Customer and internal audit that will remediate the identified observations in a practical and timely manner
The Agile Scrum Cycle is an iterative, cyclical process. In the case of a software development project, there may be an end to the Scrum Cycle when the final product is delivered and approved by the client. In Agile internal audit, the Scrum Cycle is ongoing as new and reoccurring risks are continuously added to the Audit Backlog and, subsequently, the Sprint Backlog. The following diagram demonstrates the Agile Scrum Cycle:
The steps in the Scrum Cycle are described below.
Audit Backlog – think of the audit backlog as basically the continuously updated audit plan. The audit backlog is tied to auditable risks. It is the list of audit Tasks or audit segments (sets of Tasks) to be performed based on risk profile, impact, and velocity to the business or organization
Sprint Backlog – the Sprint backlog is compiled from related audit Tasks from the Audit Backlog. These Tasks are agreed upon by the team and the Customer as being ready to audit. Sprint backlog defines the list of Tasks or sets of Tasks assigned to a specific Sprint. These are the result of the Sprint Planning exercise that occurs before each Sprint commences
Sprint Planning – takes place at the beginning of each Sprint. In the Sprint Planning meeting, scope, objectives, and assigned tasks are determined by the team. Tasks assigned to the Sprint come from the Sprint Backlog
Sprint – Sprints are the iterative time-boxed (typically one to two weeks) work intervals (Audit Fieldwork). Items ready to audit (see Definition of Ready) are moved off the Audit Backlog and moved into the Sprint. When the Sprint begins the work on these audit items begins
Daily Scrum – Daily Scrums or Stand-Ups are informal meetings for the entire team that occur once per day. As defined, these meetings should be very brief (15 minutes) and should answer the following questions for each team member:
What was completed since the last meeting?
What is scheduled to be worked on between now and the next Daily Scrum?
What have you identified that will impede achieving this objective?
Sprint Review – this meeting takes place at the end of each Sprint. This meeting aims to discuss with the entire team, plus other stakeholders, what was determined in the Sprint. Areas operating effectively, observations, roadblocks, additional requirements identified, improvement opportunities, etc. Results of the Sprint Review can also impact the Sprint Backlog for future Sprints.
Sprint Retrospective – this meeting takes place at the end of each Sprint. This meeting is for the core team only and covers areas for improvement, as well as activities that went well. This meeting should be action-oriented and focused on continuous improvement of the process. Action items should be applied to the next Sprint
As you can see from above, the move to an Agile internal audit approach is a new way of approaching the internal audit's traditional waterfall method. Agile breaks audit activities down into smaller bite-sized actions that can be completed in a shorter duration. Agile increases the transparency of the audit process through open communication and interactive activities. Agile allows for quicker response to emerging risks and organizational needs. Agile can also increase engagement and extend the tenure of audit personnel through collaboration with personnel within the organization, accelerated work experiences, empowerment, and career development, to name a few.
If you are considering moving to an Agile approach for your internal audit function, we highly recommend doing ample research on the pros and cons of various approaches. We also recommend talking to others who have taken the journey and finding the right Agile Mentor. With those recommendations in mind, we leave you with a few other considerations for your Agile journey.
Compatibility with IIA Standards – There is no need to reinvent the wheel here completely; various sources have already performed the research on this topic. Google is your friend. At the end of the day, audit leadership must ensure that the Agile approach adopted aligns with key IIA Standards.
The Degree of Agile – There are varying degrees of adopting an Agile approach to internal audit. This is driven by each organization’s willingness to adapt to the mindset. Where some audit functions dive in with both feet, others only dip a toe in. If Agile is the approach for your function, do the legwork to research, understand, sell, and obtain buy-in from stakeholders as you progress down the Agile highway. Effectively managing change is key to success. We recommend taking small steps into Agile, consider taking one or two audits through the cycle, have a final retrospective, and determine as a team if Agile is the proper approach for your function.
Delegation of Decision-making – This is not an easy transition for many. As mentioned above, empowering audit teams to make decisions during the Sprints allows for flexibility and nimbleness in the Sprints. It keeps the audit focused on stakeholder needs, audit value, and the right risks. Audit leadership does not just step away in an Agile environment. They still provide oversight, but empowering Sprint teams to make quick decisions on the fly, is vital to the agility of the approach. This empowerment needs to have parameters set upfront by audit leadership.
Documentation Standards – Don’t let that junior programmer steer you wrong about the Agile methodology. You still have to do documentation. You will still have planning documents. You will still have request lists. You will still have work papers. Reports may, in fact, be considerably shorter and to the point, and there may be fewer iterations of draft reports. Overall, your focus on documentation may shift in an Agile environment, but standards still have to be met, and as we all know, auditors do get audited.
If you missed part one of this series you can find it on our blog at: Reenvisioning Part 1
In part three of this series, we will discuss the application of innovative and emerging technologies to internal audit functions.
[i] Becoming Agile: Elevate Internal Audit Performance and Value. (2020). Retrieved 19 August 2020, from https://www2.deloitte.com/us/en/pages/advisory/articles/agile-internal-audit-planning-performance-value.html