The Money Files

In my early days as a project manager, my business cases and PIDs were full of non-quantifiable benefits. The kind of improvements that I thought we could get but weren’t set up to track.

In my more recent years, I’ve been heavily focused on quantifiable benefits, most specifically the money-related ones. Anything that presents a trackable, cash improvement is something to focus on. If it improves the bottom line, managers want to know about it.

There are also quantifiable benefits that are harder to track like reducing cycle time for invoicing and reducing energy consumption. These would lead to financial savings, but they are more difficult to pin down and measure realistically with no other influencing factors. Cycle time, for example, may lead to bills being paid faster which would lead to better cash flow and increased bank interest, but how do you separate that out as a benefit of just this project and not something to be attributed to one of the many other projects that are doing their bit for continuous process improvement?

Energy consumption can be tracked, but it’s several steps and calculations – it’s doable but harder. That’s not to say we shouldn’t do it, but it is something that you have to put effort into tracking.

Non-quantifiable benefits seem to have dropped out of favour. For example, staff satisfaction survey results is a good one that I used to mention a lot in project documentation. However, there are lots of things that influence staff satisfaction, and I’m sure my projects only played a very small part in influencing the results one way or another.

Also, new initiatives that once seemed completely life changing and a huge improvement quickly become ‘the way things work around here’ and the benefit tails off to nothing. No one would want to go back to the old process, but equally no one is celebrating the new process 6 months later when it’s just normal BAU.

I learned this on a Six Sigma course I took many years ago where the instructor talked about giving customers a biscuit with their coffee in a coffee shop. At first customers were excited they were getting a biscuit for free, but over time they came to expect that service and were disappointed when they didn’t get it, but not more happy because they did.

Therefore there is a balance to be struck with benefits: you want a mix of both quantifiable (financial and other) and non-quantifiable. But not so many that they all become meaningless. And not so few because you can’t be bothered to put the tracking mechanisms in place for more.

Be realistic about what you can achieve with benefits and how much time people really are going to spend on tracking the more difficult ones. If they believe that it’s worth tracking, they’ll do it, but if they feel energy consumption, for example, is tracked adequately through other types of environmental reporting or projects, they probably won’t be falling over themselves to create project-specific benefits reporting.

Talk to the key stakeholders about what sort of benefits you are putting forward for a project and make sure they are reasonable, measurable (where possible) and realistic.

Who do you consult when a project gets going? Or when you want to put forward an idea for a new project but need to run it past some key stakeholders?

One issue I had on a project recently was that we didn’t involve our IT subject matter expert early enough. While that didn’t slow down the project, it did mean we’d made extra work for them, which isn’t kind, and I’m sure they felt like an afterthought, which is not the relationship I want to have with my stakeholders.

So learning from that, here are some of the key stakeholder groups and subject matter expert teams that you should be talking to at the beginning of a new piece of work.

IT

Let’s put them first! Talk to your technical colleagues to find out if they can advise on the best solution.

Operations

Operations are the group that keep the organisation working, so they run the day to day functions of your business. The teams are going to be different depending on what your business does, but they will know whether your project is going to have an impact on frontline staff and the operators.

Finance

Talk to your finance team to find out whether there are any special requirements for this kind of project. For example, what are the funding options, how will financial benefits be tracked, whether contingency or management reserves are available and whether there will be a finance analyst available to support the work.

They might be able to give you and idea of what budget is available in the portfolio which will help you scale the work.

PMO

Talk to the PMO about resourcing, scheduling and estimating and securing project resource. Generally, in my experience if you are the project manager involved at the start of a discovery or concept phase, then you’ll also be the one that carries on leading the work as it moves forward. But not always, so make sure if you need project support that you’ve got a PM and/or analyst assigned to the work and that they understand what is expected.

Finally, don’t forget to include the senior leadership in your consultation. As a key stakeholder, they’ve got the power to say they don’t want the work to go ahead after all because something has changed. Equally, having their support for projects that are moving is invaluable because they’ll be able to support and champion from the top.

Legal, compliance and data protection

I’ve bundled legal, compliance and data protection into one group but you probably have separate teams responsible for each function. Talk to each of the departments to make sure that your project is viable and meets with all the required regulations and policies.

