From Data Management to Data Analysis and Visualization: The Project Management Viewpoint

Article excerpt

BACK when I was a young pup in the business of computers, the terms "data management" and "the IT guy" (no offense to IT women, but it's pretty likely they were called IT guys as well) were sufficiently well-defined to cover most everything to do with computers, at least from a project manager's point of view. Projects generated data and the IT guy managed that data. Throughout the 1990s, as the industry and the tools matured, the language evolved as well. Terms such as "data warehouse" and "data mining" described more specific products, and the database administrator was separated from the network administrator. As we kick off the 21st century, the terminology and technologies continue to evolve. This article provides a project manager's (the topic expert in this article) view of several terms and it provides an understanding of how knowing those terms and their use will improve your projects overall. Data management, analysis, and visualization are three peas in a pod.

A little personal history will help this tale. For many years, my job involved managing large data sets of chemical analyses. Around 1990, I started fiddling with geographic information systems, (GIS). These programs provided the IT guy with the tools to create "smart maps," maps that knew a circle represented a sampling point, a rectangle represented a building, and a long curvy line represented a road. The process of "mapifying" those data sets really opened my eyes to the three separate processes that are involved in the data trail and to the fact that the responsibility for, the measures of, and the expertise required for success in each process are unique. As a project manager, understanding how each process impacts the others, and more importantly, how each process judges its success, will definitely help you gather the appropriate team and be able to more effectively communicate your needs.

ISN'T DATA JUST DATA?

When databases were first developed, it was pretty cool just to be able to manage and manipulate that much information. The IT guys could really make those numbers jump. Unfortunately (and too often), the topic expert was not able to effectively communicate to the IT guys a description of what outputs from the database would be most useful. Just as frequently, the IT guys were frustrated, because although their ability to manage such massive amounts data was phenomenal, they remained unable to impress the topic experts. Data management considers data to be just data.

If we assume that both the topic experts and the IT guys are extremely smart, then perhaps we should look a bit closer at the data. Claude Shannon did just that in the 1940s and 1950s when he developed Information Theory [www.lucent.com/minds/infotheory]. Interested in understanding how to measure and control radio transmissions, Shannon did not concern himself with the meaning of those transmissions, only how to best move bits and bytes of information around a system. His work, among many others, helped us learn to move the bits and bytes of data around the system just like a train moves merchandise from one location to another. It is now relatively straightforward to calculate the costs of data management. There are also many consultants who will do a great job for you.

As project manager, it is imperative that you understand what constitutes success for the database manager. The measurements used to judge that individual's performance are essential for understanding the overall project, but those measurements have little or nothing to do with measurements regarding data quality. To continue the train analogy, keep in mind that just as the train engineer and the train owners judge themselves not on the quality of the merchandise they carry, but rather on the timeliness and efficiency with which that merchandise is carried, the database manager is judged by standards that measure how much data was correctly moved from point A to point B, not how "good" that data is. …