The Money Files

It’s the time of year where people are thinking about how well projects are performing. (Actually, isn’t that all year round?) Which means it’s health check and ‘look back’ time for lots of project managers as they evidence what they’ve done all year and how it has made a difference.

A health check is a useful thing to be thinking about as it shows how the project has performed and what areas you might want to focus in on as you move into 2026 – for this project or for other projects.

However, I know a lot of project managers avoid them because they feel like they will uncover too many skeletons in the closet – there’s too much scrutiny on what might have gone wrong. No one wants to intentionally put themselves in a position where poor performance or bad choices might point the finger of blame at them.

Putting that aside, if you can reframe a health check as a positive way to reinforce what is working and focus in on what is not, they are a useful exercise. As a team leader, you can talk to your team about running reflection sessions to dive into how the project is going.

When to do a health check

There is no ‘right time’ to do a health check but here is when I would be scheduling one:

• Mid-project reset
• Change in leadership/sponsor
• Post-crisis or post-pause

Or at any other time where it fits your governance model.

What to cover in a health check

In a health check, you’ll be looking at scope, schedule, budget, risks, stakeholder satisfaction, team morale and anything else you think might be relevant to help understand project performance.

Tools and templates

You probably have all the right tools and templates already. Check out your PMO document library for:

• Simple scorecard
• RAG review
• Short-form survey that you use with stakeholders and team members to get feedback

How to run it

Keep it short and constructive. You don’t need to spend ages planning for it, or ages holding it. The notes and write up should be short and to the point, highlighting areas to continue and areas to switch up and try something new.

Involve neutral facilitators if needed. Sometimes (I’d say all the time) we are often too close to our own projects to be able to see what is going on in an objective way.

Use it to align and re-energise. The whole experience should leave the team feeling lighter and more able to focus on what is coming up for project milestones – it’s not ideal to leave with a huge To Do list of improvements that you won’t have time to implement. Aim to get two or three things out of it that you can do easily to help the team move forward and improve project performance. Any more than that and chances are you won’t ever reach the end of the list. You’ll spend more time trying to implement process improvements than delivering the project, and that isn’t a good result for anyone.

Remember: Work with the team to reframe health checks as maintenance, not judgment. They should be something that easily slot into the project schedule and are a positive experience with some great learnings that you can implement quickly.

Leave the deep dives for full-on audits and keep quick health checks part of your retro routine!

1. Data mapping

1. Data Processing Agreements (DPAs)

1. Due diligence

1. Data security and risk mitigation

1. Testing

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.

I’ve been managing a programme for a while now, and it’s quite different from managing projects, or the very large projects that we call programmes that are really not programmes!

Programmes need their own budget as well as the budget of the projects, and here are the things I think should be included in that.

1. Costs of running the programme

It seems silly to point it out explicitly, but there are costs incurred from running a programme with a programme management structure.

For example, my time as programme manager needs to be costed and included along with any support resource from the programme office. Even though we are not full-time, the programme wouldn’t run without us so our costs have to go somewhere.

Ideally, there would also be a programme-level risk budget for handling unforeseen issues.

You may also find that on your programme there are other costs associated with running the programme, such as office space, software licences for third parties to access your programme management software (which is likely to be the same project management software everyone else uses, so hopefully not too large of an overhead there).

2. Assurance costs

Are you planning on having internal (or external) audits and reviews as part of the programme? If so, those costs should be picked up by the programme budget.

Internal reviews, in my experience, don’t cost anything except time, but if you are bringing in consultants or external auditors, there is definitely a cost associated with that (as well as time). Certification or compliance programmes may have extra costs here too, for example, if you have to comply to certain standards, going through the accreditation process is both time-consuming and normally costs something. There’s also often an annual cost to main the accreditation so factor that in too if your programme is multi-year.

Plan all those costs into the programme budget at the frequency and estimate required.

3. Benefits realisation costs

Benefits might be realised at project level, but you’ll likely have some programme benefits to track as well. And the cost of delivering and tracking those should be included somewhere – in your programme budget.

For example, you may need to programme software to create new reports. You may need a new role, and someone hired to go into that role. Some benefits might include making staff redundant due to organisational restructure, and there are costs associated with that activity too.

Plan all of those in at programme level. You may find that it’s useful to take the project-level benefits realisation costs into the programme budget as well so you can track benefits all in one place, but that’s up to you.

Project costs

Of course, there are costs to running the projects too, and in your overall programme budget, you’ll want visibility of those for forecasting and tracking. But these are the ‘obvious’ costs so it’s likely you already have them.

The project costs would normally include the large infrastructure type items that are necessary for the programme to move forward. The first project would normally take the hit for any large infrastructure-type investment, but that makes the business case for that project rather wobbly. You might decide that large capital costs are picked up by the programme as an overhead instead, and then each project goes forward on its own merit without having to fund the infrastructure required to make it and future projects work.

Talk to your financial analyst or project accountant for how best to apportion the costs across the programme and projects so it’s transparent and reasonable.

Earlier this month, I wrote about our summer trip to a holiday park. Two of the shows we saw while we were there were magic shows. One was a comedy-style show with some fun magic thrown in. The other was a ‘proper’ serious magic show with all the atmospheric lighting and big illusions.

It got me thinking – I know, this is not how most people spend their holidays, but perhaps project managers are this way inclined – about the parallels between the shows and my job back at base. Here’s what I learned.

1. The wait is part of the journey

We learned on other holidays that if you want a good seat, you have to get to the show early and sit and wait for a loooong period of time for it to start. This is because there is no allocated seating.

While we were waiting for the show to start, having arrived 40 minutes early, the family at the table next to us got out a game to play. They used the downtime as family time, getting everyone involved. It was part of the experience for them: being around a table to play a game.

We had brought books and electronic devices, and we were all occupied but not together. We weren’t using the time as family time. We were just waiting.

The wait is part of the experience. Plan for downtime on your project. How can you use that time productively? For example, can you bring forward tasks, fit in a peer review or a risk review, run an audit, or something? Where there are slower periods on projects, what are you going to do with them?

2. Same prop, different delivery

Both magicians used an identical prop, and they both performed Houdini’s Metamorphosis trick (where one person is locked in a box and the other stands on top with a curtain – they drop the curtain and they’ve switched places).

But the delivery was different. One was fun and light; the other was dark and dramatic. But the box looked the same, and the trick was the same.

Tailor what you’ve got to make it yours. The lesson for me here was how one item could be used so differently. Tailor what you use to make it relevant to your project and the way you want to deliver your work.

3. If you’ve not seen it before, it’s magical

The second magic show contained big set piece illusions: a box pierced with swords, but amazingly the magician inside was still safe, making snow from a piece of paper, levitation, escaping from a strait jacket before a flame burns through a rope and the magician is squashed. I am a huge magic fan, and I’ve seen all these before, in live shows and on TV.

But for my kids, they are new.

And they were truly amazed.

Don’t take for granted what you know. For some of your stakeholders, the magic of project management will be new for them. Train people in the process. Let them know what to expect and help them understand things about the process that feel new and different.

You’ve seen it all before; you’d read about it, done it, written the documents, and got the T-shirt. But they haven’t. Give them the support they need to come along the journey with you.

Project management isn’t really magic, but some days it feels like the team comes together, and we’ve pulled off something amazing. Don’t you think?