The Money Files

OK, it’s been a while since the summer holidays for us here in the northern hemisphere, and for a while, I’ve been musing on some things I noticed while we were away.

During the school holidays, we took our children to a holiday park – one with a swimming pool, mass catering options, and evening entertainment. During the entertainment portions of the trip, guest services reps – what’s the proper name for those? – milled around before the show started. They managed the queue, checked tickets, and then talked to us while we were waiting for the event to begin.

They were excellent at customer service and making the time feel like it was going faster. Here are a few things I took away from the holiday that I think we could be implementing in project management.

It’s all about the merch

Get your guests in for one thing and then cross-sell them something else. “While you’re here, would you like a hat?”

No, I don’t want a dinosaur hat, but plenty of people in the audience must have bought them for their kids.

The merch stands were obviously secondary money-spinners. The shows themselves were included in the cost of the holiday, but things to wave in the crowd, books, soft toys, and more were on sale at every show we went to.

Takeaway for project managers: “While you’re here, can I also ask you about…?”

Think about who is coming to your meetings and what else you need from them that is beyond the scope of the meeting. Can you ask about an upcoming project? Secure some support for a different initiative?

What can you showcase to a captive audience in a team meeting or even a one-to-one conversation with a stakeholder?

You could even ask them if they need any help with anything else if you are looking to build your network or take on different projects in their area.

Warm people up

Ten minutes before a show started, we’d get a warm up. “Who’s excited to see the show?” Plus lots of reminders about photography, how to order drinks, signposting guests to various social media accounts to follow, or even pointing out the merch stands by the side of the stage in case you had changed your mind about that dinosaur hat after all.

Takeaway for project managers: Build excitement and let people know what is going on.

Let people know how long they have to wait or to do something. Repeat the basic instructions several times. Engage across large groups with broadcast updates and keep reminding people about the benefits, tasks, and activities.

Start high

We did enjoy our time, and we decided during the stay to book again to a different park in the same chain for next year. They encourage people to do that, as you would imagine, by having an on-site shop that discounts holiday bookings for people who book again before they leave.

When I went to book again, I got pitched the most expensive accommodation at the other park, almost £1,000 more than I wanted to spend. We then reviewed all the options and found different ways to bring the cost down to our budget.

Takeaway for project managers: Ask for what you’d like and then work down from there.

When you ask for time, resources, budget, or another type of contingency, be generous with yourself. Start from the position you’d feel most safe in, and then negotiate from there.

Note: this approach might not work so well for risk appetite! You’d want to do it the other way round. Start low and increase the risk as you feel more confident.

The main thing I took from all of this is that there are useful tips and lessons from other management disciplines that are applicable to how we work on projects. While we focus on learning about project management as part of our career journeys, actually, the role of project manager can be far broader as it involves liaising with lots of different business areas, and they all have something to teach us.

The PMBOK® Guide – Seventh Edition talks about four different ways to define business value.

‘Value’ is quite a vague term when it’s used in everyday speech, so I think it’s useful to have something to hang a definition on when we’re using the term in project management.

The Guide does specify that there are lots of aspects to value, including non-financial considerations, and that the four ways that are listed are only some of the ways that you could measure value. However, they are a good starting point if you’re trying to have conversations with execs about what projects you should work on – you do need some kind of idea of what value means.

Here are the four metrics that you can use to measure value, as outlined in the PMBOK® Guide.

1. Cost benefit ratio

This ration works out the present value of the investment compared to the initial cost, basically, do the costs outweigh the benefits (if they do, you probably shouldn’t start the project unless there is a strong justification for doing so in the knowledge that it will cost you more to deliver than the benefit expected).

2. Planned benefits compared to actual benefits

This is a bit of a weird one if you ask me – until you start delivering, you don’t have any actual benefits to compare to. It’s fine if you want to review value after the project is complete or while it is in progress, but it’s not a metric you could use for project selection.

You’d have to use the planned benefits, and that really is the planned value of the work to the organisation – so it’s just a different way of talking about the other metrics until you have some actuals.

3. Return on investment

This is my favourite of the four (is it odd to have a favourite value metric?). Probably because I use it the most and it’s very clear on what it is. It’s easy to explain to stakeholders and finance teams seem to like it.

Plus it’s easy to work out.

ROI is the financial return compared to the cost, so it’s helpful in project selection. However, you can use it throughout the project to refer back to whether or not you are on target to hit that particular ROI – useful to do when your costs are going up.

4. Net present value

NPV used to confuse me because it’s time-phased, but once you get your head around it, it’s straightforward. It’s a very common metric in use for project selection so it’s definitely worth taking the time to understand how it is put together and what it means.

You can measure NPV throughout the project and check that the investment still holds up.

With all of these, as long as you keep measuring if you are getting enough value out of the project, you can make an ongoing commitment to keep the work going. If the numbers point to a trend of decreasing value, there is likely to be a point where you’ll want to stop the work, because the amount of effort expended isn’t worth the value you’ll get at the end of it.

Of course, there are some projects where the value is simply being able to continue to trade or operate within a legal framework, or benefit related to social/corporate responsibility or sustainability, so you might find it irrelevant to track metrics like the ones above. The takeaway from all this is to work out what ‘value’ looks like to your team and your project, and measure that.

How do you do it? Let me know in the comments!

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?