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!

I’ve just finished reading Business Resilience by David Roberts etc al. It’s a book that sets out a whole framework for delivering progress at a sustained pace and not being left behind in VUCA times. It’s aimed at senior leadership at the top levels as that is where the culture change is likely to need to start from, if you are rethinking strategy delivery.

It did get me thinking about what it means for projects and project managers. Thinking about what resilience meant in an IT world, back in the days when I worked in the IT team, I could draw a few parallels with resilience from a tech perspective and what it translates to for project professionals. (These are my thoughts, they aren’t from the book, which is far more strategic and articulate!)

Process

Process resilience to me means having steps in place to get things done, even when things change. For example, when I moved from a fixed term to a permanent contract, my records were updated. Unfortunately, that meant that I could no longer see any purchase orders that were approved by the ‘old’ me.

That wasn’t a huge problem but as process steps go, it would have been nice to have the continuity without having to ask for it.

Another example of building in process resilience is making sure workflows can be delegated when you are out of the business. For example, handing over order approvals, estimates or change management approvals to a colleague during your holidays, instead of them all being stuck in your queue to approve when you get back.

Redundancy

In IT, we used to build solutions that had adequate redundancy. For example, the servers would fail over to another server if the first server had problems. We had back up generators to keep critical systems operational if (when) the power went down.

In project terms, that would look like having two people trained to carry out a project role so that if one resource is off sick, someone else can step in and do the work.

That’s quite an overhead for a project team, as normally we wouldn’t want to carry additional cost, but on business critical projects, or where your resource is truly specialised, it might be worth it.

Data availability

How long do you spend looking for project documentation? Probably quite a long time, especially if its on a collaboration tool that shall remain nameless! Thank goodness for being able to search.

In a technical environment, we’d create backups so the data was available even if the main system went down (although of course with the redundancy, the goal is that the main system stays up…).

Project documentation and data availability in a resilient team would mean you could find what you are looking for easily, in the right place, and access the data.

I think as the world gets more complex, projects get busier and teams have more to handle, being resilient is more and more important if we want to get things done and avoid burnout. These are just 3 ideas of things you can do with your project team this week to be a little bit more resilient and prepared for what next week might throw at you:

1. Review your processes and look for where you can build resilience in to keep things moving and avoid the process stalling
2. Look at your resource plans and consider how you can build in resource redundancy – maybe get a few more people on a training course
3. Consider where you store your project data and how easy it is for people to access when they need it.

What do you think of these ideas? Share any other resilience-building tips you have in the comments below!