Engaging stakeholders before, during and after audit

Throughout any project, the stakeholders should be involved. In audit terms, this means involving the senior leadership and department management of the area being audited as these would be the key stakeholders. This involvement starts at the initiating phase of the audit where internal audit submits an engagement letter to senior leadership and department management of the anticipated audit and conducts an entrance meeting (similar to that of a project kick-off meeting).

 In the planning phase of an audit, internal auditors will generally work with other stakeholders besides senior management and department management. They will work with the employees of that department; those who do the everyday operations that will help the auditor better understand the processes and controls currently in place. While this is good. I think sometimes auditors may forget to include their key stakeholders in this process to get their opinions on what they are looking for in the execution phase of the audit.

 In the execution phase of an audit, again internal audit will generally work with the department employees. They will gather documents from them for testing the key controls and processes, hold interviews with the employees involved in the various processes and controls, and discuss any issues (or findings) that have raised out of their testing for validation.   

In the Monitoring and Controlling Phase, as well as the Closing phase, the key stakeholders are again involved in the audit process in the fact that internal audit will periodically, throughout the audit, provide status updates to senior management and department managers and discuss any major issues that have risen from the execution phase. Then at the closing phase, internal audit will provide senior management and department management a final report and hold an exit meeting.

 While the internal audit process is very similar to that of the project management processes, and works very well, there are some things that can be improved on in the internal audit process. It involves including stakeholders early in the initiation phase, not just at the audit engagement letter and entrance meeting. Early on it should be inquired with key stakeholder how involved they would like to be throughout the audit. This would allow stakeholders an opportunity to be more or less involved throughout the audit as they would like to be.

 Until Next Time,

 CPack

Internal Audit Closeout Phase

The last phase of a project is the closing phase. As internal audits are a type of project, all internal audits have a closing phase. In general, internal audits are terminated by “extinction”; this is generally because once an audit is successfully completed, no further work is required. This happens after the final audit report is submitted to stakeholders and the exit meeting occurs-these are the primary closing deliverables for internal audits.

 For the final audit report, many of the same topics suggested by The PMBOK® Guide – Sixth Edition to include in a final project report are also integrated into the internal audit report. Such topics are:

  • The executive summary, which is similar to a project’s summary level description.
  • A recap of the audit objective and scope, which is similar to recapping a project’s scope objectives.
  • Summary of high-risk issues, which is similar to summarizing the risks and issues encountered during the project.

Additionally, the exit meeting held generally includes the same topics as presented in the final report and is presented to the stakeholders. Most of the items discussed are the medium and high-level issues noted throughout the audit, what the root cause is, and suggestions for remediation.

 However, there are some project closing actions that internal audit does not do during audit closeout that would benefit internal audit for performing the same audit in the future. One such action is completing a lessons learned report. Identifying lessons learned throughout the audit and summarizing them at the close of the project can be useful to the internal audit department as it describes what went well and what did not go well. This allows for, when the audit comes up again in the future, auditors to make sure they incorporate items that went well and remove, plan, or mitigate the items that did not go well.

Until Next Time,

CPack

Root Cause Analysis

Issues can arise any time during a project and there may be any number of reasons why they occur. The objective of a root cause analysis is to identify the underlying problem that led to the issue occurring in the first place, so that actions can be taken to better resolve or mitigate the issue from happening again in the future. An important part of an internal auditor’s job it helping management identify issues, discover the root cause, and help provide recommendations for mitigation.

While there are many ways to go about performing a root cause analysis, I tend to gravitate to the Ishikawa diagram (otherwise known as the “fishbone diagram” or “cause and effect diagram”). I like this type of analysis because of the approach it takes when it is unknown what the cause for the issue is; it’s like structured brainstorming. First you identify the issue. Then you branch out to identify potential causes. Each potential cause is then traced back to find the root cause using the “5 Ways” technique (a technique that asks the question “why” until getting to the root of the issue. This generally takes five questions of why).

Among the internal auditors I have worked with over the year, I have not seen many who have actively used formal root cause analysis techniques to help identify root causes to issues noted throughout the audit. It seems many people have a general understanding of what a root cause is, but don’t seem to apply formal techniques. I, myself, have been performing “root cause analysis” for internal audit finding for eight years now and I was never really taught how to perform root cause analysis techniques, nor was I required to used such techniques. I find this interesting since the Institute of Internal Auditors (the IIA), similarly to the Project Management Institute (PMI), emphasize root cause analysis techniques. So, while I am familiar with these various techniques from an academic standpoint, I have not yet utilized them in my work.

When attempting to identify root causes, I find it extremely difficult. Many times, it is relatively easy to find a surface issue and correct it, but it doesn’t seem to really mitigate the issue from occur again in the future. Performing root cause analysis seems to take a lot of practice and skill, but by utilizing the techniques, you can be better equipped to identify the root of an issue so appropriate actions can be taken to mitigate the issue.

