For better or (mostly) worse, in my professional career, I have consistently found myself on projects suffering from a bevy of issues, many of which were related to data. By 2008, I had reached a tipping point: I was either going to write a book about IT project failures or see a shrink. I chose the former.
In other words, it’s rare that, as a consultant, I have the ability to influence the direction of an organization’s data management. I find myself these days in such a place. The details of my project aren’t particularly interesting to the average reader. For now, however, suffice it to say that I am building a little ETL tool that takes a bunch of data from a bunch of places, transforms it, and spits it out to a bunch of people. I’d give this about a 4 on my 1-10 scale for complexity. (Yes, I have had to build tools that scored a 14 on that same 1-10 scale before. Take me out for a beer sometime and I’ll tell you a story or two.)
On my current assignment, I am working with a large financial institution in the midst of some M&A activity. I am working closely with a director named Dave. (This is not his real name; I just happen to be listening to the Foo Fighters right now and their front man is ridiculously talented Dave Grohl). Dave is getting pulled in a bunch of different directions and, using more tact than I have, is trying to successfully navigate his organization’s political waters. As soon as we make the changes to file formats for his internal clients, he almost just as quickly comes back with changes and “the new final” formats.
While I’m a big fan of Agile development, constantly changing things is hardly efficient. The other day, Dave told me that we just had to make three changes to “descriptions” that should be quite easy. I furrowed my brow, telling Dave that things weren’t quite as simple as that. His “descriptions” were my fields on multiple tables and queries. Without giving TMI, the changes actually involved a decent amount of work.
But then something strange happened: Dave watched me for an hour make these changes in every place. I’d run the Access-based ETL tool and show him how these ostensibly minor changes caused the whole thing to break. We had developed this on the fly because (spoiler coming) the whole tool was due well before I started.
Armed with a new-found appreciation of the major impact of minor changes, Dave has vowed to do two things now:
- Run any changes by me before agreeing to make them, even if they seem insignificant.
- Immediately say no to changes that appear to be major.
Dave was minimizing the chance that excessive changes would break the ETL tool and compromise what he sent out. In short, Dave was defending the data.
My life would be a great deal easier if more clients stuck up for their data. In my admittedly jaundiced experience, most people just want what they want when they want it. They don’t understand concepts such as data integrity, referential integrity, master data, and the like. One could argue that not everyone needs to know what we data management professionals know. Perhaps they are right. But an appreciation for the data goes a long way towards ensuring that things don’t completely spiral out of control.
What say you?