Considerations for Project Management Audit

There are many articles, but the first question I would ask is whether you are auditing a specific project, or are you auditing your project management architecture as a whole.

Philip, that is a wide range of audit you are doing. Check under templates on this platform and you might find a checklist.

Philip -

Audits of any kind are tied to control objectives. For internal project audits, start by defining the scope of audits (e.g. which project sizes, in flight or just starting) and the list of control objectives which the audit will assess.

Remember that projects are unique endeavors so a project audit is different than an operational audit. In both cases, you want evidence to substantiate what is or isn't happening but in the latter case, you are checking for adherence to documented processes, creation of specific artifacts and so on, whereas with a project audit, there might be many different ways in which a control objective could be met.

Here's an example:

Control objective: ensure traceability from business objectives down to detailed requirements and test cases

Method 1: Review a current, accurate traceability matrix

Method 2: Run a query against a work management system for all completed work items confirming that traceability exists from highest to lowest levels for those work items

Kiron

If you are auditing both the process architecture, and the projects supposedly complying with that architecture, you need to need to consider whether you plan to follow a top-down, bottoms-up, or multi-phase approach.

In a top-down approach, your processes and tools should comply with some type of standard. In companies with mature processes, the high level standards are defined. If you don't have that, you need to decide what criteria you will use to audit your architecture. Then you can audit projects against the established processes.

In a bottoms-up approach you can evaluate current and past projects for what went well and what did not, and why. The why produces leading questions about root causes originating in your processes. That can help you narrow your focus to critical items you think have the most influence, so that you don't spend too much time auditing things that you eventually find are not significant.

Either of those might drive a feedback loop. The first pass of process and project audits is really to find the most sensitive variables in you equation. The second is to drill down deeper on those specific variables.

You must define the principal parameters or considerations you want to audit and determine certain classifications like project nature, project size, etc. Then you can design a personalized template to organize this information in a perfect manner. Parallel to this, you should establish a complete checklist of auditing activities, from the beginning to the end, specifying what actions you'll be doing when having all the information available.