Implementing standard tools and processes, reviewing / challenging submissions, etc to provide project information and metrics are only part of what is needed to be successful. One of the real skills is being able to take vast amounts of information, distil into key messages and present to the stakeholder.
At this point it is worth pausing to fully understand the challenge in that statement. For large and / or complex programmes there will be many data points. If you followed the recent series on defining metrics, you will recall the importance of defining metrics that truly demonstrate progress.
Now here is the challenge – distilling the metrics into a handful of key measures takes time and involves a journey – the metrics journey. When you are working closely to take data and condense it into key data points, you understand the rationale and what the metric means. You have acquired the knowledge as part of the journey that has taken days, weeks or even months.
So, put yourself in the place of your stakeholders, they have not made that journey, they have not acquired the knowledge. How would you re-act being presented a high level dashboard with filled with an array of numbers, percentages, charts, etc. For common ones like budget and headcount it will probably be easy for them to understand. However, I would imagine that many other metrics would not make sense without being explained and decoded. This data will not mean anything to the stakeholders leaving them confused and, worse still, doubting the value of the metrics and questioning the ability of the team.
This can be addressed by talking the stakeholders through the metrics. Unfortunately, not all will allow the time for you to explain and once you have lost them they are difficult to bring back onside. You may not even be present when the dashboard is being viewed. You can add notes and caveats to the dashboard. Again how can you be sure that they will be read before, or even before, the wrong re-action (plus a dashboard typically does not have the “real estate” – the space available on the page / screen).
To help mitigate this, you need to take the stakeholders on the journey. Do not be too clever by reaching the answer too quickly. As you iterate the design, be sure to share with the stakeholders, talking them through the logic. This serves 2 purposes. Firstly, it allows the stakeholders to take the journey and acquire the knowledge and understanding meaning they understand the background to the data points. Secondly, it is a very important feedback loop, helping to ensure that the direction of the work is aligned to their expectations (avoids the situation of a big reveal being a big flop).
In summary
Taking the time to consider the stakeholders and taking them on the journey can be the difference between success or having unhappy stakeholders requiring a lot of rework. The principle is simple and should be applied to many of the aspects of project and programme management.
