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.

Risks get logged on our spreadsheets or in our tools, but it’s often the identification part that people find difficult.

Below are 5 causes of risk. You can use these as a jumping off point for your own risk identification. What would happen on your project if one of these causes created a situation for you?

1. Equipment failure

On projects in the past, we’ve had the local council cut through power lines while doing work digging up the road outside one of our locations.

We’ve had internet outages. We’ve had component failure. And once one of my colleagues had their laptop stolen from out of the back of their car – not exactly a failure, but it caused the same kind of situation. If you’ve ever lost a piece of tech you’ll know the headache that comes with getting a new one and all the governance paperwork to fill in too.

What risks could you have on your project around equipment failure?

2. Planning errors

Incorrect estimates, incorrect assumptions… these all lead to the potential for your plans to be wrong.

Even missing out someone’s annual leave or scheduling over a bank holiday because you didn’t have it on your calendar can cause a delay.

You might have risks related to the accuracy of your planning and scheduling.

3. People problems

A lot of project risks are created by people! For example, in one situation I heard of, a project team hired the wrong person for the job. The candidate said they could do the work, it sounded like they could do the work and when they showed up, they couldn’t.

Other risks could be the risk of someone not turning up (as has just happened in our house with contractors due to fit the new floor), refusing to do the work, changing their daily rate or is otherwise demonstrating difficult behaviour.

Even if you can resolve the problem, sorting out challenges like this takes time and energy, and often we don’t have much of that on projects.

What people-related risks can you foresee on your project, and what can you do about them?

4. Watermelon projects

Another risk is that people don’t report the true status to you so you end up with a watermelon project: green on the outside and red in the middle.

You can deal with that risk by making sure you have processes for adequate reporting and are able to understand the current situation. If you don’t have visibility, you can’t control the project.

Could one or more strands of your project be at risk of going watermelon?

5. Miscommunication

Finally – and this can happen on any project – miscommunication. Team members do things wrong because they don’t understand or they haven’t had complete instructions.

In theory, this one should be easy enough to resolve, so much so that you might not even think it is worth putting on the risk register at all. However, if you work with a cross-cultural team, different time zones or remote teams then it is probably a higher risk factor for you.

Would your project be at risk of communication challenges?

Mostly on projects we think of ‘resource’ costs and ‘resources’ as people. Because mostly, with the majority of office-based, corporate-led projects, what we need to get the work done is people’s time. And people are expensive.

Meetings in particular are often left out of the time-budget. We’ve factored in the cost of the hours required for them to deliver their tasks, but not for them to show up to project team meetings, lessons learned calls, extra meetings because something in someone else’s area has gone wrong, and so on.

So factor in enough buffer time for the overhead of meetings for resources that are booked out to do work on the project.

But what about the other things we need to cost out in project budgets that aren’t people’s time? There is a whole host of smaller (and bigger) costs that it is worth building into your financial planning if they are relevant to you – because even the small costs start to add up when you are asking for ‘real’ money (versus people’s time which is wooden dollars if they are internal resources).

Here are 12 non-labour costs that you might incur on your project.

1. Room hire and hospitality

In my last job, we had open plan office space and very few meeting rooms. They were reserved for the exec, and it was difficult to book them. Even if we did book them, I remember being bumped out of a room because someone more important than me needed it (they did give me notice, to be fair).

Room hire costs might be something you need to factor in, and with that comes catering for people attending.

In fact, it’s not just meetings. On one project, the team had a portacabin on site as their project war room. That was a space we had to pay to hire.

2. Event hosting

Event hosting also falls into the bracket of room hire and hospitality – but it’s not necessarily project stakeholders attending.

Perhaps you have clients who need to see the new release of a software product. Perhaps you’re running an industry conference as part of the product launch. Perhaps you have training events for internal staff who need to travel and be fed when they arrive.

Training events might also incur the cost of producing materials for the delegates or paying an external trainer, as well as hire for the AV kit in the room.

3. Admin support

Sometimes projects require admin support.

You could buy in a VA (virtual assistant), or even buy access to an AI-powered assistant for meeting note taking or meeting booking, and all the many other things AI can do for you these days.

You may also need transcription or translation services, depending on what you are working on and who is involved.

4. Travel and accommodation

