Out of desperation and frustrated by not being able to communicate a basic principle to my peers, I wrote a paper that was eventually presented at the 1993 PMI Symposium entitled: “Data and Information…Is There a Difference?” Now, nearly two decades later, I am starting to believe that I could make a living helping this generation’s Executives—those in a Governance role—and Project Managers distinguish the same difference.
A lot has changed in nearly twenty years. The personal computer has become the PM’s best friend and seeming body appendage. The Internet has revolutionized the way we live and has caused incredible adaptations in everyday life. The rate at which data are being generated boggles the mind.
And in that proliferation of data lays the exact same problem as it did two decades past: we in the PM community are drowning in data and thirsting for information.
To avoid frustrating the reader, I need to distinguish the difference between data and information with a simple analogy. Think of the difference between data and information in the same way you would think of a barrel of crude oil and a gallon of gasoline. The crude oil needs to be processed and distilled—refined—to produce the gasoline. In the same way, data needs to be refined and condensed to produce information.
Today’s PM finds an abundance of data bases that contain spread sheets, schedules and accounting reports with data accurate to the second decimal place. Terabytes of data inundate the PM and potentially render the PM unable to draw a conclusion regarding the overall health of the project.
Why? Because an important planning step did not occur when the project began. No one took the time to ask and answer these questions:
What is the definition of success for this project and do the team members understand it?
What information does the project team need in order to be successful and to achieve project success together?
What information needs to be communicated to those to whom we report and at what frequency?
How can the information be delivered most efficiently?
Answering the first question provides focus and helps to prevent scope creep. What should this project “look like” when finished? Every team member will need periodic feedback to sustain performance or to correct it. And those to whom we report don’t have time to parse through reams of data in order to draw conclusions or to make other decisions.
Status reports? Forget it. Status is history. Status chronicles where the project has been, not where it is going or when it will get there. Status is analogous to driving a car while looking only in the rear view mirror.
So now what? Present a dilemma without an offer of a solution? No.
Every project should deliver four elements of information, at different levels of detail, to both internal (Governance and project team) and external customers:
Performance to date the budget and the schedule, along with a forecast to completion, presented pictorially
Reason(s) for variances from budget and schedule along with recovery plans (if necessary)
Listing of customer-directed change and its impact(s) on the execution plan
Listing of downstream risk(s) and accompanying mitigation plan(s)
Sounds easy, right? Not so. Distilling information from data requires report planning (contents, frequency and distribution matrix), good data structure in the first place, and hard work.
The alternative, producing data without information, should be terrifying.