Based on an internal audit recommendation, the organization I work for (my day-job, writing and blogging being my night-job so to speak) has decided to start implementing PRINCE2 for all its projects. Given we have about 200 concurrent projects, that is a challenge.
I mentioned this was based on an internal audit recommendation, right? It was only natural that we started thinking about how we could apply some of the lessons from PRINCE2 to our internal audit approach. Now, if there is one thing that PRINCE2 stresses, it’s to either go in all the way, or don’t go in at all. While developing the approach to the specifics of the project is one of its principles, you cannot pick and chose among principles, themes and processes.
So, in this new audit we’re starting up, we’re going all in. We will be applying PRINCE2 to the audit, and documenting as we go along. We will find out what works and what does not work, and how we made it work.
Starting Up an Audit
Getting a Project Mandate
A key requirement for starting up any project is to have a project mandate. As head of internal audit, with an approved internal audit plan in hand, I can confidently tick off this requirement from the requirements list.
For internal audit, an approved internal audit plan takes the place of the required project mandates for all audits to be executed that specific year.
Appointing the Executive and the Project Manager
For a small internal audit department such as ours (2 FTE) we need to respond to this a bit differently than in the case we would have a larger organization. In a larger organization, the head of internal audit would have been the Executive, giving his managers the authority to start with a specific PRINCE2 stage and signing off on the stage completion when this was being presented for approval by the teams.
I don’t have that luxury, as I am actively involved in doing the work. The question then becomes, who is the executive? For an internal audit assignment, this is our first deviating from canonical PRINCE2. We could consider the head of the audit committee to take this role, but even an executive role is too active an involvement in day-to-day business for a board level function.
Not an issue for a large internal audit departement, in our small internal audit department the role of the executive will be played by the head of internal audit. This is a deviation from canonical PRINCE2, which does not allow a combination of the executive and project management function.
There are however significant mitigating controls that are in place in a traditional internal audit environment. I consider the following to be relevant mitigating controls:
- An overarching methodological framework, the IIA Standards, which provide detailed guidance on how we need to perform our jobs;
- A meeting conducted in three months intervals with the audit committee, which monitors progress;
- Quality control after each audit, including feedback from auditees;
- Regular contact with the president of the Board concerning our challenges, both general and at the project level.
Capturing Previous Lessons
While we have a pretty good idea what can go wrong in an audit and how to approach it, PRINCE2’s approach to capturing lessons during a project for use in future projects is an excellent one. As all our audit documentation is stored in Basecamp projects, we established a lessons log which is to be updated with all lessons learned, and which will be integrated in a lessons report at the end of the audit.
Design and Appoint the Project Team
One of the key challenges internal audit faces is to bring to a competent team to the table. In our area, development aid, that becomes even more of a challenge because we are small and the scope of our, often highly technical, activities is wide. I previously blogged and wrote about the concept of guest auditor, which is a good answer to this challenge, allows us to remain independent yet have access to the required competencies.
This requirement allows us both to identify the competencies required to perform the work required and also to make sure these competencies are available in a timely manner. Where required, I will go and negotiate with the hierarchical responsible for a certain person in order to free him or her up for support to our audit work.
Prepare the Outline Business Case
A PRINCE2 outline business case is pretty much a high level cost benefit analysis with some additional aspects that allow you to motivate the need for this project. In an internal audit context, the outline business case has usually already been written because it provides the supporting detail for the annual internal audit planning. In an audit context, developing an internal audit planning based on a risk assessment is an essential step. This takes care of the reasons for doing the audit.
The business options are used in a PRINCE2 context to provide alternatives to the audit. For internal audit, this does not apply, other than providing an overview of the opportunity cost of doing this audit, and not other audits. However, the business options chapter can assist you in clarifying the reasons why this audit is necessary.
The expected benefits and expected dis-benefits sections allow us to describe what we believe we can contribute with internal audit. These are two interesting and relevant parts of the business case, because they force an internal auditor to think about his added value and about what can go wrong if he does not adequately manage his intervention.
The timescale is the basis for our planning and our commitments to deadlines, while the costs provide us with the opportunity to list the likely cost elements other than time that will play a role in this audit. In case it is an audit “on the ground”, as we call it, travel and lodging are to be included here.
I consider investment appraisal less of an important part of the business case, unless we want to argue that a specific audit should not take place. However, listing the major risks is a good exercise in understanding what can go wrong in the audit, and how we can proactively deal with that.
Select the Project Approach and Assemble the Project Brief
At this stage in an internal audit the project approach is likely to remain at a relatively high level, unless we are aware of the key issues. Initial audit phases are discovery phases, and we want to make sure our approach allows us to capture all the issues and develop an audit approach to further analyze them. The project brief details the considerations made throughout this phase and summarizes them in a short, concise document.
Plan the Initiation Stage
Here we develop an approach to how we will do discovery in the initial internal audit phase. Discovery is an essential phase in internal audit, as it provides you with a first look at processes, procedures and ways of working. The assessments and interviews conducted throughout this stage are important because they determine the specifics of the phases beyond the initiation.
In this specific project, we will be working with two initiation stages, because we will be covering two related, but fundamentally diverse sets of processes.
Next Post
In the next post in PRINCE2 in internal auditing, we will be looking at some of the management documentation generated in this first phase.
Exploring The Black Box 