Communications

If you have an internal comms team, talk to them about the project and what support you can expect from them. For example, they might be able to help with drafting project newsletters and briefings, and creating slides to share at leadership meetings.

HR

If your project affects people’s jobs in any way, consult with your Human Resources team. There might need to be consideration given to job descriptions, recruitment, the onboarding and induction process, training and more. HR-related changes can take some time so it’s worth getting them involved early.

Specialist teams

If your project involves manufacturing, talk to them. If you need engineers, get input from them. If you have a big marketing expectation, bring the marketeers onboard at this point and get their thoughts. Work out what specialist subject matter expert teams are relevant to your work and include them.

What other teams would you include by default? I’m sure there are some I’ve forgotten!

Making a recommendation? Whether you’re doing a formal business case or a quick paper for your boss, here are 5 things that you should make sure are covered.

1. Present the options

What are the options you have considered before making your recommendation? Normally you’ll have at least 3:

• Do nothing (what happens if nothing happens – if your project is legal or regulatory you might not have a do nothing option)
• Do something (minimum intervention)
• Do more than the minimum.

Write a few sentences about each, or if you are doing a verbal presentation, spend a moment outlining each.

The option chosen should be practical and deliverable. In fact, all the options should be reasonable – suggesting pointless activity is a waste of time and undermines your credibility. There’s no point putting forward an option to deliver 100% improved customer service if it needs an investment of £2m and you know there is no way your company is going to go for that.

2. Present the choice

Next, say which one of your reasonable options you are putting forward.

Explain why. Be clear and don’t assume they know anything about any of the analysis or thinking. What’s the obvious choice to you might not be clear to them.

Explain why the other choices are not appropriate to pursue at this time. You don’t want to spend loads of time on explaining why you have discounted them, but you might need to justify the financials so link out to (or have to hand if you are presenting) info that stakeholders can use to look at the detail.

Hopefully they won’t need it as they should trust that you’ve consulted the right people and made a sensible choice.

3. Present the benefits

Review the benefits that come with the chosen option and make sure you can justify them. Are they clear, measurable and reasonable? Are there benefits that look good on paper associated with the rejected options that you should explain? Normally, business leaders go for the ‘biggest benefit’ choice so if you aren’t selecting that one, be sure you have clearly justified why not.

Don’t over-estimate the benefits because of all the sections in this presentation or paper, the benefits are the thing most managers will remember. They’ll be looking to you to deliver those, so I would recommend being on the cautious side!

4. Check the language

The decision might go up the chain to people who don’t know the jargon of your department. Check through your proposal or presentation script and make sure you’ve explained any acronyms or project-related terminology that other people might not understand – or that they might interpret incorrectly.

Get someone else to read it through if you are worried that you’re so in the detail that you won’t be able to pick out terms that someone else can’t understand.

5. Read through your recommendation again

If you were presenting this to a family member or non-project manager friend, would they understand your justification for the choice? It should be clear that you have chosen the obvious winner and that you can explain why that is the most appropriate choice at this time for your business. If there is any doubt, go through and strengthen the language.

Finally, check for spelling and grammar errors, and make sure that people’s names and job titles are spelled correctly. Circulate the paper for comment amongst your subject matter experts if it is something you need to get input on, and then send it off to your boss or whoever needs to see it.

The decision maker might not agree with you, but you can be sure they’ve seen the best possible justification and case for the choice.

Risk avoidance is an approach that you’ll see mentioned as one way to manage project risk. But how can you actually avoid a risk? Oftentimes, the risks are related to what the project is all about and you can’t simply palm them off on to someone else or change the project so that they don’t happen – because that would mean changing the scope of the project and that’s probably not going to be something your sponsor will go for.

In his book, Identifying and Managing Project Risk (4^th edition), Tom Kendrick lays out some realistic options to consider if you want to avoid a risk completely.

Here are some suggestions drawn from his work but with my own interpretation added in.

Avoid new technology

Anything new brings with it an element of risk. Untried technology might be the latest shiny thing, but if you want to avoid risks related to using unique, new, and unproven solutions, it’s better to stick to the tried-and-tested options.

Buy, don’t build

