The Money Files

We’re all familiar with the standard ways of measuring progress and project success. You might use earned value, or burndown charts or even percent complete.

There are other metrics we can build into our project management practice, and over the last few weeks I’ve been exploring them. One of the questions I got asked in response to my first article on alternative metrics was what challenges might arise from implementation and how could we, as project managers, overcome those?

Let me share some ideas.

Change adoption

The hardest thing with implementing any new way of working is resistance to change. You want me to track something else, in a different way, making more work for me? No thanks.

So when you want to introduce a new metric, like customer satisfaction tracking for internal customers, the goal is to make it as easy as possible.

Try to reduce the barriers to implementing the change, using all the good change management practice you are familiar with, like training and communication and helping people understand the reason for tracking in new ways. Find champions. Remove the old ways of doing things. Give people the tools they need.

Start small

As with all changes, it helps if you have someone leading the charge, and that is likely to be you. Let’s say you want to implement customer satisfaction measures, following the outline of the process in my book, Customer-Centric Project Management. There’s no obligation to start with your biggest program, or even to do it on more than one project.

Use your own project and just do it. Start by asking the sponsor what they value the most from project delivery or what they find important in the process, and then track how satisfied they are with that measure once a month. For example, when I did this, communication was one of the things stakeholders said was important, so each month we tracked how good we were at project communication by asking them to rate us on a scale of 1-10.

Ultimately, we did get the whole department of project managers tracking internal customer satisfaction in this way, but we did start with one project.

Be consistent

Another challenge with changing any way of working is being consistent. One of the things we’ve found with tracking measures monthly is that often (too often, really), we’ve found a flaw in the original assumptions, or some business process changes, or some other thing happens and we realise that the way we are tracking needs to change. Getting more data, more understanding and more accuracy is not a bad thing, but it does rather invalidate your earlier measures if they are now not comparable to your ‘today’ measures.

The way around this is to be consistent, both with tracking in general (in other words, do it regularly and don’t give up on it) and in how the measures are calculated.

Perhaps learn from our situation and give yourself three to six months where you allow for the measurement assumptions and tracking approach to be tested. Make tweaks as you go so you know that after that period you can ‘fix’ the way you are tracking so going forward your numbers are comparable and stable.

Consistency also means following through and completing the tracking regularly, whatever frequency you set, and that might be different for different metrics.

For example, we track some things monthly, but other metrics are only looked at quarterly because that’s how it makes sense.

Build the obligation to report into people’s job descriptions and roles. Set up a mechanism to hold them accountable if they are not completing the tracking. For example, the PMO could ask for all metrics to be added to a central spreadsheet so all portfolio tracking is in one place. Then you could easily see which projects had completed their tracking and which had not.

There are always challenges with doing things differently, but if you really want to make the change, you can. The good news is that often you don’t need PMO or portfolio office support, or even the consent of your line manager. If your sponsor is happy that you track, and you’ve got the energy and enthusiasm to do it, you can.
I recommend starting with customer satisfaction as it’s easy to do with no specific tools required, and it has a huge impact on stakeholder engagement: it’s very much worth it!

Every stakeholder on your project is going to come to the work with a different level of engagement. That level of engagement is going to depend on lots of things, like:

• How busy they are
• What other projects they are working on and the priorities of those projects
• Their level of understanding for the project’s goals and objectives
• What is expected of them (and whether they perceive those tasks to be easy, hard, pointless or worth their time).

Often stakeholders don’t exhibit the levels of engagement that we might feel we need from them to get the best results for the project. Here are some thoughts and simple ideas for how to move people into a place where they are prepared to engage a bit more with the project.

Blocker to indifferent

Projects struggle when the wrong stakeholders are blocking the change. In fact, when any stakeholder is resistant to change, that can cause problems.

Blockers are possibly people who don’t see the problem that the project is trying to fix. They might be keen to defend the status quo, whatever that is.

Talk to them about why they appear to be resistant, or what they are worried might happen as part of this project. Try to share the reasons for the project and the ‘why’ behind the change, even if it doesn’t directly affect their team. They might be more open to engaging with the project if they know the reasons driving the change.

There are various things to try here, but it starts with trying to understand their position and probably ends with escalating to their line manager or your project sponsor.

Indifferent to keen

These are stakeholders who are a bit ‘meh’ about the project and you’d like them to be supportive.

Indifferent stakeholders may think the project isn’t relevant to them. Perhaps they don’t see the point of it. The project just doesn’t seem important. You can see this in their reaction to the work, their slow response in getting back to your messages and calls, and their general attitude to the project.

There is also a chance that you’ve asked them to be involved and haven’t been clear enough with the ask. Talk to them about their priorities and those of their team. Share the successes and if necessary, try to get some of their time ringfenced to complete their project work.

