Find Your Specialist


Contact Us

    Go Back

    Culture of Compliance | Making the Shift to Agile Internal Audit

    Do you ever feel as though your internal audit methodology is too rigid and misses the mark? Sabrina Serafin meets with Danny Goldberg of GoldSRD to discuss Agile Internal Auditing, a flexible new approach to achieving your objectives.

    Culture of Compliance is available on iTunes, Google Play Music and Spotify. Listen now using the player below or download for later.

    Making the Shift to Agile Internal Audit Transcript

    Sabrina: Welcome to Frazier & Deeter’s Culture of Compliance podcast series, where we discuss compliance as a competitive advantage in today’s marketplace. I’m Sabrina Serafin, Partner and National Leader of Frazier & Deeter’s Process, Risk & Governance practice.

    Today we’re talking to Danny Goldberg, the founder of GoldSRD, a leading provider of staff augmentation, executive recruiting and professional development services. Danny is a well-known speaker on communication, internal audit and risk. And today, we’ve asked Danny to talk about a trending topic, which is agile audit. Welcome, Danny.

    Danny: Thank you, it’s really nice to be with you.

    Sabrina: Danny, “Agile” is one of those concepts that has gained a lot of attention lately. Can you give us some background on what exactly people mean by agile in terms of a business process in general?

    Danny: Well, it is something that has become much more popular and trending over the past couple of years, and you know, as a whole, our profession is not very quick to innovate, change ideas. We’re a little antiquated in many ways. Something like Agile hits us pretty hard, and I think adopting it is very slow to occur.

    But I think there’s a lot of value in it. Agile comes from the manufacturing concepts of lean manufacturing, Six Sigma, Lean Six Sigma, et cetera, and agile project management from other industries and IT project management. We’re just applying that to internal auditing. When I have a client, we’re doing a discussion on how they’re going to become more agile, looking at the Agile principles. To me, it’s really good project management. Sometimes I think we spin things under a guise, maybe a consultant had an idea to spin it a different way and sell it that way.

    To a certain extent, I think Agile is kind of like that. If you’re doing a lot of the good project management foundational steps you should be doing, agile will come very naturally to you. Agile is really — and this is how I discuss project management in our project management course — project management. It’s just a conduit to good communication, good transparent, continuous communication. It forces it upon you if you’re doing good project management, and I would say agile in many respects is virtually the same.

    Sabrina: So for someone who’s first hearing about this subject, how would you define or describe what an agile internal audit approach is?

    Danny: Well, if you just look at the base definition of the word, and anybody that has any knowledge of internal audit knows that we have a pretty rigorous step by step process. You have the planning, you have field work, you have reporting. And there’s not, I would say, not much flexibility in that. It’s,”Hey, here’s what we’ve figured out, what we’re going to audit against or here’s our key risk, here’s what we’re going to audit, here’s our report.”

    Sabrina: So what you described in a lot of internal audit departments would be considered a project management approach. So how would Agile be different?

    Danny: To me, that’s a very rigid approach. Agile is going to give us more flexibility throughout that approach. It’s going to force communication, and it’s going to give the project manager flexibility to say midstream, “Hey, this doesn’t seem like a good idea, let’s not go down this rabbit hole. Let’s pull back. Let’s focus on this,” or “Let’s change our scope a little bit to focus on X risk versus Y.”

    A lot of your listeners might think, “Well, we should be doing that anyway.” And that’s become my conclusion. These are things that most good audit shops are doing in many respects, but they probably haven’t formalized why. There are a lot of very valuable principles to agile that I think a company can integrate almost immediately and find a lot of value. But I don’t think it’s going to be a 180 degree switch to your audit methodology.

    Sabrina: Danny, I understand you’ve adapted what you consider the 12 pillars of agile project management to internal audit. Can you walk through those 12 pillars for our audience?

    Danny: We went through and looked at the agile principles or “Agile Manifesto,” it’s called, and they basically have 12 Principles, and we applied that to internal auditing. These will be the guiding principles, and I think you go to different routes, you can say, “Hey, we’re going to do an agile auditing light, which is use our current methodology,” and then just put in some of these milestones throughout, or “We’re going to rewrite our whole audit methodology.”

    I think most companies that do a lot of good, structured auditing and good project management are going to do the former, that auditing light, versus reinvent or rewrite their audit methodology.

    So the twelve principles, when I’m applying it to auditing, the number one highest priority is customer satisfaction. I don’t know if you need even say that, but I think it’s a good thing to remember for the audit team, that we want to make sure we’re meeting the goals and objectives of our client. I think in a lot of ways, you can do that through doing an objective driven audit. We need to be focused on their business objectives and helping them achieve their objectives, which is the definition of internal audit. But I think a lot of internal auditors tend to forget that.

    Number two. Be flexible in your scope and objectives. Most of the time when we define in planning, here’s our key objectives, here’s our key risks. I don’t know if that makes sense. If we go down a pathway, and it’s the wrong pathway, or it’s not the most effective path, why wouldn’t we want to change it? So, it gives the project manager a little more flexibility to revisit the scope and the objectives throughout the project as necessary.

    Number three. Frequent formal check points. In agile auditing, these are called stand ups, where every morning or every afternoon, once a day during fieldwork, you’re meeting with the project team and discussing where we’re at, what we need to do to accomplish over the next 24, 48 hours. It doesn’t have to be every day. I think it could be every few days, but we’re very focused on not building a plan for two or three months, but really building a plan: “Okay, here’s what we’re going to accomplish this week.” Again, I would say with good project management, we’re having at the very least informal meetings with our internal staff and our clients on a daily basis. But again, I think this is just a conduit to facilitate good communication. That’s number three.

    Number four. Focus on business people and auditors cooperating daily. I think that goes very much in line with number three.

    Number five. Focus on building projects around motivated people. And this really focuses on empowering the audit team to make decisions to take that accountability on more and more. Again, in line with being flexible in scope and objectives and making sure we’re communicating effectively.

    Number six. Face to face conversation is best. To me, this is going in really just general communication skills, and I co-authored a book on communication skills for internal auditors a few years back. We’re working on a follow up right now. The focus of that is making sure that we’re communicating effectively in person. The important information, or potentially difficult issues, or the project’s off the rails a little bit. There are certain subjects, topical matter, that need to be communicated or are communicated much better face to face rather than e-mail, which is viewed as a faster way of communicating than in-person. But I would tend to argue the other side of that very easily.

    Number seven. Progress measured by transparent milestones. Going back to project management, if I’ve built a project plan, I have milestones throughout. Not just for my client but for my team. We’re going to have very transparent milestones throughout this project, and lots of checkpoints. We want to make sure the client is very well informed of everything we’re doing and why we’re doing it. We want to get them bought into what we’re doing as quick as possible. If they buy into what we’re doing, they’re going to buy into the results. We’re not going to have those arguments that we usually have at the end of audits on: “Is this a finding, is this not or more importantly, what’s the rating of this finding?”

    Number eight. Sustainable development pace, meaning, this is a realistic budget. A lot of times I believe management has their eyes on making sure that certain audits are done each quarter, and we tend to shortchange the audit at times potentially. And this is making sure that the timelines, the deadlines, the hours are realistic to make sure that we’re employing our people in an efficient and effective manner.

    Number nine. Continuous attention to quality. Just because we’re trying to move quicker and more agile doesn’t mean the quality level is going to change. With our industry, I think there are many repetitive levels of review and most of my clients are looking at, “How do we cut that down without losing the quality?” And I think there are opportunities for improvement without losing that quality.

    Number ten. Simplicity; keeping the big picture in mind at all times. We talk about this in our senior and our manager courses frequently…does the project manager see the forest for the trees? Do we keep the big picture in mind? Do we realize or do we understand that if we do X can we continue to do Y? What do these findings really mean? Does it mean anything? We talked about a lot in class, if I have this finding and the client doesn’t care. And nor should they care. Why am I testing in the first place? I have auditors tell me all the time that they go to the client with an issue. But if the issue doesn’t matter to them, nor should it, why do we even bother testing it? If we’re truly running a risk-based audit, that shouldn’t happen.

    Number eleven. We are very focused on self-organizing or self-motivated teams. We talked about the motivation aspect earlier. A good project team that’s working efficiently and effectively with each other shouldn’t need a lot of oversight. They’re guided by the project plan. They all commit to the project plan. They all helped to build the project plan, and they feel empowered and accountable to its deadlines.

    Finally, number twelve. Regular reflection and adaptation. Again, a lot of these principles can overlap. We’re focused on impact versus following the plan. When I was in public accounting, how did we learn how to audit? We went back to last year. We’d take the audit work from last year and then repeat it. Does that make sense? Is this going to have an overall impact? Going back to my comment a few minutes ago, what’s our focus and why are we doing this? We’ve got to bring a lot of credibility to the table. If we continue to bring up issues that nobody cares about, again, nor should they care about them, we’re going to lose credibility quickly.

    So those are the twelve pillars of agile auditing that we’ve developed/discussed with clients, and they tend to agree with. Probably, Sabrina, from what you’re hearing, I’m thinking that you’re coming to the same conclusions that I did when I started looking into agile auditing, is that these are very effective. They can be very helpful to an internal audit department, but I don’t think there is going to be a 180 degree turn in your audit methodology if your methodology is sound and you’re doing good project management the first place.

    Sabrina: This sounds like an exciting development in internal audit. Danny, are there any closing thoughts on agile audit you’d like to share with our audience?

    Danny: I’d like to just reiterate a couple of those key points, that agile auditing is not much different than what you’re doing. It’s going to force communication between the team, the client, the audit project manager. And maybe the audit management team is going to force those communication systems, and it’s going to make sure that we’re staying focused.

    I think from a client management perspective, it’s going to build a very strong bridge between the project manager and the client, because they’re going to be focused on continuous transparent communication at all times. It will force that upon the client and one thing that we struggle with as an industry, still, is: does the client trust us to do the right thing? Are we doing the right thing? Do they know what we’re doing? And I think a lot of those questions are answered through agile auditing or agile auditing light.

    Sabrina: Well Danny, thank you for being with us today and sharing your insights on agile auditing. You’ve given our listeners some really interesting ideas to consider for their organizations.

    And thank you for listening to Frazier & Deeter’s Culture of Compliance podcast. Please join us for our next episode as we continue to discuss transforming compliance requirements into investments in your business.

    Related Articles

    Privacy Overview

    When you use or access the Site, we use cookies, device identifiers, and similar technologies such as pixels, web beacons, and local storage to collect information about how you use the Site. We process the information collected through such technologies, which may include Personal Information, to help operate certain features of the Site (e.g., to prevent online poll participants from voting more than once), to enhance your experience through personalization, and to help us better understand the features of the Site that you and other users are most interested in.

    You can enable or disable our use of cookies per category.
    Always Enabled