So, as a takeaway, even if performing formal root cause analysis techniques is not required in your job, I would still highly recommend utilizing these techniques as it provides guidance and a structured process that helps you to get to the underlining issue so you are not just glossing over the surface causes for the issue without really getting down to the “heart of the issue.”

 Until next time.

CPack

The Difference between Risks and Issues:

In auditing, the terms “risk” and “issue” come up frequently. While I am no stranger to what each of these terms mean, I have not thought too much about their context and, I fear, they have sometimes been used interchangeably. This is due to the close connect that risk and issue have and what they can mean to the business.

The term “risk” generally means that there is an uncertainty that an event may arise that could negatively or positively affect the objective in question. The term “issue” is something that has already happened that could hinder the success of the objective. Basically, one is something that could happen and the other is something that has already happened. Auditors tend to focus on the impact and forget if the event noted is indeed a risk, that has not occurred, or an actual issue.

One of the primary objectives of an internal audit is identifying if the company is mitigating their risks by implementing “key” controls. Key controls are the main controls that reduce the risks that could arise during be process of business. For example, making sure that no single person can create an employee, input their time and pay the employee; as this could lead to a high risk of a single person fraudulently creating a fake employee and producing paychecks for this fake employee that they could then send to themselves. While this is an extreme example, this is the type of risks that internal auditors should be looking for.

However, sometimes internal auditors may blur the lines between risk and issue, such as identifying a minor risk and embellishing it to be a major issue. More often than not, any risk that internal audits may identify, senior management has also identified and determined if the risk is worth requiring mitigation or not; they may even perform something similar to a risk matrix. The risk matrix helps to identify whether a potential event that could adversely affect the company has a low to high probability of occurring and a low to high impact of occurring. In general, something that is of high probability and high impact should be mitigated; where as a risk that is of low probability and low impact may not be worth the cost it would take to mitigate. While senior managers know this and make decisions for the best interest of the company, sometimes auditors can get too caught up risk that they automatically feel any risk that is not mitigated is an issue, even though the impact may be nil.

It would be beneficial for auditors to really looks at the difference between risk and issue, as well as the likelihood and impact any risk / issue may occur or have occurred; really look into these items and see if they are a risk or issue that will substantially adversely affect the company or are they events not worth mitigating as they have no or minimal impact. This is important so that auditors don’t “cry wolf” every time they see a very minor risk or issue arise as this could adversely affect the credibility of the internal audit department and downplay any value they could have of providing insight to potential risks or substantial issues that may see in the company’s internal processes.

Until next time.

CPack

Incorporating Project Management Software into Internal Audits

During one of my project management class sessions we were introduced to the project management software Microsoft Project 2016. I learned that this tool is helpful for project managers in the project planning phase by helping develop the project plan into a realistic, attainable schedule by scheduling the plan out my deliverables and tasks, assigning resources and estimating costs. It also seemed to help in the project execution phase by allowing the project manager to track the progress of the project by providing a visual of how the project is progressing through task completion dates and determining if tasks are completed on time or if tasks are behind schedule. If tasks are behind schedule, the software helps the project manager monitor and rework the tasks so they can be completed.

 Now, the purpose of this blog post is not to promote Microsoft Project, but I am trying to bring awareness to the fact that Internal Auditors need to start utilizing project management software. It is a helpful tool that assists auditors in developing their audit plan schedule, as well as help in the monitoring and controlling of the audit scope, schedule, and cost. In my experience, I was not provided project management software, nor was I encouraged to utilize it in the process of planning or executing internal audits. I learned how to perform audits through trial and error and every audit has taught me something new. However, one thing I have not had much success in learning was how to be able to consistently deliver my audits on time. There was always some reason or another that caused delays, but I never quite knew what it was ‘specifically’ that caused the delay, and of course it changed from audit to audit and from year to year.

 By utilizing project management software, I can take more control over the audit schedule. l can detail out the plan into deliverables and tasks, estimate the resources needed and determined the time needed to complete each task. Then, as the project is being executed, I can monitor the progress to see if we are on track or off track. If we are off track in an area, I can get a better understanding of what is causing the delay and, more importantly, how much it is delaying the audit. I can then be better able to inform management and stakeholders what is being delayed, the cause for the delay, and when we can expect the audit to be completed. Ultimately, I can see this tool as being helpful in controlling the audit better to keep in on track and have less instances for the audit to be delayed… well, in the case where management wants to shift resources or added additional tasks, we can inform them ahead of time how such changes can impact the current audit so they can make more informed decisions.

Until next time,

CPack

Leadership: Putting People First

