The Money Files

Are you thinking about year-end project audits? Perhaps your PMO is thinking about how to learn from the past year. Perhaps you want to set a good foundation for projects next year. Perhaps you just had a rubbish past few months and want a second opinion to see if there was anything you could have done differently to avoid the outcomes you got.

Whatever your reason, many project leaders’ thoughts will be turning to audits at this time of year, so let’s talk about how to make the most of this exercise – it’s not as awful as you might be thinking!

Planning the audit

First up, make sure the audit is planned in. Schedule it in advance to ensure key team members are available.

Look out the documentation that is required, which is normally things like financial reports, scope changes, and risk logs. You’ll also want to make sure that the business case, project plan, and schedule are available, as well as any change requests that changed those, so the auditor can compare the original planned baselines to the current baselines.

Key areas to audit

So what is your audit going to look at? Whether you have been asked to audit someone else’s project, or you want projects in your PMO to be audited, here are some things you’ll probably want to put on your checklist.

• Budget vs. actuals: Compare planned spend to actual spend and do the same for resource utilisation if you have the data.
• Scope management: Look at how many change requests the project had and whether that resulted in managed change or scope creep. Personally, I don’t think it is important to assess whether the project stayed within its original scope – what you are looking for is whether changes were assessed and approved rather than being done in an ad hoc manner.
• Risk management: You’ll want to go through the risk log to see how well risks were managed, mitigated, or exploited.
• Quality of deliverables: If anything has been delivered so far, check to see that the quality is comparable to the targets set. In other words, are there post-go live bugs still to sort out, and does the product meet quality expectations?

Identify lessons learned

The main purpose of an audit is to review what worked, what didn’t and what needs to change (or be continued). So you can think of the output of the audit as a sort of lessons learned report. If you already have scheduled lessons learned activities, you can feed those in to the audit report. If not, it never hurts to have a lessons learned conversation with the team.

Set the stage for next year

If your project is running into next year, discuss how the results of the audit can be used to improve processes, define new standards or ways of working, and inform the next year’s project strategy. There might be some easy things you can do to change up how things work to make them more effective.

Whether the outcome is a lot of things to change or the reassurance that you are doing everything right, it’s a good time of year to be reflecting on project management practice. Take stock of where you are and how far the project has come, and if an audit is offered, say yes! It really is a good learning experience.

Risk avoidance is an approach that you’ll see mentioned as one way to manage project risk. But how can you actually avoid a risk? Oftentimes, the risks are related to what the project is all about and you can’t simply palm them off on to someone else or change the project so that they don’t happen – because that would mean changing the scope of the project and that’s probably not going to be something your sponsor will go for.

In his book, Identifying and Managing Project Risk (4^th edition), Tom Kendrick lays out some realistic options to consider if you want to avoid a risk completely.

Here are some suggestions drawn from his work but with my own interpretation added in.

Avoid new technology

Anything new brings with it an element of risk. Untried technology might be the latest shiny thing, but if you want to avoid risks related to using unique, new, and unproven solutions, it’s better to stick to the tried-and-tested options.

Buy, don’t build

Make or buy decisions are common in tech projects and others. You have to decide if you’re going to buy in a solution or build it in-house. It might feel like the right thing to do is to build it in house, but if someone out there already has a proven solution that works and would work for you, you can reduce the risk if you go with that.

Building involves creating something new (for you) so it adds time and uncertainty and risk.

Do the minimum

Keep your scope small. The larger the scope, or the more additional change requests and new features that find their way into the brief, the more risk you are adding. MVP for the win.

Keep the plan simple

Along the same lines as having a simple product scope, have a simple plan. Avoid multiple strands of work that run in sequence. Avoid dependencies between tasks where you can. Break down tasks into smaller chunks of work and make sure there are enough people to manage them. Schedule ‘fire breaks’ where the team can catch up.

Manage resources

Look at where you can build in more time, or more slack, for example by not having someone due to work on two back-to-back tasks and making sure people are scheduled at a lower level of availability over resource-pressured times like holiday seasons. Even better, ring-fence the resource so they are solely dedicated to your project and aren’t trying to juggle their day job or other project commitments at the same time. Use resource levelling to spot where you might have problems and plan around those.

Make sure there are enough people available with the right skills so you can avoid the bus factor. Give people the tools they need to get their work done so they aren’t slowed down by not having access to the right kit or software and automate what you can so they don’t have to do those tasks at all.

If you want to avoid risks completely, you will have to think about how you plan and resource the work. Review how you prioritise requirements or look at the schedule. Think about how work can be rearranged between people or across the timeline to reduce the risk to nothing.

It might not be possible – in fact, I’d bet it isn’t possible – to avoid every risk, because that’s the nature of projects. But there could be some specific schedule, resource or scope risks that you could remove from your log because of the choices you and the team make.

What else would you add to this list? Let me know in the comments!