| Home | FAQs | Book Contents | Updates & News | Downloads |
I have often encountered a strange belief where an expert in one field thinks that anything they don't know how to do must automatically be "easy". For example, as a software developer when I told someone how long it would take to write a particular piece of code I was usually met with incredulity and told that it could not possibly be that hard. My own (no doubt biased) recollection is that usually it normally turned out, in the event, that my original guess was either slightly optimistic or wildly optimistic.
Doing "information management landscape assessments" for E&P companies is another activity that I am often informed "can't possibly take that long" (by people who couldn't ever do it themselves). In that case there seems to be an assumption that the highly visible part of the job, interviewing the E&P technical data experts, is the bulk of it, whereas, at least when I do it, the back room analysis and write-up usually take at least twice as long.
I was reminded of this recently when talking to a senior oil company executive. He felt that my estimate of how long it would take to develop a good, workable technical data standard was overly pessimistic. I got the impression he thought my reservation was rooted in an underestimate of his company's abilities. While in my experience writing workable data standards is hard, complex and fraught with pitfalls, it takes a major investment in talent and time to do it right, and even the most sophisticated modern oil company (which this one was) would require this level of significant effort. Devising standards that are destined to sit collecting dust on the high shelves of oil company offices is easy, that I can do in my sleep (obviously a skill that is very widely shared).
In my experience building a standard that will actually positively impact data handling in a company requires several documented elements: an agreed definition of the scope; an outline of the related business processes; some aspects of the data structures (without getting bogged down in the detail of trying to converge on a single data model); a list of the participants and their responsibilities; details of the main data handling activities; ways of measuring adoption; quality checking rules checked by domain experts; an idea of how to link to essential documents that provide details; and, an indication of the closely related data. My bias is that the only people that know those things are the data users themselves, that is the domain experts, but they have little experience in such formal and precise specification, so while they are writing they need a lot of assistance from data management specialist, technical authors, qualified trainers, change management experts and so on. And just writing the standard is only half the job, implementing it is the really hard bit. Embedding the new processes into the company's culture requires a change management project (which those same domain experts must be a major part of).
Now don't get me wrong, writing good data standards is not an impossible mission, but as someone once said about a good marriage "it's not about getting one single thing right, it's about not getting any one of a hundred things wrong".
 Article 58 |
 Articles |
 RSS Feed |
 Updates |
 Intro |
 Book Contents |
 All Figures |
 Refs |
 Downloads |
 Links |
 Purchase |
 Contact Us |
 Article 60 |