The Money Files

Last time we looked at the different times in a contract where you would be scheduling payments. Today, I wanted to write a bit about the different types of payment you could factor into your work with vendors to give you some variety with how you structure payments.

Before we start, make sure to discuss any payment plans with your procurement and finance teams, so you don’t end up committing your company to something that you really shouldn’t! In my experience, contracting and procurement are really outside a project manager’s pay grade – organisations generally want the specialists involved, and most project managers would not have authority to sign contracts.

However, it’s worth knowing about the different payment options out there, so you can mention them in conversations with the right people if they are relevant to how you think your project would be best served.

Here are some options to consider for your next project procurement activity.

1. Uptime/availability payments

This is something to build into service level agreements. In the past, my projects have needed to set up SLAs, and uptime payments were built into those.

In essence, vendors get an incentive payment for keeping the service available instead of penalty clauses for downtime.

You could use this principle to build in payments for services or support being available, and you could have various thresholds that trigger different payments. Or you could put penalty clauses in for downtime, but that’s not so good for relationship building. The management at my last company was very much against punitive clauses as they believed it did not incentivise a partnership relationship and was too much centred on blame.

If you do put these clauses in your contracts, make sure you also document how you claim the payments. For example, for uptime incentives, if I remember rightly, we had to claim them, and sometimes for the value offered, it wasn’t really worth the admin… so think that through before you write them into contracts.

2. Performance payments

I haven’t used these personally in projects, but I believe they are common in construction (are they? Let me know in the comments).

This would be a payment related to hitting a particular performance threshold, perhaps delivering early on a particular milestone, or reaching some kind of target. When we pay for services, there are often performance-based payments built into the schedule. You’ll have seen these, too if you do any kind of online transaction processing. For example, I signed up for a service linked to my personal website that allows me to have up to 10k of transactions per month at a flat rate fee, and then if I go over that, the next tier of payment-based payments kick in. Payment is based on how many transactions you put through the system.

That could be relevant for your project if you are launching a service where volume or number of transactions or units processed would trigger an additional payment or an additional discount.

3. Incentives

You could find any number of ways to incentivise vendors. For example:

• Productivity savings
• Process improvements
• Staff savings
• Time per transaction saving
• Decrease in number of complaints or increase in staff satisfaction as measured by a survey

In addition to the ones I’ve already mentioned above. Anything that reduces overall cost of the service or product could be passed on to the client (your project), and there could be an incentive payment linked to that – ideally something that is beneficial to you both, not just cost-cutting for cost-cutting’s sake.

Have you used any of these payment methods on your projects? Let us know in the comments!

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.

The Planning performance domain in PMBOK 7 covers all things relevant to making sure the project is adequately planned. We want to address all the work required to deliver whatever the project is delivering, and to do so in an organised, thought-through way.

Planning for the financial aspects of your project is covered by this domain.

Budgeting

Budgeting is the obvious one: as part of putting together the early steps of getting our project off the ground, we need an idea of how much it is going to cost. That means taking info from the task and work estimates and using that to create a cost estimate.

Building out the cost baseline forms part of the project planning activity and then it’s used to track against. Project performance can be measured against the baseline, in the same way you do for tracking schedule activities. In fact, combine cost and time schedules help you phase the spending. Even if you don’t go ‘full EVM’, a phased budget is helpful for the finance team to manage cash flow and for the project team to track whether work is broadly happening at the expected pace.

Financial management

Knowing how you are going to manage the finances is also useful and worth working out at this point. For example, how often are costs going to be reviewed? What contingency reserves are going to be put aside and how will the team access those? What’s the process for getting purchase orders raised and invoices approved for payment? Do you have access to a management reserve and if so, who is going to approve using that funding?

Procurement planning

Most of my projects involve buying things from suppliers. Whether it’s something small or a multi-million pound deal, procurement activities are a big part of what we do.

It’s important to spend time in the project planning phase thinking through how procurements will be managed. Will you have a dedicated procurement professional to manage the contracts and run point with suppliers? Who is going to manage supplier relationships? What’s the process from choosing a supplier and negotiating a price to actually getting the contract signed off and the order raised? I know from personal experience that this process is easier said than done!

If you have someone managing the contracts on your projects, they will need to know what the project needs to buy, when the team needs it for, what the lead times are likely to be and a lot more. Given that at the moment the lead times on all kinds of equipment and building materials seems to be extending – our own build project at home has been delayed – and the price of materials is rising – it’s really important to be all over the numbers, process and plan for this aspect of your project.

There’s more to the Planning domain than simply thinking about the money and contractor relationships, but these aspects are essential if your project involves procurement work. It’s all too easy to get sucked into scope discussions and deadlines and milestones – because executives want to know when the project will get delivered, not who in Finance is going to be processing the requisitions.

So this is just your friendly reminder to make sure you allow adequate time in the planning stages of your project to factor in the finance planning – and that it’s an ongoing activity for each stage, and as your project evolves.

In this part of my occasional series on program cost management, inspired by The Standard for Program Management (Fourth Edition), I’m talking about 9 financial management tasks that you should expect to do as a program manager.

1. Identifying changes

First up, be aware of what might be coming over the horizon to influence the budget baseline and what factors are leading to changes. This is basically being aware of what might create a change so you can be on the look out for any changes. It’s proactive listening and always considering what a course of action might do to your budget.

