Not the best way to understand your underground assets…

In the previous post, we discussed some of the physical reasons that might lead to incomplete data in your pipeline GIS database. In summary, these include:

• Data capture was from data sources with insufficient level of detail (e.g. as-built alignment sheets).

• Data was not captured in the first place, so no record exists.

• Changes since original construction were not captured (or loaded).

• Changes since the implementation of the GIS were not captured (or loaded).

These are all proximate causes for incomplete data; they do not reflect root causes. That’s what we’ll discuss here. In the previous post, we danced around the term, “Data Governance,” but did not actually define it. So:

Data Governance is the marriage of traditional IT data management methods and technologies with modern business process management methodologies.

More specifically, Eagle views Data Governance as the application of Six Sigma (defect reduction) and Lean (process efficiency improvement) manufacturing methods to data management in general, and GIS data management in particular. The combination of these is referred to as Lean Six Sigma.

If we think of data as a manufactured product, then it’s clear that data errors (including omissions) stem from deficiencies in the manufacturing processes that produce it. The foundational concept behind Six Sigma is that processes must be quantitatively described and measured as a prerequisite to improvement. To paraphrase Dr. Mikel J. Harry:

• We don’t know what we don’t know.

• If we can’t express what we do know numerically, we don’t really know much about it.

• If we don’t know much about it, we can’t control it.

• If we can’t control it, we are at the mercy of chance.

Items 2. through 4. are mainly applicable to process management, and we’ll talk more about these within the context of data management in the next post. But item 1. is pertinent to both process management and data management, and requires our full attention.

The folks who built pipelines in the 1950’s simply could not predict which bits of information would prove critical almost sixty years later; they didn’t know what they didn’t know. Nor, short of a working crystal ball, could they. So more accurately, they couldn’t know what they didn’t know. (LOL! That’s a bit convoluted, but I trust you get my drift.) By extension, we may not necessarily know which bits of information will prove critical sixty years from now. Logically, the most prudent course of action is to store every bit of information we possibly can, even information that might seem unimportant.

To put this another way, one should assume that everything is potentially important. Note this statement reflects attitude and outlook, not technology or even process. But if properly embraced, it guides how we design and build the processes that gather, validate, verify, audit, store, analyze, and distribute data. Attention to detail must become a passion.

If all this sounds like hard work, well, it is. But it beats the heck out of the alternative, and Dr. Harry’s items 2. – 4. help us approach this work systematically. We’ll talk more about this in the next post. Meanwhile, remember what the Navy SEALs say: “The only easy day was yesterday!”