In a similar vein, I came across a situation where field staff were paid based on their productivity – if they didn’t hit a set job average, their pay was cut. So if their average was down, and they should have been recording data on the assets they were replacing, they would tend to save the data update and hope they could catch up on it at the end of the week. Inevitably, they never recovered the time and the data was ‘lost’ to the organisation.
The cost to send someone out to site to collect the data was far higher than the incremental cost of spending another 5 minutes to record the data.

Conflicting targets are never a good idea, but can be hard to spot in large complex organisations.

Julian

@Jill I’ve fought that same good fight. Glad to hear that the organisation is more or less taking the “reasons why” to heart. In my experience, IT Technology people will tend to focus on the Database platform, and (if we’re lucky) the technical tools being used, and the Business tend to sup the koolaid a little too much about how easy this stuff is (sure, just buy another BI tool or CRM platform…) Inevitably people carry a tonne of information around in their heads about “how things really work”. The problem is that if you get 3 of them in a room, you’ll get 4 versions of how things work.

Check out http://obriend.info/2010/03/17/st-patricks-day-special/ for another take on this theme.

I have to admit that I was LMAO at “then there was a loud bang and the power went out.”

I think “magic smoke” is also a great metaphor for DQ/IQ. If only it was that simple to make the shocking truth of poor information quality that obvious to the organization.

Best Regards,

Jim

Our team was asked to support the implementation of a CRM solution and one of the very first things we did was to ensure that for each and every piece of data there was a definition, clearly defined rules, identified stakeholders and business purpose (I’ll call this data definition for simplicity). This information was (and is) shared throughout the organization and is essential to ensure that data creators and users all understand the whole point behind it all. To this day, data definition is an essential part of each successive deployment. Unfortunately, not all system deployments follow the same process, so we have a long way to go!

What amazes me is how often this kind of information is discussed (the original electrician probably chatted about the wiring with all his co-workers) but never written down. What a waste. I sometimes rant that the persons who behave this way (have information but don’t share it) are… dare I say it: ‘narrow minded’, because they don’t think about the big picture and how others may benefit.

Thanks again for a thought provoking post!