Traditionally, internal auditing was done retroactively. That means that we have historically reviewed decisions, activities and transactions after they occurred to determine whether those were done according to some criteria (e.g. laws, regulations, policies, procedures, contractual terms). The results were then used to provide an opinion on the overall conditions in the program or process reviewed.

While our methodology has relied on this practice and it has been used widely for a long time, one of the issues with this after-the-event approach is that the actions have already occurred. It is based on auditors focusing on issue detection. While it is helpful to detect problems, we are increasingly coming to the realisation that deterring and preventing issues is better than detecting and having to correct them later.  This is the essence of being proactive.

Standard 2100 – Nature of Work states “The internal audit activity must evaluate and contribute to the improvement of the organisation’s governance, risk management, and control processes using a systematic, disciplined, and risk-based approach. Internal audit credibility and value are enhanced when auditors are proactive, and their evaluations offer new insights and consider future impact.”

Being proactive and considering the future impact may be a departure from the common practice for some internal auditors, but it is one of our Standards. We should do this, not only because the Standards are mandatory, but because it holds the potential for adding a significant amount of value for our clients.  It would help the organisation anticipate risky dynamics so they can be avoided or at least minimised and improve the relationships we have with our clients.

To illustrate the application of this proactive approach, let’s consider how we have audited IT system development initiatives in the past and how we can introduce better practices.

The Traditional Approach: For many years we selected and audited new IT systems after they were completed and implemented. We reviewed what was delivered to determine if the functionality matched what was initially promised and documented in the business requirements. We usually checked the time variance between when the system was supposed to be delivered and when it was delivered. We also checked the budget variance between what the system was supposed to cost and how much it eventually cost the organisation.  Our review also consisted of checking the quality of the system to determine if what was delivered was stable, reliable and secure.

But by the time we reviewed all of this the system was already in operation.  If we identified issues, they affected many users who were already relying on this system for their daily production, the data was now live and corrections were very costly and often disruptive.

The 2018 Pulse of the Profession report from the Project Management Institute (PMI) shows that project management has improved in many ways from past years’ performance, yet it indicates that on average 9.9 percent of every dollar is wasted due to poor project performance and 15 percent of projects were deemed failures. Only 69 percent of projects successfully met their original goals and business intent. The report also shows that 57 percent of projects finished within their initial budgets and 52 percent finished within their initially scheduled times.

Our audits have been showing this unfortunate loss of organisational resources for many years and these statistics corroborate what many of us have been witnessing for a long time. 

A Better Approach: Given the limitations and issues shown above, it is not surprising that internal auditors started reviewing IT development projects while they were ongoing. We started reviewing progress reports to determine if the projects were advancing as planned and we highlighted deviations in the scope, timeline or budget. Quality issues and deviations could be communicated to management through quarterly check-in reviews so adjustments could be made closer to real-time.

While A Better Approach has been a substantial improvement over The Traditional Approach, it also has some limitations, especially because by the time these periodic reviews were conducted, contracts had already been signed, the hardware and software had already been chosen, the project manager had been assigned, consultants and their firms had been selected, and the chargeable rates were not only set but were already being paid.

So, when we identified issues it was typically still too late to correct them.

The Recommended Approach: An improvement to The Traditional and A Better project management audit cycle approach consists of checking matters before any decisions are made and review the process management has in place to:

  1. Document management’s need assessment and feasibility analysis
  2. Determine the scope, budget, timeline and milestones for the project
  3. Finance the project and the funding schedule
  4. Select the project manager and project sponsors
  5. Write and sign all contracts and the clauses they contain
  6. Select vendors and consultants
  7. Prepare, monitor and evaluate progress reports, their contents, who will review results and how accountability for results will be set
  8. Perform the project risk assessment and how project risks will be managed
  9. Select the project management and communication tools
  10. Manage, retain and safeguard project-related documentation

By using The Recommended Approach we are not co-managing and we are not acting as a control point. We are not threatening our independence either.  We are advising management of design deficiencies and applying a risk-management and risk-based approach that anticipates failure points before they erode stakeholder value.

The Recommended Approach is consistent with the Standards and helps us accomplish a very important aspect of our role as internal auditors: Verify that management has built the necessary infrastructure around its strategic initiatives and these are therefore more likely to succeed.