Keen to champion

Supportive stakeholders are keen about the project, but they wouldn’t necessarily be a champion – those super proactive stakeholders who really understand and make progress on the work. Some of your stakeholders probably need to be in the ‘champion’ category.

Think about how you best use their time so they don’t sit in meetings and hear updates that they already know about. Ask for some small commitments and see how they get on completing those before you ask for larger tasks.

Not everyone needs to be a champion

You don’t need everyone to be a champion. Some stakeholders are probably OK to simply be indifferent: as long as they aren’t resisting the change that could be good enough.

The idea of looking at stakeholders in this way and seeing where they are on a scale is to understand better about the kinds of engagement – and specifically the time commitment – required for each stakeholder or group. Those that have the furthest to go on the scale are going to need more time and more focused action to move them into the zone where you want them to be.

Does anyone have an example of a stakeholder who has moved into the ‘more engaged’ category that they’d be prepared to share in the comments? I’d love to hear your stories of successful stakeholder engagement 😊

In December I looked at how to reduce your project’s carbon footprint and provided a few ideas you could take into consideration when you’re working on a project.

One of the questions I got asked on that article was how have I seen these sustainability practices implemented effectively in projects?

Sustainability practices are easier to implement if there is corporate-wide mandated practices and the expectation that you will manage your project and create products in a sustainable way, but let me share a little of my experience.

Carbon savings

When working out project benefits, include carbon saving as one of the metrics you will track, as long as your project does something that will reduce carbon. This could be by digitalizing a process so less paper is used, removing paper cups from coffee machines and replacing them with a ‘bring your own reusable cup’ policy in your project office or something else.

I’m aware that digital solutions also have a carbon footprint in that they use energy and land as there are vast data centres behind the scenes of every virtual meeting, so you’ll have to draw your own conclusions about whether the savings you are claiming are ‘real’ or not.

Many companies are now very much focused on energy saving and the equivalent carbon saving this equates to, so someone in your organization is likely to be able to tell you what measures are used in the business to track and report on carbon usage. Talk to your energy manager or the sustainability team if you have one, or someone in Finance who could help you work out what, if any, carbon savings you can reasonably track.

Ideally, the project’s deliverables would have a benefit that demonstrates carbon reduction, but if not, you could look to track carbon usage related to managing the project itself, for example, you could track number of journeys that did not happen because you chose to meet virtually instead.

Paper usage and waste recycling

A very small thing you can do on your project is to make sure that the team does not use excessive paper. Stop printing project board decks and meeting agendas. Make these available on digital solutions instead.

Use digital thank you cards instead of real ones (although you’ll have to weigh up the value in a digital one – some how for me, a physical card feels like it means more).

Travel

I mentioned avoiding meetings where the journey would create a carbon emission – see how much travel it is possible to cut out of your project. There’s probably some.

Supply chain

Even if your project is not buying anything in terms of goods, there are probably some items that you end up procuring, for example, lunches for workshops. Choose local suppliers using locally-sourced products.

Ask questions of your suppliers and see if there are choices to be made.

Document your decisions

The easiest way to make sure that you are living your goals and managing to make a carbon impact is to ensure your project management plan and documentation includes the commitment. Put your metrics in your benefits tracker. Put targets in the quality plan.

Make sure your schedule includes any specific actions you are going to do as a team. What other suggestions do you have for reducing your carbon footprint as a project team? Let us know in the comments section below!

Last month I looked at a range of alternative metrics for assessing success. One of the comments on that article asked how, on reflection, had I seen these or other alternative metrics implemented effectively. It also asked whether there were challenges that might arise integrating alternative metrics into existing project management frameworks (which I’ll look at in a different article).

So, if you want to implement a more nuanced approach to measuring project success, how do you put this into practice? Below are some ideas. This topic is one that we could probably speak (or write) about at length, but hopefully the examples and ideas I share will give you some starting points for incorporating a range of measures into your project management practice.

1. Customer satisfaction

This is an area where I have quite a lot of examples to share. In my book, Customer-Centric Project Management, my co-author and I describe an extensive exercise to set up customer satisfaction tracking on projects, with internal customers.

I’ve written about customer satisfaction measurement on this blog before (start with this article: Lessons about project metrics). Basically, find out what is important to people, then track that regularly and plot your scores as part of regular reviews.

You don’t have to use an ‘official’ CSAT mechanism, or pay for electronic survey tools. Just ask people as a minimum.

2. Innovation level

I haven’t used an innovation score regularly throughout a project, but it has been included in the way we rate projects and prioritize which ones should be done as the requests come into the pipeline.

Implement an innovation score yourself on a simple Likert scale (1-5 or similar). Ideally, you don’t want the measure to be subjective, so set some criteria e.g.:

