The following statement sounds like it could have come from today’s news: “54% (of [chief executive officers] CEOs) are funneling money toward growth initiatives, including emerging technologies in mobile devices, social media, and data analytics.”1 However, it is actually from a 2011 survey conducted by PricewaterhouseCoopers. Fast-forward eight years, and PricewaterhouseCoopers’ 2019 survey found that “49% of IA [internal audit] functions do not use RPA [robotic process automation], but 45% plan to within 2 years.”2 Investment in next-generation technologies such as data analytics and RPA has been a priority for almost a decade, but within the IA function, the implementation of these technologies is self-reported at only 50 percent. In the same decade, many of IA’s IT partners have successfully implemented digital transformation (or risked irrelevancy). Project risk has not gone away, but it may not be a coincidence that IT’s acceleration in digital innovations coincided with its acceleration in Agile project management.
Before examining the application of Agile for IA teams, it is important to note a few of the key project success factors the Agile methodology was developed to maximize. COBIT 2019’s Build, Acquire and Implement (BAI) BAI11 Managed Projects identifies three alignment goals (AGs) goals for the project management process:
- AG03 Realized benefits from information and technology (I&T)-enabled investments and services portfolio
- AG06 Agility to turn business requirements into operational solutions
- AG09 Delivering programs on time, on budget and meeting requirements and quality standards
The Project Management Institute (PMI) has identified seven key performance factors that can be associated with the four goals listed previously and used to evaluate how effectively the Agile model meets COBIT® process goals. For example, goal 1 is tied to PMI’s performance factor that states, “focus on business value, not technical detail.” Goal 2 relates to PMI’s guidance to “provide the project team members the tools and techniques they need to produce consistently successful projects.” Goal 3 is tied to PMI’s performance factor that states, “include the customer at the beginning of the project and continually involve the customer as things change.”3
Agile addresses both the primary goals of COBIT 2019’s BAI11 and PMI’s performance factors. In accordance with the primary focus on business value, Agile starts by identifying desirable business features, which are presented as stories. These stories do not include the specific software modules that will be implemented; technical how-to decisions are made after a story has been understood and documented. After identifying the desirable business value, regular meetings are held to ensure that requirements are understood, to provide feedback and to generate ideas that can feed the next set of stories. Although this sounds simple, and although communication is generally easy to do, maintaining it consistently throughout the life of a project requires either proper discipline or a methodology such as Agile that makes it second nature. Audit teams have probably already examined Agile or have considered using it as a tool, but Agile also offers a disciplined approach to incorporating data analytics or RPA into audits (figure 1).
The first step in the Agile model for next-generation audit development is to identify stories. This is where big ideas are turned into actionable deliverables and where overall projects are prioritized and carved into stories.4 Planning to automate the user termination control review via RPA is a great idea, but proposing this project to an audit team and asking for an update in a couple of months is the opposite of Agile. Agile is not an approach that consists of handing out a new tool and asking the team to run with it; it requires discipline to realize benefits. Identifying time-bound stories keeps the project team from going into the “back room” for months and emerging with an unexpected result (good or bad). Rather than asking for the overall project to be executed and devising a week-by-week plan for the next three to 12 months (otherwise known as the waterfall approach), a team leader or project manager serving as the scrum master divides the project into stories that can be completed in short sprints of approximately two weeks. For example, the team may decide to automate the extraction of user lists for three applications in the first sprint (figure 2), fully knowing that this is only the first of several steps in the overall termination testing process. These bite-size stories can yield results in a relatively short period. If any of them fail, the project team knows within the sprint period (known as “failing fast”) and can quickly pivot. This is a huge benefit of Agile (failures are still counted as results). Week after week, the team keeps learning and pivoting by focusing on specific outcomes.
IDENTIFYING TIME-BOUND STORIES KEEPS THE PROJECT TEAM FROM GOING INTO THE “BACK ROOM” FOR MONTHS AND EMERGING WITH AN UNEXPECTED RESULT (GOOD OR BAD).
After dividing the project into stories and selecting the stories to target in the first sprint, the Agile approach moves to step 2: Meet regularly. At this point, the new scrum master is tasked with organizing daily “stand-ups” to evaluate the progress from the previous day, quickly identifying and resolving any roadblocks with the development team. The term “stand-up” is important; attendees at these meetings actually stand, providing the incentive to keep the meeting short and to the point. (Of course, adjustments should be made to accommodate team members with different physical needs.) This is not a meeting for everyone on the team; it is a meeting where the project development team can focus on the assigned work and avoid digressions from the product owner that are better handled during sprint planning and the gathering of story requirements. This is also not the time to do a project deep dive. The meetings allow the scrum master to identify whether team members are being pulled in other directions or key stakeholders are not cooperating—directly related to the team’s ability to address the goal of delivering benefits on time and on budget. IA professionals have been waiting almost a decade for better success in delivering digital capabilities, so they are depending on scrum masters to hold them accountable for prioritizing this project. Success does not happen by accident.
At the closure of every sprint, it is important to execute step 3—review and celebrate—sometimes called a retrospective. This meeting should be facilitated by the scrum master and attended by the development team, product owner and other stakeholders. During the meeting, the team reviews the completed stories and shares lessons learned along the way. This is an opportunity to identify any key insights that can be applied to future stories. For example, perhaps the team delivering automation for five applications identified a tool near the end of story development that might be more efficient than the one originally selected. By recognizing this after the completion of only five applications, rather than working on the whole suite of applications, the team can adapt and proactively pivot before automating other applications in future stories. Another feature of this approach is being able to ask questions early. Do team members understand how an application was built, and will the team be able to use it after a key developer leaves? This review gives stakeholders the opportunity to ask key questions that might spark better approaches in subsequent sprints and provides shared ownership of the outcome. The “celebrate” part of this step gives leadership the opportunity to recognize the contributions of the development and testing teams and encourage future progress before they repeat the cycle for the next sprint. Digital transformation requires a clear and demonstrated commitment from leadership, as lasting change has a material impact on people, process and technology.
ALTHOUGH THE FOUNDATION LAYER OF THE MODEL—TO PROVIDE TOOLS—IS NOT SPECIFIC TO AGILE, IT WAS IDENTIFIED BY PMI AS A KEY PROJECT PERFORMANCE FACTOR.
Although the foundation layer of the model—to provide tools—is not specific to Agile, it was identified by PMI as a key project performance factor. The accounting team would not be asked to give up its enterprise resource planning (ERP) and book journal entries in Excel. Similarly, the IT team should use an Agile software development program to prioritize and collaborate, not Excel project trackers; IT professionals should use a data analytics program for analyzing data sets, not Vlookups. Beyond the basic audit documentation infrastructure, the team needs analytic tools to identify and develop stories. A US$2,000 software license sounds like a lot, but it is minuscule compared to the time saved when audit teams utilize the right prioritization, delivery framework and tools. However, simply funding the team may not be enough. The leader may need to support the team through the bureaucracy of the enterprise’s purchasing department. The good news is that the team’s IT organization may already have these tools or a signed contract to procure them. This may be the best starting point to identify tools that can be acquired quickly.
Conclusion
Even after applying all the elements of the Agile model, there is no guarantee of a successful digital audit transformation project. However, executing according to Agile with discipline will result in more transparent week-to-week progress and faster identification of problems. It cannot be overstated that applying digital transformation is not a one-and-done project. Systems and their respective databases within the enterprise are constantly changing, and teams must be able to react quickly to these changes. The value of Agile is not limited to completing long-awaited RPA and data analytics projects; Agile is an operating procedure with the reactiveness to keep up with the rest of the enterprise and allow IA to lead by example.
EXECUTING ACCORDING TO AGILE WITH DISCIPLINE WILL RESULT IN MORE TRANSPARENT WEEK-TO-WEEK PROGRESS AND FASTER IDENTIFICATION OF PROBLEMS.
Author’s Note
Opinions expressed in this article are the author’s and do not necessarily represent the views of Charles Schwab.
Endnotes
1 PricewaterhouseCoopers, 2011 State of the
Internal Audit Profession Study, USA, 2011, www.utsystem.edu/sites/default/files/offices/system-audit/state-of-internal-audit-profession-study-2011.pdf
2 PricewaterhouseCoopers, 2019 State of the
Internal Audit Profession Study, USA, 2019, https://www.pwc.com/us/en/services/risk-assurance/library/assets/pwc-2019-state-of-the-internal-audit.pdf
3 Discenza, R.; J. B. Forman; “Seven Causes of
Project Failure,” Project Management Institute
(PMI), 2007, https://www.pmi.org/learning/library/seven-causes-project-failure-initiate-recovery-7195
4 Sanders, C.; “Launching a Value-Based
Analytics and RPA Program,” ISACA® Journal, vol. 6, 2018, https://www.isaca.org/archives
Chris Sanders, CISA, COBIT 5 Foundation Certified
Is senior manager of identity and access management (IAM) controls assurance and review for Charles Schwab in Denver, Colorado (USA). He has nine years of IT audit and security experience and has led the creation of multiple data analytics programs for IT audit and control monitoring groups.