The Money Files

OK, this might not be relevant to everyone reading, but sometimes project managers are left with ‘spare’ budget in December. How are you going to make use of any available funds – assuming you are not under pressure to give them back – to maximise project value. Here are some ideas.

Conduct a year-end financial review

First, make sure your budget trackers and up to date, and that everything that should have been accounted for has been added on. That will give you a true picture of your actuals, so you can review the financial status of the project, including how much budget is left and what key areas need funding.

If you need to move money around, talk to the finance team so that the right amounts can be journalled to the right budget lines to tidy up your accounting.

Prioritise high-impact investments

Next, think about where you could use leftover budget in the remaining weeks of the year to make the most impact. That could be new tools (testing software licences are always a win), training for project team members, especially if that will help them develop skills they will need next year, or risk mitigation activities. Perhaps you can buy a few days of consultancy time that will speed up a particular task? Perhaps there are licences that need renewing, or equipment that you could invest in? Perhaps you could talk to suppliers about getting a discount if you place an order now instead of in January – many suppliers have targets to hit at year end and might be open to negotiation.

I think that spending money on training and certification is a good choice. It helps team morale as individuals see that their future is being invested in, and you get skilled team members who have the skills required to continue to support the project, or future projects. So my recommendation would be to look at investing here, in team development, if you aren’t sure what use you can make of additional funding.

If you need to buy anything, make sure to get approval and move quickly before the year end deadlines.

Don’t spend for the sake of it

We want to avoid wasteful spending. Be aware of what is going on in the rest of the organisation. For example, other projects might be struggling, and the most prudent thing is to always offer the money back to the ‘pot’ as a first point of call.

In my experience, budget that is not spent is not carried over to the new year unless it can be accrued against a committed spend. In other words, if you have got £20k sitting waiting to be spent, there is a high chance that you will lose it unless it is spent on something. Talk to your Finance team to find out whether that is likely to apply to your budget, and what they recommend you do at this time of year.

Work with Finance to reallocate funds

Talking of working with Finance – they are the guardians of spending rules and regulations, and they will help you maintain compliance and an audit trail for spend.

They will know if it is possible to carry budget over – and it might be, if your financial year does not end in December.

Are you thinking about year-end project audits? Perhaps your PMO is thinking about how to learn from the past year. Perhaps you want to set a good foundation for projects next year. Perhaps you just had a rubbish past few months and want a second opinion to see if there was anything you could have done differently to avoid the outcomes you got.

Whatever your reason, many project leaders’ thoughts will be turning to audits at this time of year, so let’s talk about how to make the most of this exercise – it’s not as awful as you might be thinking!

Planning the audit

First up, make sure the audit is planned in. Schedule it in advance to ensure key team members are available.

Look out the documentation that is required, which is normally things like financial reports, scope changes, and risk logs. You’ll also want to make sure that the business case, project plan, and schedule are available, as well as any change requests that changed those, so the auditor can compare the original planned baselines to the current baselines.

Key areas to audit

So what is your audit going to look at? Whether you have been asked to audit someone else’s project, or you want projects in your PMO to be audited, here are some things you’ll probably want to put on your checklist.

• Budget vs. actuals: Compare planned spend to actual spend and do the same for resource utilisation if you have the data.
• Scope management: Look at how many change requests the project had and whether that resulted in managed change or scope creep. Personally, I don’t think it is important to assess whether the project stayed within its original scope – what you are looking for is whether changes were assessed and approved rather than being done in an ad hoc manner.
• Risk management: You’ll want to go through the risk log to see how well risks were managed, mitigated, or exploited.
• Quality of deliverables: If anything has been delivered so far, check to see that the quality is comparable to the targets set. In other words, are there post-go live bugs still to sort out, and does the product meet quality expectations?

Identify lessons learned

The main purpose of an audit is to review what worked, what didn’t and what needs to change (or be continued). So you can think of the output of the audit as a sort of lessons learned report. If you already have scheduled lessons learned activities, you can feed those in to the audit report. If not, it never hurts to have a lessons learned conversation with the team.

Set the stage for next year

If your project is running into next year, discuss how the results of the audit can be used to improve processes, define new standards or ways of working, and inform the next year’s project strategy. There might be some easy things you can do to change up how things work to make them more effective.

Whether the outcome is a lot of things to change or the reassurance that you are doing everything right, it’s a good time of year to be reflecting on project management practice. Take stock of where you are and how far the project has come, and if an audit is offered, say yes! It really is a good learning experience.

You’ll see that at various points in the project management lifecycle you are supposed to review the business case and check it is still fit for purpose, but what does that actually mean? What are you looking for?

I’m not sure that continuing commercial justification of a project sits solely on the project manager’s shoulders, but you can do a first pass review and raise any concerns with the sponsor. After all, power sits with them to make changes to the project or cancel it, should it no longer be fit for purpose and likely to achieve its goals.

Here’s what to look for when you do a business case review to check if the project is still viable.

Strategic alignment

Hopefully your strategy doesn’t change that often, but if you’re managing a multi-year project or program, or you’ve just had some strategic change at the top, it’s worth checking to see that your project still aligns with the organisation’s goals.

Affordability

Can you still afford to do the project? In other words, have costs spiralled due to unforeseen issues, scope changes, requests from the client that have to be included because the contract was so vague they are saying you have to pay for it (of course, that never happens…) and so on.

The challenge with assessing for affordability is that it then opens up a conversation about sunk cost. If you’re three weeks off finishing the project, it may well be worth the cost uplift to get you across the line. If you’ve got two years still to go, not so much.

Riskiness

Look at whether the riskiness of the project has changed. Hopefully as you know more, risk levels have decreased. But a portfolio manager would probably want to assess the risk of this project along with the risk of the portfolio overall, and if the whole portfolio risk profile has changed, there are some conversations to have.

Look at whether your risk budget or contingency time in the schedule is adequate to cover the risk. If not, if you added more, would that make the project unviable?

Achievability

Consider whether you can still complete the work. Achievability might be challenged if key resources have left, deadlines have changed, a supplier has gone bust, or there are plans for a merger. Anything might affect your ability to achieve the plan as it is today.

If you can’t achieve the baselined plan, would a replan mean other criteria for viability are not met? For example, you could achieve the plan with more time and more money, but that would mean the project would not be a cost-effective initiative.

Benefits

Check that you are still going to get the benefits, or enough of the benefits to make it worthwhile from a cost/benefit analysis. If the project ticks all the other boxes, it might not tick the box for benefits. For example, a delay in the schedule may push back realisation of the benefits to a point that undermines the business case. Additional resources pushing the price up will eat into benefits. Perhaps the project no longer represents value for money.

Carry out these checks at key governance points and gate reviews. Highlight where there are issues to resolve, and come up with a plan if you can. Then discuss that with key stakeholders, the client and sponsor, and see if you can resolve any business case challenges without having an impact on viability of the project. Ultimately, if the business case is no longer viable, the decision is around cancelling the project – and that’s a tough conversation for everyone.

However, if the business case no longer stacks up, cancelling could be the best thing to do.

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.