Make or buy decisions are common in tech projects and others. You have to decide if you’re going to buy in a solution or build it in-house. It might feel like the right thing to do is to build it in house, but if someone out there already has a proven solution that works and would work for you, you can reduce the risk if you go with that.

Building involves creating something new (for you) so it adds time and uncertainty and risk.

Do the minimum

Keep your scope small. The larger the scope, or the more additional change requests and new features that find their way into the brief, the more risk you are adding. MVP for the win.

Keep the plan simple

Along the same lines as having a simple product scope, have a simple plan. Avoid multiple strands of work that run in sequence. Avoid dependencies between tasks where you can. Break down tasks into smaller chunks of work and make sure there are enough people to manage them. Schedule ‘fire breaks’ where the team can catch up.

Manage resources

Look at where you can build in more time, or more slack, for example by not having someone due to work on two back-to-back tasks and making sure people are scheduled at a lower level of availability over resource-pressured times like holiday seasons. Even better, ring-fence the resource so they are solely dedicated to your project and aren’t trying to juggle their day job or other project commitments at the same time. Use resource levelling to spot where you might have problems and plan around those.

Make sure there are enough people available with the right skills so you can avoid the bus factor. Give people the tools they need to get their work done so they aren’t slowed down by not having access to the right kit or software and automate what you can so they don’t have to do those tasks at all.

If you want to avoid risks completely, you will have to think about how you plan and resource the work. Review how you prioritise requirements or look at the schedule. Think about how work can be rearranged between people or across the timeline to reduce the risk to nothing.

It might not be possible – in fact, I’d bet it isn’t possible – to avoid every risk, because that’s the nature of projects. But there could be some specific schedule, resource or scope risks that you could remove from your log because of the choices you and the team make.

What else would you add to this list? Let me know in the comments!

Last time I looked at some tips for making lessons learned sessions run a bit more smoothly, and it made me think about some of the pitfalls we see when facilitating those sessions. My own experience is with using the model associated with predictive projects, but I imagine you could get stuck with these pitfalls if you were doing retrospectives with an agile team as well.

Image credit: ChatGPT

Here are some things to look out for once your lessons learned conversation is in the diary.

Focusing on only the negative things. Don’t let the session focus only on the negative. Yes, people like to have the opportunity to share the things that didn’t go well. If it helps the atmosphere to have a moan about the elephant in the room, then do so. But make sure there’s some time on the agenda left to discuss the working practices that were successful, otherwise you’ll all leave the meeting feeling like nothing went well, and I’m sure that wasn’t the case.

Making the sessions too long or too short. Who wants to give up an afternoon for a workshop? No one. And yet if your session is too short, you won’t have time to properly address any issues, come up with action plans or go through the agenda. The exact length of time is going to depend on what you’re wanting to cover and how much prep the team have done beforehand. Question why you need longer than an hour.

The same topics coming up regularly because they haven’t been handled. Regular lessons learned are part of the process, but too frequent and you won’t have had a chance to fix anything – and the same problems will come up again.

Listening to people say they suffered the same challenges because nothing has changed is annoying and frustrating and leaves people wondering what the point is of raising anything if nothing will be done.

People not feeling safe to speak up. Psychological safety is important if you want to get to the truth, but if no one is prepared to share what they thought didn’t go well, you won’t be able to improve. This is a hard one to address if the organisational culture is conspiring against you, but have a think about how you may be able to overcome it if it’s a risk for you. Having smaller sessions with targeted conversations, or anonymous surveys might be options.

Not doing anything with the output. Yep, this is all about leaving your lessons documented in a folder gathering electronic dust somewhere. Not good. Make sure they are turned into actions and have people responsible for doing something with them. At the very least, share them with the other project managers in your group.

Not being able to determine actions properly as you don’t have the detail to hand. So you’ve recognised you need to do something to change a process? If you don’t have the As Is process to hand, it might be hard to work out the action required to make the improvement. And that basically means the improvement won’t get done as what are the chances of someone doing the mapping and analysis afterwards? Unless the leadership team puts a lot of emphasis on follow up, you might miss that out.

These are some of the pitfalls of holding reflection sessions, but by all means I’m sure this list is not definitive. What are the other challenges you’ve found in your own meetings? Let me know in the comments!