The other day, in my project management class, a guest speaker, Kevin Ciccotti, gave a presentation on “the 5 Best Practices of World-Class Leaders”. During the presentation, there was one best practice that stood out, to me, above the others. “Leaders put people first.” The basic concept is simple enough. Its about communicating and being open with others. It is about the fact that everyone has an innate need to belong and be accepted, but most of us are scared to let people in for fear that they will reject us. So, we close ourselves off. This best practice is about changing that. Seeking people out and talking to them; communicating with them. Unfortunately, this is one of my biggest weaknesses.

 While I sometimes engage with others in a social settings or exchanges of pleasantries in the breakroom, I mostly identify as an introvert. I prefer to keep to myself and do my work, by myself, quietly. That is where I am most comfortable. However, as many who are successful at their work, they eventually lead others and leading others requires more communication. This is the case with me. I have been an internal auditor for eight years now; five of those years have been spent in my current job doing government contract compliance audits. As such, I now find myself leading increasingly more internal audits and leading a teams that are new to the field.

 Performing a successfully audit requires a lot of communication; communication between the audit leader, the audit team, audit management, stakeholders, and the auditees (personnel overseeing the area being audited). All parties must understand and agree to the audit objective, the scope, and the schedule. It is important that there is open communication to any constraints or issues so they can be addressed. A good audit lead will communicate with each party throughout the audit so everyone understands and is apprised of what they need to know in relation to the audit, throughout the audit. This is especially important when it comes to potential issues. It is especially important to discuss any critical issues that arise during the audit with the auditee and stakeholders so issues can start to be mediated, if necessary, before results come out. It also helps to avoid many unpleasant surprises when audit results are presented.

 I have had some hard lessons over the years about not communicating with others while leading audits. While I like to think that I am getting better at it, this lecture reminded me just how far I am away I still am from being successful. I understand that talking with others may make me uncomfortable, but really the only why to get better at it and more comfortable, is to do it more often. I am more aware of how I communicate with others at work since this presentation. I know I will need to do baby steps, but I am now looking to find ways to engage more with my audit team, management, the audit stakeholders, and especially the auditees (as they are key to really understanding the process being audited). I think communication is something I will forever need to work on, but I will continue to do so as this critical in performing successful audit engagements.

 Until next time.

CPack

The Triple Constraint: Scope, Schedule, and Cost

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition identifies six typical project constraints: Scope, Schedule, Cost, Quality, Risk and Resources. While all of these constraints are important, the first three listed constraints seem to be viewed as the most critical. These three constraints are generally referred to as “the triple constraint” and are interdependent; if any one of these changes, it affects the others. For example, if the scope of a project changes, this will affect the project’s cost and/or the schedule.

As an internal auditor, the concept of the triple constraint stood out to me as I have seen many times where the scope of an audit changes (i.e. usually by expanding) without too much thought as to how this change effects the audit schedule (e.g. audit completion date) and the overall cost of the audit (e.g. increased cost of employees’ time). External auditors many be more aware of changes in the audit scope, schedule, and costs due to having contract agreements with the company they are auditing and they track billable hours. Internal auditors, on the other hand, are generally a part of the company’s overhead cost (e.g. G&A expense), so such things as tracking the cost of a particular audit and time it takes to complete an audit are not heavily monitored. This can lead to internal auditors making changes to their audits without really evaluating the constraints it can put on the audit.

It is understandable that changes may need to occur during an audit due to unexpected circumstances, just like any project. However, it is important for internal auditors, audit leads, and audit department managers to take a closer look at the changes being made. Like project managers, assessments should be made as to why these changes are needed, how the changes will affect the audit, and determine if the change is worth the additional constraints it will place on the audit.

Until next time.

CPack

Internal Auditors are like Project Managers

The first thing that stood out to me when being introduced to the basic concepts of project management was that audits are projects and internal auditors are like project managers. Most of the work auditors do is project base; they perform various types of independent assessments over many different areas of the organization to provide assurance that the company’s risk management, governance and internal controls are functioning effectively. These assessments, also called audits, always have a start date, an end date, and provide results.

As for the audit, every audit has an audit lead. This person is similar to a project manager in that they have the overall responsibility of working with the audit customer (‘auditee’), the audit team, and other people involved in the area being audited to define, communicate, and meet audit objectives. The auditee is usually the representative for the area or department being audited and is the person most directly affected by the audit and the audit results; they are similar to a project sponsor. The audit team is made up of the other internal audit team members who help performing the audit fieldwork (i.e. executing the audit).

For an audit to be successful, it is critical that there is adequate communication between the audit team and the personnel being audited. This is usually facilitated through the audit lead. The audit lead makes sure the auditees, and those affected by the audit, understand and agree with the objective and scope of the audit while ensuring the audit team has a thorough understanding of the processes that are in place for the area under audited. If there is any lack of understanding or agreeance, it will hinder the effectiveness of the audit.

These are only the start of the similarities I am observing between internal auditors and project managers. As I continue to learn more about project management, I am sure to notice much more similarities. As I do, I will also be looking to see what is utilized in project management that could be used, or used better, for preforming internal audit activities.

Until next time,

CPack