It’s time to turn progress-reporting from a burden into a driver for your team

The problem

If you are a project manager or a higher-ranking executive, you want to create value. You want to grow your business and ideally finally leapfrog the competition.

However, there are the stakeholders to your project or initiative. They want to see progress reporting. They do not specify what they mean with “progress reporting” but they demand it every month.

That report, however, is some sort of a challenge. How shall we report progress? Estimated time left? How much time did we consume? How much we achieved already? How many tasks did we tick off? But what if the tasks have different efforts attached to them?

Doing that makes you feel annoyed and at the same time, you might feel a bit helpless. You need to create this report, on the one hand, on the other hand, you most likely know that the numbers on paper do not reflect the effort you put into it. The more time you spend on the reporting itself, the more demotivated you become, while you originally wanted to focus on creating more value.

I have been there too!

Sounds familiar? I can relate to that. I have been there too. Which project manager hasn’t? We all faced the situation at least once, where we told our teams: “Don’t worry, I will take care of the reporting and figure something out”, and then sat back for hours making up some progress report in an unbelievably complicated format. That, however, got the teams disconnected completely. If we do that, our teams become completely detached from the progress we potentially communicate.

I have worked in numerous project and program management roles myself over the past years. I have worked with numerous C-Level executives but also with hands-on engineers and developers. Drawing from this experience, I compiled for you the three main actions, which made reporting work for me. Utilizing them I was not only able to provide meaningful reporting but also to utilize the reporting as a motivator for the team.

Plan for action

The three steps to create meaningful reporting:

1. Identify the value your project tries to realize

2. Break down the value realization into incremental steps

3. Decide on a meaningful reporting cadence

Let’s take a few minutes, to break them down in a bit more detail.

1. Identify the value your project tries to realize

You need to be aware of the problem your project is trying to address. Often, the problem is not communicated as initiators and sponsors themselves are not even sure about what exactly they want to see resolved.

E.g. I remember coming across a project which was implementing a digital onboarding process for customers. That is a cool thing, but why are we doing it? Just because our competitor does it that way? That is a bad reason as the only value we would add is to catch up with our competitors. You do not leapfrog the competition by playing copycat. The real reason for implementing a digital onboarding journey might be, to increase the satisfaction of new customers straight from the beginning. Or, in general, attract more customers. If that is the case, let’s be specific. How many customers do we want to attract? Daily? In what timeframe? That is the real value your project tries to realize, hence, that is what you should measure.

2. Break down the value realization in incremental steps

Now that we know that our real value is attracting new customers e.g. we most likely will have to adjust our project approach. If we implement the digital onboarding procedure over the next six months and then release it to our customers, we will not be able to report any progress over the next six months. Customers will be forced to use the old process. But, what if we at least allow them to sign-up and send sales agents to their doors? Then, we might be able to attract new customers already before the full digital onboarding procedure is rolled out. How cool would that be?

3. Decide on a meaningful reporting cadence

As we identified our problem, broke it down and adjusted our project approach, it is time to discuss: how often should we report? To be honest, that is not an easy question as it will highly depend on your circumstances. If you can release your results to customers daily, you could measure improvements straight away and report every week. Often enough, however, that will not be the case. Hence, choose something meaningful and discuss it with the report recipients. If you can release every two weeks into production and measure the results? Maybe report on a monthly basis. If you can only release once a month? Report every two months. If you can only release once into production every quarter/ half a year? I would suggest working with the management on a more frequent release schedule as that might be a challenge worth addressing. Whatever reporting rhythm you choose, you need to communicate it to all stakeholders.

The result

If you follow the above three steps, you will not only be able to provide real progress reporting to your stakeholders. You will also be able to measure if your project is making a difference or not. In addition to that, your team will become more interesting into the reporting itself and subsequently more driven. They will most likely watch the measurements, if possible, daily and become more and more excited the closer you get to your goal.

You will prevent situations, where stakeholders got bored reading status reports. You will also prevent reporting some artificial percentage progress figures, which do not reflect the real progress at all and you will prevent your team from getting completely detached.

Last but not least

Some of you might be in the situation, where you cannot adjust your project approach anymore. Or, where you are working on a major transformational project such as a core banking system replacement or an SAP transformation. If you are in this situation, measuring customer impact and direct value realization might not be that easy.

In that case, please do not fall back again on artificial measures such as % of tasks completed but choose instead a measurement which is useful at this time for you and your team. Examples might be % of buffer consumption such as described in the reliable scrum framework (www.reliable-scrum.de) or the number of fields mapped to the new system or the number of test cases executed vs. the number of passed/failed ones.

Do not fall into the trap of simplifying the reporting in that case. Rather report content which is relevant and explicitly mention when you might need management support. Often we tend to oversimplify our reporting and are hesitant to ask for help while the stakeholders are keen to see exactly that. They want to feel part of the project and see you succeed.

Most of the above principles are derived from the OKR (Objectives and Key-Results) framework that Google applied for a long time. If you want to read more about it, I suggest picking up measure what matters.