• Number of tools used where the business has less than 1 year of experience using them
• Years of experience of team implementing (as someone could have gained a lot of relevant experience in a different role)
• Contractor level of experience rated on a scale of how many implementations they have done.

Or similar – you really only need a couple of measures to make up your innovation score. Use the innovation score as part of the decision criteria for whether a project should be taken forward or not.

3. Resource utilization

Resource utilization reports are something I’ve only actively used on a couple of projects, because mostly we either haven’t had the tools to extract the data (because we aren’t doing timesheets or detailed estimates), or because staff have been 100% assigned to the project so we don’t have to worry about them splitting their time across projects. We would still have to worry about them being scheduled to do too many tasks in a week and being over booked, or under utilized, but when the team is full time somehow that’s easier to manage as you can see what they are doing and we speak every day.

Use the reports to check exactly that: is the team going to struggle to meet its commitments? And if it is, because staff are over-scheduled, what are you going to do about it?

Even the basic reports from Microsoft Project will give you utilization data, so take a look at what you already have within your tool suite and if you find it useful, use it.

4. Risk mitigation effectiveness

The final one I’m going to talk about today is tracking risk mitigation effectiveness. I mentioned in the article that you could use AI-powered insights to establish the effectiveness of the risk management activities undertaken, but in reality I imagine that takes quite a lot of effort to set up.

Another way to do this would be at project closure, or during lessons learned conversations, whenever these take place in your project lifecycle.

Look at what the risk was and what was done to mitigate it. Score the risk based on the effectiveness of the action:

• 1: Risk management activity was 100% successful and risk was closed
• 2: Risk management activity was successful but residual risk was worth £x
• 3: and so on.

Using residual risk (and specifically, a financial value of residual risk) is a way to establish how effective your management action was – or at least, it’s one way to create data that allows you to assess that.

Hopefully that gives you some pointers for measuring project success through different routes, with some more concrete examples of how to get started.

I’m working with organisations who are putting a lot of thought into benefit management at the moment – more thought than I’ve ever seen in past years. I know benefits management has always been something to consider on projects, but how many project/leaders/organisations actually truly do it?

I’m sure the larger projects are geared up for benefits tracking, but smaller initiatives? Those that might only deliver a few thousand pounds/dollars of benefit per year? Are those being tracked?

I think the trend is changing, and I think there is more focus on benefits tracking, particularly in programmes. Where there is a large programme of work, even small projects get to contribute.

So how do you do it?

The first step is to work out what benefits your project is going to deliver. For example, that could be:

• Cost saving
• Increased sales/revenue

In fact, benefits could be lots of things (shorter cycle times, more calls answered, higher customer satisfaction) but most often they can be reduced to money. Shorter cycle times should mean more projects delivered in a year, so more value achieved, or more widgets through the process, so more sales. More calls answered should convert to more sales, so more cash. Higher customer satisfaction results in more repeat purchases and more testimonials that drive new buyers, so more cash.

Even carbon savings and sustainability targets can often be represented as financial benefits. Carbon has a financial figure associated with it, so you can translate carbon reduction into money.

The trouble comes with trying to get stakeholders to agree on how these benefits will be calculated.

More calls in, for example, might not translate to more sales for several months, depending on your business timeframes and processes. You will need some rules and assumptions around how benefit numbers are going to be worked out where the maths is not straightforward.

For example: if we outsource a service, we can reduce headcount in function and probably make a saving on the cost to serve (budgets are part of the outsourcing decision, after all). That’s a straightforward cash saving: those individuals are no longer on our payroll (even if they were moved across to the outsourced party – the UK has TUPE rules for this).

But do we count that saving as a ‘pure’ saving, or do we have to take off the cost of buying the outsourced service? How long can we claim the service for before it becomes BAU? What happens when we need to add a head or two back in, where do those costs go?

We need assumptions to make benefit calculations work, like what’s the average cost of a sale (so if we answer more calls we should convert x% and make y% extra money as a result).

This first step of creating a model on which to base benefit calculations is the hardest part, in my opinion. There are experts to consult, finances teams to engage, data to gather so we have something to use as the baseline, and lots of maths and spreadsheets to test out so we can model what the benefits might look like.

Getting agreement on how the benefits will be worked out is hard. You need everyone to agree, and more importantly, to understand how it all goes together so they can repeatedly work out the benefit using the same calculation, month after month for as long as you decided to track it for.

That’s no small undertaking, especially for organisations starting out. Especially as many projects have multiple strands and multiple things contribute to the benefits.

What’s the journey like for benefits tracking in your organisation? Let us know in the comments what the biggest challenge is for you – I’m interested to see if you agree with me that it’s the setting up and creating the assumptions and rules for calculation, or whether there is something else that is the hard part.