On my first project in my last job, there was a lot of travel for the implementation teams. They were out on the road 4 days a week during most of the go live periods, supporting locations to implement new processes and tools. As a result, we had huge expense bills for petrol, rail travel, accommodation and food.

Fortunately for me, most of it went through the corporate expense booking system so all I had to do was add the numbers to the budget at the end of every month. It was part of the cost of doing business and keeping the project going.

These days, we travel less for work and do a lot more remotely, but you may still have to factor in days out of the office and on the road for some team members.

In addition, your in-house guidelines might allow for per diems or expense allowances for colleagues out and about. Be clear on whether you have your own internal rates or are using industry published guidance for these so you don’t have any queries when people submit their expenses.

5. Tech

Technology costs crop up even in projects that are not tech-led.

For example, you might need to access webinar tech to deliver training, or buy an online learning package. Even loading training videos to your existing online learning platform might incur a fee.

Most of the tech costs I have been involved with on projects come from having to buy hardware items or software licences. Those items rack up the cost, but they are often clearly known and factored into the budget from the start.

In addition to those items above, you might also have these on your projects:

• Other materials
• Utilities if these are costed to your project or required specially.
• Printing and binding (less used now with the focus on sustainable project management and green delivery, but there might be some things you have to create as hard copies)
• Web page and creative supportive
• Subscriptions
• Photography or photocopying
• Subcontracts – again, normally clear and well-known at the outset.

Link these costs to the person who is incurring them in the work package so they can be accounted for appropriately in the budget.

Have you ever been caught out with a project cost (and was it on the list above)? Share your non-labour common expense items in the comments below!

We talk about the cost of change often on projects. If you’ve been in a delivery role for a while, you’ll no doubt be familiar with the idea that if you find something you want to change later on in the project, it costs more to make that change than if you identified it at the beginning.

That’s typically because there are fewer things to unpick and less rework required because you haven’t got as far yet. You can change the buttons on the widget if you haven’t manufactured any buttons yet. Just change the drawings or spec and you’re done. But if you have a factory stacked with boxes of buttons, then there’s a bigger cost involved – all the pre-made buttons need to be scrapped and you have to manufacturer a bunch of new ones.

Understanding how much wiggle room there is for change is important in understanding how easy it will be to make change later, and how agile (with a small A) you can be during the project when it comes to addressing defects or changing your mind.

Bridge building, button making, house construction: all these are hard to change later. But business process change, website design, or software writing probably have a different result. You can tweak a process later on, and while a group of different stakeholders will be affected, it is certainly possible (and cheaper) to do in a way that changing the foundations of a building once half the building is built is not – it’s a different kind of conversation, and a different kind of cost involved.

How easy it is to make the change, and the cost of change, play alongside each other throughout the project.

The PMBOK® Guide 7^th Edition talks about Boehm’s cost of change curve. It sounds like common sense, but it is also important to challenge our assumptions and what we think we know. There is also a difference between bugs and changes that arise through active decision making. Is the cost of change the same for each on your project?

It might be possible to add a financial amount to each change and each defect so as to work out the potential cost of defects or changes addressed later in the lifecycle, but that’s probably overkill for most small and medium-sized companies, and organisations that are not software houses with plenty of data to analyse for this. Unless you’ve been through many product recalls or can model what it would look like to address a component failure, you might not have the data or time to create any meaningful cost models.

Instead, bear in mind the general principle: what is it going to mean to make a change on your project, for your decision makers, in your environment, for the development and delivery methodologies that you are using? Are there cutoff points? Points of no return?

Really?

Generally, as project managers we can make anything happen with enough money, time and resources – whether it’s the right decision to do ‘anything’ though is a completely different conversation.

It is sensible to think about the cost of change before you need to make any changes, and to consider how you’re going to avoid too many potentially costly changes. For example:

• Decent requirements
• Good quality stakeholder engagement so everyone is on board with the deliverables and no stakeholders are left out (as ignored stakeholders tend to want to insert  their requirements on to the project later when they do find out about it.
• A good change control process
• Robust attitudes to quality deliverables, quality control and assurance.

How do you think about the cost of change in your projects? Is it a discussion you have with the team? I’d love to know how you work to minimise it – or if you embrace it and go with the changes! Let us know in the comments below.