Let’s pretend that I am the exploration manager for a medium sized oil and gas outfit company and we have just drilled an expensive dry hole. I am feeling the heat already. During the drilling, as is customary - well it used to be I don't suppose it is now - the company’s top brass, WAGS* in tow (sorry for the sexism but World Cup oblige) all traipsed out to the drill site located in a woodland area to witness the well test and (hopefully) celebrate. During the visit, the CEO and her husband (back in your good books?) wandered off (what could they have been up to?) into the woods and discovered an old abandoned well head only a couple of hundred yards from ours!
The CEO came back disconcerted asking what was going on. I was on the spot as I hadn't a clue what this old well was about. It wasn't on any of our maps. Our well then failed spectacularly to flow and we all headed back home, me in a state of considerable embarrassment. Now this is a fiction, so let’s imagine that instead, as is customary, such things get swept under the carpet, we kicked off a post mortem investigation to find out why the hole was dry and what should be done to avoid it happening again.
This post mortem is an excellent example of a good business question that has some interesting attributes. Number one it is easy to understand by all those involved. Number two it is ring fenced - why is the well dry? And number three - it has a chance of being answered with finite resources in a reasonable time frame. It is, in other words, a business question that has all the attributes necessary to turn it into a project! Note the order of things here. To give this more weight I propose a little flow chat viz.
OK I can hear you think, ‘that is pretty dumb as flow charts go’ but bear with me.
Actually answering both components of this question can be quite tricky which is why I introduced the deus ex machina of the nearby well. The investigation found that the old well drilled some 30 years ago had already tested the structure and proved it to be dry. How could we have re-drilled a dry hole**?
Although this scenario sounds improbable it does happen. Wells are ‘lost,’ or misplaced. Wells are drilled in the wrong place. Sidetracks run into old wells, logs may be wrongly depth registered and so on. Shit happens...
Such issues are of great interest from an IT perspective. We have identified a data issue. What can IT (I use IT in the broadest sense including data management, governors and computer experts etc.) do to help? IT loves to ‘abstract’ and generalize problems. Data issues of this nature are currently considered to be ‘master data’ problems and as such amenable to being handled in a ‘master data management' (MDM) project. At this juncture I invite you to visit Wikipedia to see what a large bucket MDM is today - including data cleanup, consistency, ‘unicity’ and so on.
A presentation from Entrance Software’s Nate Richards at the 2014 PNEC conference last month on ‘Unexpected insights from an MDM failure’ included a citation from Gartner which forecast that, ‘Through 2016, only 33% of organizations that initiate an MDM program will succeed in demonstrating the value of information governance.’ Richards argued that ‘MDM initiatives are not just projects,’ and that ‘people are the primary drivers of success (or lack thereof).’
I think there is another problem with the MDM project in that its top-down approach only brings benefits when a project is complete. In North America, several million wells have been drilled for oil and gas. Large operators have thousands, perhaps hundreds of thousands of wells in their databases. As more complex wells are drilled, operators are confronted with more tricky geometries, the burden on an operator to track everything goes through the roof. We are quickly into ‘boiling the ocean’ or ’solving world hunger’ territory to use just two popular clichés.
If MDM projects really do fail as often as Gartner would have it***, it is probably because they are ‘MDM projects’ and as such are unconstrained and not addressing a sufficiently specific business issue for them to have a chance of success. In fact Richards’ presentation revolved around the implementation of ‘complex shale lease compliance' which is indeed a good ‘business question.’
How should my fictitious company have gone about ‘not letting it happen again?’ I don't know. Maybe they should have fired me (maybe they did, maybe I didn't make all this up). Perhaps a data blitz prior to drilling would be a good approach - checking all information within say a 10km radius of the well location for accuracy. ‘Just-in-time MDM' if you want to be fancy. At least take a walk in the woods before spudding to make sure nothing embarrassing will be seen by the CEO. Whatever approach you try, just remember the magic formula and put the business cart before the project horse.
* WAGs - wives and girlfriends (in football parlance).
** I am not very happy about this intro and I don't suppose that you are either. You may like to replace it mentally with an unusual set of circumstances that have tested your information systems. The expression 'the exception that proves the rule comes to mind.’ This is not, as is commonly believed, nonsensical. It refers to an older usage of the word 'prove’ as in ‘puts to the test.'
*** I am a skeptic when it comes to Gartner-style analyses and I am not saying that MDM is a waste of time. Data cleanup etc. is an essential part of doing business. On the other hand, many data ‘issues’ would go away if the constraints available in the relational database were correctly implemented.
© Oil IT Journal - all rights reserved.