The Money Files

How do you pay for stuff on your project? We talk about preparing a procurement plan, but what are your options?

I’ve always found that having clear payment terms and a structure for the payments makes planning a lot easier. When I know when invoices are due or what deliverable is attached to what payment milestone, I can queue up conversations with Finance so they are ready to pay what is often a sizeable invoice.

There are 3 phases to consider when structuring a payment plan for your project:

• Before the project deliverables are fully complete
• When the project deliverables are fully complete
• Post-project follow up.

This is how they look when you put them into practice.

Before the deliverables are fully complete

This is the project execution phase, the stage where you are working collaboratively on creating the deliverables.

This is where my contracts often have stage payments so the vendor gets something before the end – useful for keeping motivation high and helping them pay their costs on a long project. After all, they need to be able to operate their business to support yours.

Generally, you’d want to make those payment milestones meaningful and relevant to the project. For example, you could set the payments to go out on completion of milestones that start generating benefit for the project.

Alternatively, do what we did and just split them by project lifecycle stage, so a payment is due on completion of the discovery/scoping and requirements finalisation, then another one during build and the final one on completion.

On the largest contract I’ve been involved with, we had multiple delivery point payment milestones as it was a long project.

When the project deliverables are fully complete

This is the point where you’d do the final payments related to the services or goods they are providing on the project.

All the doing is done, so you pay them for the work delivered. In practice, this is often the final stage payment.

Post-project follow up

There might be post-deliverable payments to make, for example any maintenance costs or ongoing service contracts that come into effect once the main delivery part of the project is wrapped up.

Perhaps this is a payment point that then initiates another round of payments for Phase 2 or subsequent work, or you might have written into the contract a mechanism for paying for additional work through change control.

At this point, if the project is done, you’d normally be handing over any open contracts to the operational team who will deal with the ongoing supplier relationship moving forward. Just document what you know and hand it over to them with any paperwork.

Ultimately, commercial relationships need to be beneficial for both parties, so it is helpful to work with the supplier in partnership to work out a reasonable payment scale. We involved lawyers on both sides to draft out the documentation and help with the negotiation because it was a big investment and we wanted it to be right.

Putting the time and effort in to working out suitable payment milestones, stage payments, processes for change and so on meant that the working relationship going forward was pretty smooth. Both sides knew what to expect and we had documented approaches for dealing with changes and disputes. Plus, from a project management perspective, I knew exactly what would trigger a stage payment and I could plan for the acceptance paperwork so we were ready.

Last month I looked at what you need to consider when setting up programme financial management, drawing on The Standard for Program Management, Fourth Edition (2017).

Today I wanted to write some more about financial planning at programme level (as we would spell it here in the UK), again, using The Standard as the foundations but sharing my experience as well.

The financial management plan for a programme

The Standard talks about having a financial management plan which is made up of:

• Funding schedules and milestones (financial timeline)
• Initial budget
• Contract payment and schedules
• Reporting activities and how reports will be managed
• Metrics for reporting and controlling finances

This all fits into the overall programme management plan, but could be a separate document.

The document is supposed to outline a lot of information about how money will be managed during the work. It should go into detail about:

• How risk reserves will be accessed and used
• How the programme will deal with financial uncertainty e.g. international exchange rate fluctuations, changes in interest rates, inflation, currency devaluation etc
• How the programme will deal with cash flow problems and if any are already identified
• What the local laws and compliance regulations are and how these will be met
• Incentive and penalty clauses in contracts.

In addition, as with all plans, you should include how the budget is going to be approved and what that authorisation process looks like.

In my experience, we did not have all this written out, although we did have a Finance team who were very much on the ball and probably had considered it without making it my job (thank you, wonderful Finance Manager!). In addition, the detailed technical budgets, which represented most of the cost (aside from staff) were put together by the technical architect, and were comprehensive. By the time it was my turn to look after the numbers, the paperwork seemed solid and it was very much a tracking exercise. I can’t take too much credit for the planning effort.

We were using international resources so the currency issue was very much relevant, and so was the risk reserve because we were doing something new to us with a high degree of uncertainty.

To be honest, I’m not sure we had a formal process for risk reserves either. Contingency had been added to the budget, but we did not allocate budget to risk management activities on a per risk basis. Given the scale of the investment, that was probably a mistake! I don’t recall any terrible dramas happening as a result of not having funding assigned in that way, even when the programme timeline was extended.

