Data storytelling for project managers: Turning numbers into action

Medium 1024X768 Gettyimages 1614147302 (1)

In my day job, I manage consumer complaints data across five European manufacturing sites, which means I spend much of my time turning numbers into dashboards. Not long ago, I presented one to a room full of quality and operations managers. It was thorough; months of trend data, every category color-coded and figures from every site. Yet buried in all that detail was the number that concerned me most: a slow but steady rise in packaging complaints at one location. However, nobody asked about it. The meeting ended with a polite nod and no decisions made.

A few weeks later, that same trend was no longer a line on a chart; it was a difficult conversation with a retailer. My data had been right the whole time but had simply never been heard. That is when it clicked for me that being correct and being heard are two different skills. And a number, however well analysed, cannot speak for itself.

What fixed it for me was a small discipline I picked up after that retailer conversation: before any update leaves my laptop, I check that it answers these three questions, in this order.

What is happening?

Why does it matter?

What decision am I asking for?

For years, I had been presenting in reverse; showing the data first, hinting at the implications and hoping the room would work out what to do with it. The first time I flipped the order, the dashboard still appeared, but it arrived as evidence supporting a case rather than a puzzle I was quietly asking everyone to solve.

Over time, this has settled into a process that takes me about ten minutes before any meeting. I start by identifying what is happening, pulling only the data that proves the point and moving everything else into an appendix because nobody ever spots the risk sitting in row seventeen. I learned that the hard way. Then I define why it matters, translating whatever the numbers say into time, cost, quality or risk, since sponsors and stakeholders act on consequences rather than metrics. Finally, I identify the decision I am asking for because, if there is no decision to be made, the update is probably an email rather than a meeting.

From there, I build a narrative headline; one sentence that states the situation and its consequence, and I open with that rather than the dataset. I always close with a clear recommendation, specifying the choice I would take and why, followed by an invitation to challenge. A recommendation provides the audience with something to react to. A shrug allows it to move on.

A few smaller habits have made this stick. I build one point per chart now, mostly because I used to cram twelve metrics onto a slide and wonder why nobody could find the story. I show the trend rather than the snapshot, and I translate numbers into consequence wherever I can, because a consequence demands a response in a way a figure on its own never does. None of it means dressing up the facts. I鈥檓 simply arranging them the way people naturally take information in: the situation, why it affects you and what I need from you.

The second time I raised that packaging trend, I opened by outlining what it would cost us if the retailer noticed before we acted, and the room agreed on a plan within minutes. My data had not changed, but it finally had somewhere to land.

For me, data storytelling has come down to empathy. It is less about charts and more about the person across the table and what they need to hear before they can act. Influence has always been part of a project manager's job, even if it never appears on the RACI (responsible, accountable, consulted and informed) chart.

Here is the one thing I would pass on; before your next update, write down the sentence you want someone to say as they leave the room, then work backwards until your data supports it. My packaging trend went unheard for weeks because I led with the dashboard instead of the decision. Your riskiest number deserves better than row seventeen.

Partly AI supported; human-validated