Skip to main content
Software development is a complex and intricate process that requires constant supervision to deliver the result you expect from it. It’s a project manager’s (PM’s) job to oversee the development and ensure that you’ll get the software you need under a specific deadline.
One of the key tools that PMs use to keep an eye on a project and detect possible issues early is a project management audit. In this article, we take a look at what a project management audit is and how it can benefit your business. We also share a workflow and an example of how we conduct such audits at Apriorit.
This article will be useful for product teams, development leaders, and PMs who are looking for ways to improve project visibility.
Contents:
What is a project management audit?
The state of a software project constantly changes during the software development lifecycle. Sometimes it goes according to plan or even better than expected, and sometimes the team falls behind schedule and needs more resources to work on some tasks. To be able to track a project’s status, a PM has to conduct a project management audit (or simply a project audit).
The Guide to the Project Management Body of Knowledge (PMBOK) defines a project audit as a “structured independent review to determine whether project activities comply with organizational and project policies, and procedures”. An audit allows a PM to:
- Assess processes inside a project
- Evaluate the project’s health
- Understand the project’s desired and real statuses
- Identify potential issues and blockers
During an audit, a project manager can check multiple project parameters like:
The parameters of an audit can change depending on the project’s size, nature, and goals. Each of these parameters has its own health criteria, timeframes, properties, etc. That’s why a project manager has to develop a procedure for evaluating each of these parameters and assessing them individually. Also, that’s why there are no recommendations on when to conduct a project management audit.
In most cases, auditing a project takes a lot of time even for an experienced PM who knows everything about the project. The duration of an audit depends on the size of your project: the more processes it has, the more time a PM spends auditing them.
Despite that, regular project audits have a lot of benefits both for business and development. Let’s take a closer look at these benefits.
Why conduct a project management audit?
At first glance, it may seem like your team can spend its time more productively than by participating in a project management audit. During an audit, a project manager can involve other team members to gather needed information and assess all the parameters we’ve listed above. However, regular project audits can bring you many benefits:
Manage project artifacts from one place. Even a small software development project consists of numerous internal processes, issues, communications, etc. A project manager can’t be constantly involved in everything happening inside their project, but they need to be aware of what’s going on in general. A project audit helps them assess the project’s status and progress towards established goals.
Detect project issues early. An audit helps a PM to uncover issues that aren’t currently critical for the project but may become so in the future. For example, a project’s risk strategy may not be implemented correctly, which could lead the project to fall behind schedule. Unclear procedures also may lead to time wasted on working out project changes down the line. Discussing such concerns with the team and resolving them proactively results in a more resilient project in terms of the scope, budget, and timeline.
Reduce costs of project development. If a project team encounters unforeseen risks and challenges during development, they’ll need additional time and resources to get back on track. Such situations can postpone a product’s release and increase the overall cost of a project. During an audit, a PM can detect and resolve emerging risks before they negatively impact the project.
Inform stakeholders on the project’s health. At the end of an audit, a project manager compiles a detailed report that describes multiple parameters such as the team’s progress, budget compliance, and current risks. With this report, project stakeholders can quickly assess the overall health of their project and ensure everything works as it should.
While there’s no standardized procedure for conducting a project audit, each project management team and development company must have its own audit flow. In the next section, we share how we conduct high-quality project management audits at Apriorit.
How do we conduct a project audit at Apriorit?
Based on over 20 years of IT management experience, we at Aptiorit formed an audit workflow that ensures swift and efficient project evaluation. We usually divide this process into four key stages:
Stage 1: Definition. First, we define what exactly must be audited. When defining the components of an audit, we not only take into account processes defined by the PMP but also pay attention to unique processes that are relevant to your organization. For example, not all projects require auditing competitor analysis or marketing activities, so we only include them in a project management audit checklist when they’re relevant for a project.
Stage 2: Decomposition. After we get the list of components for a project audit, our project managers provide descriptions for these components and define how they’re expected to work. During audits, detailed descriptions of project components help us evaluate the project’s status consistently and with reduced bias.
Stage 3: Developing evaluation criteria. Next, we develop our evaluation criteria and parameters we’d like to measure during an audit. During the first audit, we need to choose representative parameters and define transparent and efficient criteria. As a project goes on and a project manager conducts more and more audits, the criteria will become more and more refined.
Stage 4: Conducting the audit. During an actual audit, we evaluate chosen project components according to our criteria and create an audit report. At the end of the audit, we:
- Create a project management audit report on the results of audit, issues to review, and comments for the next audit
- Assign employees responsible for fixing discovered issues
- Publish a report in a place accessible to anyone who may need it
Note that when conducting a secondary audit on your project, there’s no need to go through all four stages. You need to go through the first three stages of this workflow for the project components you want to check once. Then, you can use the same results of definition, decomposition, and criteria evaluation to conduct several audits.
Seems easy and straightforward, right? Let’s take a look at a practical example of conducting an audit.
Conducting a project management audit
As we mentioned, an audit focuses on both well-known process groups described by the PMP and specific project parameters you define for yourself.
While each project has unique requirements that you’ll need to account for, we’ve established the core structure of an efficient project management audit that you can start with. We’ve included these parameters in the project audit plan to accommodate the needs of our clients.
Stage 1: Process definition
The first step of a project management audit is listing processes and components that are important to our client. Here’s what we want to assess:
- Project paperwork and resources
- Project development processes and procedures
- Project management processes and procedures
- Project communication management and reporting
- Stakeholders and responsibilities
- Project status tracking
- Status tracking systems
- Risks
- Changes
- Performance and metrics
- Retrospective analysis and team management
- Product quality
- Delivery and version control
- End user support
- Marketing
- Project documents and knowledge base
Note that this list contains unusual project components that aren’t mentioned by PMP, such as marketing and project status tracking. We’ve included these components, as they are common for IT projects
Now we have the basis for our future assessment: we already know what to assess, but a simple list isn’t enough to start the assessment.
Stage 2: Decomposition
Now, let’s try to decompose our components and explain what they mean in terms of our organizational assets. We’ll get something like this:
| Component | Description |
|---|---|
| Project paperwork and resources | Agreements A, B, and C are signed |
| Agreements A, B, and C are placed in secure storage | |
| The project is registered in the accounting system and all required fields are filled out | |
| Project resources in the management system are up to date | |
| Project development processes and procedures | Processes and procedures for the project team are agreed upon, described, and placed in a commonly accessible place like Confluence |
| Project management processes, procedures, and tasks are described and placed somewhere PMs can access them | |
| The PM’s role and activities are described and placed in a commonly accessible place | |
| Project communication and reporting | Regular internal team meetings are set up and notifications for all participants are configured |
| Regular meetings with the client are set up and notifications for all participants are configured | |
| A project reporting schedule is defined and is accessible to the team | |
| All meetings have fixed start and end times | |
| Stakeholders and responsibilities | A development team matrix of responsibilities is created and described |
| A business team matrix of responsibilities is created and described | |
| Channels for communication with the client are defined and approved by the client | |
| Feedback from the client is requested regularly and shared with the team and PM board | |
| The flow of the client’s artifacts sync is described and is in place in the project knowledge base | |
| Project status tracking | A project backlog is in place and has tasks for at least one month ahead |
| A long-term project roadmap and plans are in place | |
| Iteration boards are configured and always contain relevant information | |
| Status tracking systems | A bug tracking system like Jira or Trello is set up on the client’s side and is regularly updated |
| All created and assigned tasks are formulated according to SMART principles | |
| The project team tracks their working hours on a daily basis | |
| Risks | Risk management strategies are implemented and described in the project space |
| A risk matrix is implemented and is updated according to the PM plan | |
| Changes | A strategy for working with change requests is implemented and described in the project space |
| A change request registry is implemented and updated according to the PM plan | |
| Performance and metrics | Metrics and KPIs are defined and implemented, and success indicators are shared with the project team |
| Retrospective analysis and team management | Retrospectives are performed regularly at the end of each iteration or other specified period |
| A retrospective to-do list is in place and kept relevant | |
| Lessons learned during retrospectives are formulated to: – Highlight current project-based challenges and possible ways for improvement – Get feedback from the team on whether they’re comfortable with their tasks, technologies, etc. | |
| 1-on-1 meetings are conducted to get feedback from teammates on their work | |
| Product quality | Engineering practices like code reviews and refactoring are implemented and maintained |
| A QA strategy is implemented and executed | |
| Delivery and version control | Delivery criteria are defined and described in the project’s knowledge base |
| The version control flow is agreed with the client and all considerations are in place for everyone on the project | |
| The project team always knows which product version or phase is in progress and what its goals are | |
| It’s always clear from the backlog and roadmap what should be done in terms of each version’s scope | |
| End user support | An end user support process is described and contains at least the following information: – Where escalations are coming from – Who is responsible for working on requests (on both Apriorit’s and the client’s side) – How and when we start working on a ticket |
| A checklist for taking a support ticket is implemented and is in place. It should contain the following information: – Are the problems and steps for ticket escalation clear? – Is there information about the environment where the bug occurred? – Are there logs and dumps? – Is there a version ID where the bug was found? – Are there clear steps for bug reproduction? | |
| Marketing | The product’s place on the market is highlighted in market research reports |
| All competitors are clear and listed in the market research | |
| A list of possible valuable (killer) features is reviewed with the client regularly, and agreed features are added to the roadmap | |
| Project documents and knowledge base | The project’s knowledge base has a defined structure |
| The high-level project architecture is always up to date and in place | |
| Project how-tos are in place. Must-haves are: – How-to build – How-to launch – How-to test | |
| Credentials and other sensitive data are stored securely in a proper place |
With these parameters, we have a clear checklist of things we need to audit. Now, we need to develop evaluation criteria.
Stage 3: Evaluation criteria
To make our brand-new checklist work, we need to establish consistent and transparent evaluation criteria. They allow a project manager to make their reports easy to understand and compare the results of several audits.
First, let’s define our score system. We believe it is best to use simple scores like these:
- 3 — everything is good; no comments
- 2 — good in general, with minor issues (updates aren’t frequent enough, we’d like to make the process clearer, etc.)
- 1 — there’s a major problem (the process is not finalized, no updates for a long time, etc.)
- 0 — the process is undefined or absent for the particular project
Numerical marks allow us to evaluate the health of a specific process in a group of projects and the health of a specific area under a specific project.
Next, we need to establish a results scale. It will help us assess the project’s health and prioritize your future actions. To make this scale visual and easy to understand, we at Apriorit coordinate audit results by colors:
- 80% to 100% — green zone; any actions are optional
- 50% to 79% — yellow zone; the process requires improvements
- 0% to 49% — red zone; the process doesn’t work as expected and requires changes
Now that we know how to assess project parameters, we can start an audit.
Stage 4: Conducting the audit
To establish a transparent auditing process, a project manager prepares a table that reflects the project name (when auditing a single project), decomposed components, responsible managers, and process health assessments. When completed, this table becomes an audit report.
We also recommend including the following parameters in the audit table:
- Review period. This defines how often we want to evaluate each parameter. Different processes inside a project evolve at their own pace, so there’s no point in reviewing all of them simultaneously. A review period should be individually assessed for each process within each project. The same review period for a given process may not work across different projects.
- Latest review. The date of the previous review helps us monitor and control the audit process. By knowing when it’s time to audit a certain process, we won’t spend time on unnecessary reviews.
- Comments. Comments help us to maintain the context of why a particular process got a particular score during a previous audit. You can put comments wherever you want, as long as they are easy to understand. Since we write simple and concise comments, we’ll leave them in the same column next to the score.
- Project columns. This addition is only necessary when you want your project managers to evaluate several projects at once. If you need to manage lots of projects or project stages simultaneously — like we do at Apriorit — you can place all gathered results in a single table. This will allow you to compare progress on similar projects, determine which projects are “sagging,” and understand how critical this sagging is.
Let’s put such a table together and fill it out. Since auditing all project parameters takes a long time and a lot of space, we’ll only audit the marketing components in this article.
| Review period | Latest review | Alpha Inc. | Beta Inc. | Omega Inc. | Group process health | |
|---|---|---|---|---|---|---|
| Responsible | Alex | Alex | Kelly | John | Kate | Alex |
| The product’s place on the market is highlighted via market research reports. Links and evidence: – Link 1 – Link 2 | Quarterly | Apr 10, 2023 | 2 Reports are not regular | 3 | 3 | 89% |
| All competitors are known and listed in the marketing article. Links and evidence: – Link 1 – Link 2 | 6 months | Mar 10, 2023 | 3 | 3 | 2 The latest update was too long ago | 89% |
| A list of possible valuable (killer) features is reviewed with the customer regularly and agreed features are added to the roadmap. Links and evidence: – Link 1 – Link 2 | 1 month | Jan 10, 2023 | 1 Considerably fewer features than we’d like to have | 3 | 0 There’s no such list | 44% |
| Process health of the specific project | 67% | 100% | 56% | |||
We can draw several conclusions from this audit:
- Process health of a group of projects. Process #3 was rated 44% because of the lack of killer features for the first project. That’s the red zone at the process level. It means that we need to review our approach to the process.
- Process health of a specific project. Omega Inc. got 56%, since there’s no list of possible killer features for this project. It’s a yellow zone at the project level. We need to review our marketing activities on this project.
If you need to evaluate a single project, your evaluation table might look something like this:
| Marketing component | Review period | Latest review | Project Omega Inc. | Process health of projects |
|---|---|---|---|---|
| The product’s place on the market is highlighted via market research reports. Links and evidence: – Link 1 – Link 2 | Quarterly | Apr 10, 2023 | 3 | 100% |
| All competitors are clear and listed in the marketing article. Links and evidence: – Link 1 – Link 2 | 6 months | Mar 10, 2023 | 2 The latest update was too long ago | 67% |
| A list of possible valuable (killer) features is reviewed with the customer regularly and agreed features are added to the roadmap. Links and evidence: – Link 1 – Link 2 | 1 month | Jan 10, 2023 | 0 There’s no such list | 0% |
| Overall process health of the project | 56% | |||
With these results, a project manager sees what areas of their project need additional attention. Color coding helps PMs quickly spot the most critical parts of the project and prioritize further actions accordingly.
Note that while it may take a lot of time for a PM to create a report template for the first time, they can reuse one template for multiple audits. They can also automate all calculations and color coordination using formulas in solutions like Microsoft Excel and Microsoft Project.
Conclusion
A project management audit is a valuable tool that allows a PM to assess a project’s health, discover processes that require improvement, and detect issues at early stages. When conducted properly and regularly, a project audit helps you avoid emerging challenges, save resources on project development, and generally stay on top of a project.
At Apriorit, our skilled project managers have developed a routine to conduct project audits quickly and efficiently, as well as to tailor audits to the needs and conditions of a particular project.
Reach out to establish sustainable and beneficial project management processes within your project!
