Metrics are an important way to learn about how the project is going and to reflect on what has happened in the past so you can do things different in the future. Or repeat the things that work well.
I learned a few lessons about project metrics when I worked on an ERP implementation a while ago now. We measured internal customer satisfaction from the angle of the stakeholders’ experience of being on the project. We used standard questions and asked them to rank our performance on a scale of 1 to 10. (I write about all of this in Customer-Centric Project Management, which I co-wrote with a colleague.)
In my experience, workstream leads scored reasonably based on the context: no one ‘played politics’ to get what they wanted. But there was always room for improvement based on our scores. We had plenty of armchair debates in the lobbies of hotels while working on the road, talking over the scores and why they were ranking project performance the way they did. They weren’t my favourite conversations, but they were extremely useful in building great stakeholder relationships and goodwill over time.
The big lesson for me came when I was asking my own colleagues in the IT department to rank the project and they scored it badly. I took it personally as the project lead as you can imagine! But it was a huge wake up call for not taking my colleagues and friends for granted: I was pouring all my stakeholder engagement effort into people outside of my own team.
Luckily it was easy to fix. I set up conference calls for team Q&A and made time for regular communications. If you listen to what people want and give it to them, you can make a quick difference to perceptions and how easy it is for them to do their jobs.
The takeaways for me, specifically around metrics were these.
Identify stakeholders in the process
Put some time into identifying stakeholders and don’t miss the obvious ones like I did!
Ensure the measures are representative of all stakeholders
If your measures are not objective and are not representative of all stakeholder, consider having different versions of the measures for different things. That’s OK as long as there is some longevity baked in for comparison purposes.
Decide on how to record results
In my case, it was better to keep individual stakeholder results separate instead of creating an aggregate of stakeholder satisfaction scores. That gave us greater insights into how each workstream was feeling. An average would be unrepresentative of the community overall.
Sense check
Are the metrics telling you what your instincts are telling you? If not, why?
As project leaders, it’s important that we set up metrics to measure what matters (I’m sure you’ve heard that before). We need to know who matters and their experience influences the overall metrics on something like satisfaction or the interpretation of project value.
Metrics are only useful if they include or are representative of all stakeholders, and all interested parties, even if you then split those groups out further.
