I’ve been surprised by the level of interest about my recent post on using Basecamp as the base application for internal audit working papers. While by no means a representative sample, I feel the interest indicates that current working paper solutions fail to address a number of concerns or needs which the simplicity and flexibility of Basecamp does answer. Therefore I’ve decided to write this “practical guide” to using Basecamp as the “basecamp” for internal audit documentation. It is a way, not necessarily The Way. But, if you keep waiting for The Way to appear, it’s likely you’ll never get anything done.
What Basecamp does not allow you to do
Before we go into what you can do with Basecamp, let’s first make clear what it does not allow you to do. Basecamp is not a standard working paper documentation solution for internal audit purposes. That means that it does not provide a number of functionalities these solutions provide out of the box.
For example, if you are looking for a solution with an integrated risk identification and mapping functionality, you will not find that with Basecamp. If you want your solution to highlight key control weaknesses as a standard report, Basecamp will not provide this for you. If you are looking for any kind of automatically generated report, you should turn away, because you will not find it.
Traditional packages cramped our style
We worked with such software for a while – actually less than a year – and we found that it did not fit well with our needs. None of these packages provided us with the flexibility we wanted. Rather, they assume that you buy in to their methodology, and use it to the exclusion of anything else. Sadly, the type of work we do as auditors in development aid does not allow us to buy into any one methodology. Rather, we need a lot of flexibility. Our working papers need to be exactly that: traditional structured repositories of information on work planned and work executed, leading to a set of findings and conclusions, where possible supported by relevant recommendations. The very simplicity and flexibility of Basecamp provided us with the means to structure just that.
One of the reasons I react so negatively to structured software is because it takes away the need to think and reflect. Often, audits are mere mechanical executions of tasks, without any real in-depth consideration of how and why the task needs to be executed. And these systems do not provide the necessary flexibility to allow for a non-standard project to be integrated in that approach. If you then take into account that in addition to our traditional assurance projects we also manage a number of advisory projects each year as well as documenting all integrity and corruption complaints in this system, you understand that a highly standardized approach was not an option for us.
Now, the very simplistic structure of Basecamp means that you will need to do some “configuration” and abide by some ground rules while using it. These rules need to be well understood and consistently applied by everyone using the system. There are not inherently present. That being said, any auditor that is not able to follow simple instructions as to documentation is not worth the title.
Auditor versus client
Basecamp provides you with the ability to define a participant in the project room as either a team member or a client. A client can be prevented from seeing certain documents, if the team member posting the information excludes the client from seeing it.
It’s a very simple, but very powerful concept. We now invite our auditees into our working papers, where they can share their comments on the documents we open up to them. Usually, we open up questions and information requests, the so called Prepared By Auditee (PBA) documents. This allows them to answer questions and provide information directly in the working papers, which reduces our administration and allows us to work from so called raw documents, i.e. information received directly from and directly traceable to the auditee providing us with that information.
There are two ground rules here: first, you need to set up the system with the names and email addresses of your auditees, as well as informing them of the fact you will be using Basecamp as an information repository. The second ground rule is that you make sure you do not post anything to all users of the project room that is eyes only to the auditor. This is a risk, as the starting point is that information is shared with all users. Nevertheless, I find it focuses the auditors really well on the nature of the information they put in the system.
We also share preliminary findings and related recommendations with the auditees. This way, they really see the audit report developing almost before their eyes, and they have the possibility to provide comments or correct factual mistakes.
The central nature of the to do-list
Basecamp has a number of standard document types which can be either uploaded (such as files) or generated (such as to do lists, text notes or dates, which are calendar entries.) Now, our working papers are traditionally a reflection of the proper execution of a work program, which in turn is built based on initially gathered and analysed information.
Basecamp allows you to develop and structure this as you go along. Our analysis of initially gathered or researched information, based on standard audit initiation work program, leads to the development of a audit scope memorandum, which is the basis for the work program which will guide the execution of the audit. Basecamp’s to do lists allow us to built that work program in phases.
The audit initiation work program is a standard work program. Like any other work program, it consists of audit activities focused on gathering information and performing preliminary analyses, including but not limited to interviews, which feed the development of an audit scope memorandum or ASM. This ASM describes what we will and will not be auditing. How we will be auditing it then becomes the subject of the work program for that audit. The work program is an evolving beast. It is a set of to do lists that together comprise all the work that needs to be executed for that audit. We recognize three types of work program activities which we capture in Basecamp’s to do lists:
- Information requests, sometimes also referred to as PBA’s (documents Prepared By the Auditees) are requests for information or data sent out to the auditees. This can range from a simple organization chart to a full accounting data set, or any other type of information. Information requests are purely requests to the auditees to provide us with some information, without further requirements to provide some explanation about it. We do not want to be influenced by the opinion or the idea of an auditee on this data, we just want the data for analysis now or later in the audit.
- Questions are exactly that. Based on our analysis, we have certain things we do not understand or need more information or clarification about. We will then ask questions of the auditees. They can answer directly in Basecamp, which saves us significant time in administration. Perhaps funny, but some of our auditees actually enjoy the possibility of answering questions in a more formal, written manner.
- Audit activities are those tests, analyses and other activities to be executed by internal auditors to test the assertions made by the auditees. After all, we are not journalists and need to make sure that what we write has been tested. Audit activities may include reconciliations, specific data analyses, IDEA tests comparing two information sources for data completeness etc.
Each of the to do lists which together form part of the overall work program has at least one and in most cases all of these activities. Additionally, each activity in the work program needs to be identified as one of these activities.
As stated above, a work program usually consists of more than one to do list. We develop one to do list per subject area under audit. Subject areas are determined based on the ASM (remember, audit scope memorandum). This implies that each to do list comprises all audit related activities (information requests, questions and audit activities) that need to be executed to thoroughly audit a subject area under audit. For example, we currently have an audit ongoing on our budget processes. The structure of the to do lists is the following:
- Audit initiation work program: this is a standard work program that we apply to every audit;
- Audit activities related to the budget process at headquarters level
- Audit activities related to the budget process at local office level
- Audit activities related to the budget process in programs and projects
- Audit activities related to the internal organization of controlling in the context of the budget process
- Audit activities related to other departments’ roles in the budget process
In addition, we have two other to do lists which we maintain:
- Draft findings and related recommendations
- Draft improvement ideas other than findings
Document creation in Basecamp
Given the central role of the to do-list in our use of Basecamp, there should be no other document that is created outside of the to do-lists. There are three exceptions to this:
- Forwarded mails are mails that are directly mailed in to the system. These are usually forwards of essential mails received from an auditee where we want to maintain not only the information but also the mail itself. A forwarded mail needs to be URL-linked directly to a to do item via the comments.
- Text documents are documents which we use in the context of findings and other improvement ideas, and are to be linked to the two separate to do lists mentioned above. The text document format in Basecamp allows for a more elaborate text development. We use it because it is easy to copy-paste into the final report. The documentation of findings follows a standard structure and each finding needs to be URL linked to both the supporting evidence and the finding in the to do list. Having that to do list makes it a lot easier to check for completeness of the final report.
- Dates are used as a calendar for both auditors and auditees. They allow us to indicate, in broad terms, to the auditees where we will be and what we will be doing when.
The need for URL linking
As documented in an earlier post, it is essential that we take the time to properly link documents to each other in both directions: whenever we document a finding, we need to link to the supporting evidence, but the supporting evidence needs to link back up to the finding. The best way to do it is to embed internal links into the comment fields. As Basecamp is a web based solution, internal links are URL links and hence usable by anyone with access to the project space in which we are documenting.
In conclusion
While Basecamp may require a bit more care than other solutions, its flexibility more than makes up for the bit of extra investment in time. In case you have more questions on its use, don’t hesitate to ask.
Exploring The Black Box 