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.

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?

Sunk costs… what a headache when it comes to decision making. In this video, I talk about what they are and why they are a problem. If you don’t feel they are a problem for you as a project manager, then all credit to you!

In summary, sunk costs are those that have already been paid out. They are budgeted expenditure that has already been committed – the company can’t get those funds back. I agree they absolutely that this expense shouldn’t cloud your judgement, but unfortunately not everyone in the project sphere feels the same way and often decisions are made with sunk costs playing a large part in what next steps are taken.

In my view, project sponsors who feel that saving face is more important than business value are most at risk from making choices that perhaps wouldn’t stand up to too much audit scrutiny when the project is reviewed for benefits in a couple of years’ time post-delivery. Having said that, everyone is at risk of feeling invested when they have poured effort into working on something.

We have to work really hard to make sure that sunk costs, and the emotion attached to a project, don’t play a part in tough decisions about the project’s future.

Watch the video and then share your thoughts in the comments below: am I right, or is there more to it? Can’t wait to hear your views!

If you’ve been working in project management for some time, you might be familiar with the idea of variance. However, new project managers, or those who haven’t had to prepare financial information about their projects before, might find the idea a bit harder to get their heads around. Keep reading – this is for you!

I was speaking to one such project manager recently. While she had a ton of experience, she hadn’t needed to provide financial information for her projects as it wasn’t part of her stakeholders’ expectations. When the costs are mainly internal resource, many companies don’t require project managers to work that out in money terms. We tend to just estimate in days or some other unit of time and that’s good enough.

However, there will come a point in your career where you will most likely be asked to start crunching budget numbers for your projects. As you move into environments with greater levels of project management maturity, for example, it becomes more important to track things across projects in a standard way.

Budgets for money are the same in principle as budgets for time: you still need to work out how much you need and how much you are using, just like you would for time tracking on a project where you are only estimating in person hours/days. There’s another ‘however’ coming though…

However, in many organisations, including those where I have worked, it isn’t always necessary to track time. You create a project estimate at the beginning that states how many hours etc are needed from a resource in order to secure that resource, but after that, people are simply expected to manage their own time and the project is expected to conclude on the day you said it would. Timesheets don’t feature.

So, moving from this loose ‘we make a guess at how long things will take and go from there’ environment to one where you are expected to submit project reports with variance figures each week can be quite a challenge!

Luckily, the maths is not complicated and while it might seem daunting (especially if the numbers are big), variance is easy to track.

Budget variance

Here’s how to calculate budget variance.

Variance = Actuals + forecast – budget

In other words, you add up what you’ve spent so far with what you still have left to go, and compare that the original approved budget. The difference is the variance and shows whether you are under or over spent.

At the very beginning of the project the actuals are zero as you haven’t done anything yet. Each reporting period, simply pop the actuals into the right column and adjust the forecast down. Assuming you are on track, that is!

If you aren’t on track to hit your original estimates, you should be reforecasting the still-to-do work and noting those figures in the forecast column. Forecasts can change for lots of reasons including:

• The team created estimates that were based on assumptions that haven’t held true
• The team wasn’t very good at estimating
• More work has been added to the project as the result of a change request
• Work has been removed from the project as the result of a change request
• Resources have changed and now you are working with someone less experienced who will take longer to do the tasks
• Something else!

If you keep your forecast and actuals columns up to date, the rest is easy!

Tolerance

Normally there would be some tolerance agreed for the variance. For example, being under or over by 10% of the budget is OK but anything over that needs escalating to management or a change request etc.

Setting tolerance with your project sponsor will prevent you from having nightmares every time your project report says you are a few percentage points over budget.

How to get started

Make a spreadsheet that has the various columns. The simplest way is to have one column per field (actuals, forecast, budget, variance) and note the figures overall. As you get comfortable doing that, you might want to break them down by month to get a better idea of how things are tracking over time.

Once you’ve played with your project’s figures and have put together a spreadsheet to track them yourself (I recommend doing that instead of starting from someone else’s template so you can see how they fit together and what sums sit behind the columns) then you’ll get used to working out the numbers in this way.

I’m not a maths whizz by any means and I can manage it, so I’m sure you can too!