Jeff Bladt and Bob Filbin wrote a concise post at HBR.org about the way they go about applying big data in their business. Their idea:
A Data Scientist's Real Job: StorytellingData is dull; information may be interesting; but stories can be captivating.
It's sales 101: there's the messenger and there's the message. The combination, well made, is what gets the point across.
Authors Bladt and Filbin are talking about how to analyze and present information from a data warehouse or other large repository of data.
They've devised a process in three steps:
- Look only for data that affect your organization's key metrics
This seems obvious on the face of it, but confusion, ambiguity, and incoherence affect all too many data analyses. Look to the business scorecard and/or the project scorecard for the key metrics (a.k.a. Key Performance Indicators, KPI) that really count - Present data so that everyone can grasp the insights
As the authors say: "...never show a regression analysis or a plot from R. In fact, our final presentation had very few numbers - Return to the data with new questions"
This step is continuous improvement -- CI -- applied to storytelling, using feedback from the audience to refine the story and find new chapters
From the project management perspective, these data stories may well come around as requirements. The agilists will handle them as 'user stories' and use cases -- maintaining the conversational character. The traditionalists will structure them into 'shalls' and 'wills'.
Here's my take:
The popular vernacular is 'narrative'. So in the context of data, what's a narrative? Simply said, it's discreet facts -- call them 'data dots' -- sequenced, related, and linked in such a way that a theme emerges and a story -- a narrative -- is evident: a beginning, middle, and ending. In other words, the dots are connected.
Usually, there's a self-evident purpose for constructing a specific story from the data dots, though it's likely that more than one narrative is possible. Just put the dots back in the pot, draw them out again, and connect them differently: same facts, different story!
In any event, the good news for the project is that there is a data source to go back to; the bad news is it's not stationary, subject to updates from business operations.
But data changes...
The project might want to think about capturing a data image and putting it away as a 'static' version. This image capture can be the baseline for requirements. And, even though static, if accessible by an project analysis engine, the project can continue to probe for derived requirements
Check out these books I've written in the library at Square Peg Consulting
