The Money Files

Definitions project managers should be confident using

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!