2. Monitoring for impacts

Part of the daily work of a program manager is keeping your eye out for any environmental factors that might impact the program overall, and budget changes are part of that. These could be environmental factors like changes in regulation, access to skilled resources from the local hiring pool, or access to the right technology – anything that could have an impact on the budget.

3. Managing changes

What happens after you scout the horizon for things that might change your program budget? You find things. Part of a program manager’s tasks is to manage those changes. The change could be to scope, to the schedule, to the resource profile, procurement plan, or anything else, and we have to play back what impact that is going to have on the budget and build in the changes.

4. Monitoring cross-project impacts

As I mentioned in my last article, part of my role as a program manager is being able to shift funds between pots to ensure the overall program goals are met. That’s what this task is all about: monitoring the impact of what happens when costs are reallocated and making sure that overall the program components are balanced – or at least as balanced as they can be.

I mentioned cross-project impacts in the heading, but programs often include an element of BAU work and that can just as easily be affected by changes.

5. Monitoring supplier contracts

Some suppliers might be contracted at a program level, so it’s the program manager’s job to ensure that suppliers get paid in line with their contracts. With one supplier I worked with, we had contractual milestones in place. When each milestone was reached, another stage payment was due.

Part of my work was ensuring Finance was aware that a stage payment was due so they could have the right amount in the bank accounts ready to pay when the time came.

6. Earned Value Management tasks

If your program uses earned value management, you will work with control account owners, project managers and other experts on the team to make sure EV practices are implemented and adhered to. Part of the role will also be making sure everyone can interpret the outputs of EV reports and manages their part of the schedule accordingly.

7. Dealing with over and underruns

It’s unlikely that your program will be perfectly on budget every month because that would rely on your estimates being perfect and no ‘real life’ happening during the work. It’s more likely that you’ll be a bit under or a bit over.

Part of the program manager’s role is to manage within that tolerance and to advise and support project managers on the program to do the same.

8. Working with stakeholders

Another big part of program management is communication and engagement with stakeholders around changes. The sponsor, customer, client and governance groups (including auditors) need to have access to transparent information around the program’s financial measures. You have to provide that.

9. Managing within tolerance

Finally, the main, most obvious part of the role is to manage the program’s spending within the levels expected. You may have set tolerance at individual component level, or there may be other ways you are managing to within the expected parameters. These should be clear, so everyone knows how the work is being tracked.

And, if you spot that you are not managing within the parameters and boundaries set, then as the program manager it’s your role to take steps to get back on track, whatever those actions might look like.

The Standard for Program Management (Fourth Edition) talks about how to track program financial metrics once your financial management plan is up and running. I thought it would be worth comparing the guidance to what I’ve done as a program manager to see how I measure up – and you can compare your own practice to what’s in the Standard too.

Program financial management, as a refresher, is defined in the Standard as:

Activities related to identifying the program’s financial sources and resources, integrating the budgets of the program components, developing the overall budget for the program, and controlling costs during the program.

Once you’ve got the program going, your work as a program manager shifts to tracking the money and making sure you are on track.

Spoiler alert: I’ve never used earned value to do this in real life, although I’m well aware of the benefits of doing so on projects and programs.

I think the techniques you use for tracking very much rely on your organisational culture and maturity levels, and I’ve not worked anywhere where EV is considered part of the way things were done. If you’ve got experience working in an EV environment, let me know how that goes in the comments.

The program manager’s role shifts to monitoring spending and controlling spending, ensuring what is being paid out is in line with the budget. In my experience, as a program manager, I’ve had a fair amount of latitude to move money between ‘pots’ (or projects) to ensure the overall goals of the program are met. And I have to say, I’ve enjoyed being able to make those decisions.

What I haven’t enjoyed is the financial scrutiny. I know we need governance on programs, and I’m all for it, but sitting in a meeting having to present the numbers has always been uncomfortable for me. Not because I don’t believe in the numbers, but because I’m normally presenting to people with an accounting background and honestly they could dance rings around me if they wanted to pick holes in my maths. So I have to put extra effort into making sure I can justify how numbers are put together.

My top tip is to make sure you keep detailed records of how you came to land on certain figures. For example, on a program I’m working on at the moment, we track committed spend, forecast and then actual “out-the-door” spend. But there are a couple of other strands within the program that are accounted for separately (don’t ask, it’s just the way it works best) so I have to make sure I’m clear as to what’s in and what’s out of the numbers so I can justify them every month and make sure we are reporting to the PMO on a consistent basis.

Because trust me, if I didn’t, I’d forget from month to month what the basis of calculation was and report something that wasn’t internally consistent and that I couldn’t justify reliably. Which would be bad.

Governance serves a purpose: it makes sure that a program is operating within approved cost limits and challenges programs that are forecasted to go out of those budget targets. Then the organisation can decide if it wants to continue with the program or not.

I’ve luckily never worked on a program that has been cancelled because of financial issues – but I imagine that is largely luck and the kind of programs I have been involved with rather than any skilful cost management on my part.

My experience of program cost management has been very similar to managing large project budgets: the skills are the same, and business acumen comes into play too. I think that having the bigger picture and goals in mind helps. What do you think?

In my next article, I’ll look at some typical financial management activities as outlined in the Standard and talk a bit more about those.