Most people would think that asking this kind of question when you are a project manager is a risky business.
Much as the answer to all the above questions depend on context and people, I also think that audits are - in general - useful and necessary; they can be both productive and bring profits and real advantages to your project as well as to yourself.
I suggest starting with the beginning: who sponsored the audit? Why was an audit deemed necessary? Who are the auditors? And chiefly, what is the precise object of the audit?
I discovered from experience that answering the latter question, i.e. the precise scope of the audit, often allowed me to find the answers to all the other questions. Indeed, when the object of the audit is shared and understood, it often sheds light on several target domains of investigation and detailed review. It can encompass project management practices, budget control, quality control pertaining to deliverable, security aspects, project status, project plan details or all combinations of the above as well as other points we may have overlooked. A little bit of forward thinking and prior discussions with the auditors should help elicit the rationale behind the audit and who the requester is.
Besides, the kind of auditors who have been selected, internal or external, generalists or specialized consulting firms, expert auditors of the processes or technicians, tells a lot about the purpose and how significant the audit is.
For example, while conducting a project for the integration and deployment of an ERP (Enterprise Resource Planning) software, we were internally audited. Once established that the focus was essentially to ensure that we both budget and risks were managed properly, it was easy for the team to supply the evidence of what we were doing in these domains. We showed our processes to control cost, our method for following-up with resource assignments, the log of open questions and the risks register. The chief financial officer, who had asked for the audit, was reassured by the conclusions and the recommendations of the auditors on which we naturally took prompt actions. Besides, the auditors helped us to go farther in our management of the risks by facilitating the set up of a session of brainstorming on the risks with the entire executive committee.
It is indeed important to understand their approach to better prepare the team for this event which they may initially perceive as stressful and negative. Generally, the first phase consists of conversations with keys members of the team as well as the executive committee of project, preceded and/or followed by demands for diverse project documents for pre-analysis.
The following phase implies additional sessions to dive more deeply into specific questions in more detail in particular on how processes or tasks are conducted. Another example based on my personal experience, took place on an IT project in which we had met tough problems during software deployment. As a junior project manager, I had neither the experience nor the pluck to drive the interview with the auditor (an external auditor for that matter). He arrived and ran his show without explaining why and how (the process which he was going to follow if he had one) to anyone. Furthermore, from the beginning, he sent numerous negative messages.
The team, disorientated by an apparent lack of structure and visibility on what was happening, quickly became worried and a little defensive. The team members then supplied all the project documents, but in an unstructured way, without a good articulation of the many components. The storyboard was missing to position these raw materials in their context. The audit took a lot of time and was very stressful for all. In the end, the audit did not succeed in helping the project to get over this difficult period. In that specific case, an audit which could have brought some value, only managed to kill a project which certainly had a few weakness but which could be put back on track if only a little effort was made in correcting these issues. Until today, I have a bad memory of this audit; I certainly learned a lot from it but the process was painful and the project was killed.
Third suggestion: find your place in the thinking and reporting processes
You should take into account the fact that the auditors will keep tabs on both management and requesters. During these sessions, they are going to share the progress, to expose their discoveries and "astonishments", to test their initial ideas (to observe the potential reactions) and, later, present their recommendations (intermediate then final). Last year, I was asked to lead the internal audit for the deployment of a set of IT applications in my company. Since I had been several times of the other side of the audit, I tried to pay specific attention to explain the objectives, the milestones and the approach of the audit (the first and second hints mentioned in this article). We discussed the proposed perimeter and who would do what. We shared our observations we went along with the team to avoid bad surprises (the third suggestion above). We gave them the opportunity to comment on our observations: which they did and that we considered. We shared our recommendations with the project team before doing it with the management. We also helped to define, set up and track action plans to address the identified points of weakness. We have even, after the audit, provided a follow-up of the execution of these action plans. I am certain that it was much more beneficial to the company than a simple report. Independently of the scenario, the key point for the project manager is to support actively the auditors during their investigations. We have to supply them all the required information in total transparency and ask members of our team project to do the same. We also need to make time for them in our overloaded agenda. We want to be open, positive and value-add partners. This way, we can hope to gain the privilege to be involved in the preparation of documents and sessions for the management. It can be limited to validating the correctness of the facts and details and this alone is already very useful. It can be to understand what they are going to bring to light and even to discuss some of their intermediate recommendations to start to elaborate action plans.
fourth recommendation: voice your expectations clearly
In my role as a PM, if auditors ask me for my expectations regading the audit, I bring to light 2 major points:
- Fairness towards all team members;
- Getting good recommendations from the audit as to how the project can be improved
final stage: audit wrap-up
The final stage consists of the completion of the audit and the delivery of the recommendations. Inevitably, there are some recommendations with which you will agree and understand. There are others that are more difficult to accept. In any case it is absolutely critical to remain positive and open. Moving to defensive mode would not help at all. Furthermore, keep in mind that the recommendations of the consultants and auditors are one thing; the selection of the recommendations on which the management or the executive committee will decide to act upon is another matter (the latter are more important to you and your project). As soon as you understand which corrective or improvement actions are retained, share these with the project team in a positive way. It is frequent that the complete report of the auditors is not distributed. Only the key (retained) points are presented. Those that engage the team on productive actions.
as a conclusion
If your project is not yet the object of an audit, consider which domains could be improved through external advice and request an audit on these critical points: i.e you should seek help before somebody above you decides that you need help. On many projects, you will experience that the auditors may help you dramatically to improve some aspects like scope control, change management methodology or exec sponsor engagement impact on risk management. Auditors will take a bird's eye view of your project and are thus more objective than you can ever be. Furthermore, they have a legitimacy which can help you to send specific tough messages to your executive project committee, in particular when some critical issues need to be fixed and the onus is on them. For example, it could mean that their involvement in some of the project areas is too weak or that there is an issue regarding their involvement in scope control and risk management.
I've been leading IT projects for more than 20 years at telecom and computer manufacturers: Thomson Sintra, Digital Equipment, NCR, Nortel Networks, Orange Business Services. My passion is Project Management and leadership and I run a blog on the PM best practices at http://dantotsupm.com/