Contract payment schedules were documented in the contract instead. Our legal team bound up the contract and relevant schedules into little A5 booklets and I had one that sat on my desk and became my go to reference for all things to do with service level agreements, contract expectations and when I had to approve certain milestones to issue payments.

One time, I issued the payment notification and requested the funds be paid, but I had not warned Finance such a large request for cash would be coming so the actual payment was delayed a few days. That taught me I needed to start my process earlier so that Finance had notice that a large payment was due as part of our contract schedules.

Planning at a programme level feels harder because there is generally a bit more uncertainty, the timescales might be longer than your average project, more people are involved, and the numbers are higher. However, it’s never one person’s job. As you come together as a team, experts can provide their input to make sure the final result is something the governance team, finance team and programme management team can be confident with.

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!

The Standard for Earned Value sets out an approach for scope management with the goal of maintaining the performance measurement baseline. You need to keep the integrity of the baseline, otherwise there is no point in having it to measure against.

And given that change happens, you need a plan for dealing with those changes. I was interested in finding out why there needed to be a separate scope management process in the Standard. Perhaps you manage change differently if the project uses EV methods?

I suspect you don’t – but you do need a way to tie scope changes back into the time and cost baselines so your EV metrics don’t go off track.

Read along with me as I dig into this Chapter of the Standard and uncover what’s different about managing scope in the world of earned value (it’s Chapter 10, if you are interested).

Inputs

There are four inputs to this process:

• The project management plan – in particular, the performance measurement baseline and the integrated change control process
• The performance measurement baseline. So important they mention it twice – in the plan above and in its own separate called out line!
• Change requests – because we’re talking about what happens when a change happens
• The integrated change control system – this is the process for change control. Is a process really another input to a process? I get that having a way to evaluate project changes is important if you want to evaluate a project change. Let’s assume this relates more to the tech, decision making framework etc.

So what do you have to do with those inputs?

What to do

There are three main things that need to happen as part of this process.

First, the change should be analyzed. The Standard suggests that a Change Control Board is convened to do that. I think the CCB is a really useful group and we relied on it in my last job. Our CCB looked at operational and project changes so the team could see the impact of ‘normal’ changes as well as the project-related ones.

I think this really needs to be done, at least at an introductory level, before the CCB gets together – otherwise what will they talk about? In reality, all these things have to happen in a logical order because you might approve the change but then need to do the analysis of what happens to the project in terms of the work.

For example, you need to update the baseline and the WBS to incorporate the change. The tasks to be done are added to a work package, and in EV, the process for doing that is a bit counter-intuitive. The Standard explains you close the current work package and move the money to the new work package, along with the new budget for the new tasks. The rationale for this is to maintain the integrity of the cost variance while removing any schedule variance. Create a new control account and carry on.

Then, the cost and schedule baseline need to be revisited. That improves the correlation between the work to do, and the baselines for budget, scope and time.

All in all, there is a surprising amount of work required for handling a scope change in an EV setting. No wonder you get the impression that it’s hard to make changes and that there needs to be adequate planning up front to avoid extra tasks arriving later.

Outputs

The outputs from this process are:

• Performance measurement baseline updates (let’s hope you have the tools and support to make this part easy)
• Project management plan updates (review the WBS and dictionary, plus anything else)
• Change request status updates (update the change system to note what was approved/rejected etc).

I read this chapter and was surprised. I mean, not surprised that you have to do scope control or update the baseline, but surprised at the admin involved in re-aligning all the different aspects of the performance measurement baseline. I suppose I knew that it needed to be done hypothetically, but I had never unpicked what it would look like to have to do that work.

I have a new respect for schedulers and project control managers.

Not only do you need to deal with the change and incorporate the decision to do it into the work (which all projects need to be able to do), there’s an added level of admin required to maintain the integrity of the EV reporting.

The Standard says, for example, “Budget must never be transferred simply to eliminate variances.”

Well, back in the day, I did exactly that. On a project (where we were not using EV), our overall capex budget was set. I had the flexibility to move money around within the different capex lines, as long as overall we stayed in budget. So I did. It meant the difference between hospitals receiving the kit they needed to work efficiently or not, and it was never large sums of money. The budget remained overall balanced, and no one really minded how it was distributed as long as everyone got what was needed and we knew where the cash was going.

I learned a lot about budget tracking from that project and I quite enjoyed it. I’m not sure I would have enjoyed it as much if I had had to incorporate EV reporting as well.

There’s a worked example in the book, so if all this doesn’t really make sense to you, or you can’t see the flow of the changes, that’s helpful.

Pin for later reading