Are You Drowning in Data?

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 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:

• Performance to date vs. 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 planning, good data structure in the first place, and hard work. 

 The alternative, producing data without information, should be terrifying. 

Don’t forget to leave your comments below.

---

Paul Bosakowski has more than 40 years of PM experience in in a variety of projects in the public and private sector. 
His assignments have been on six continents.  He is currently teaching, consulting and writing.   

---