One of my favorite songs from a musical has the line ”525,600 minutes; How do you measure, measure a year?” And how many songs have been written about the “measure of a man”? These are all catchy tunes, but after a recent remodeling experience, I was starting to question the “measure of a measure”.
It sounds like a bizarre statement or a flashback to something related to 1990′s function points… measuring a measure? Even more bizarre was the reason that the thought kept running through my head. Normally, my personal and professional lives stay somewhat separate; however, the aforementioned remodeling caused these two worlds to collide in a way that I couldn’t have imagined.
In order to make amends with my remodeling company (guilt from making one too many change orders), I agreed to help out by ordering some of the materials myself. Little did I know that nothing I needed would be in stock at a local store and I would be at the mercy of websites.
The mission: Order a tub.
The challenge: Maneuver a home improvement store’s web site and order the correct item – a 60×32 tub with right hand drain.
It sounds simple enough, right? It would have been, if the necessary metadata were in place.
With specs in hand, I attacked the internet with gusto. After searching a home improvement store’s site for a while, I decided to use the site’s “compare” feature to narrow my choices. And that’s where it all went downhill. As I scanned the specs for each item, I could not believe my eyes. A 999 foot high shower wall? A 999 foot wide tub? Would this item really fit in anyone’s house? And why does a different field say it’s 60 inches wide? Why would somebody fill all of these fields with what seemed to be garbage data? Needing a rational answer (i.e. proof that the company didn’t have a master data management solution or data governance), I searched for information on the company.
After a few minutes, I found an article talking about how the company had reached its goal for product master data quality – a metric related to the percent completion of product metadata. Ready to wave a judgemental finger, I was all set to send some unsolicited advise to the company. Luckily, a little voice just wouldn’t let me push the send button. “What about YOUR measures?” Wow, what a reality check!
I started to think about how we can select measures that make sense and truly assess progress toward the goal that we want to meet. If the goal was to provide a positive experience to the customer (ideally, a “compare” utility would have been a great way to entice customers), shouldn’t the measure of data quality be something that supports that goal? While measuring completeness can be a good thing, in this case, correctness was probably at least, if not more, important. It left me wondering if the chosen metric was a factor in the decision to fill fields with incorrect values.
So I was left asking myself a few questions:
- Are my metrics aligned with my goal – the true goal- or are they just something I can easily calculate and show on a dashboard?
- Could my metrics encourage behaviour that would conflict with my goal?
Who knew that an experience in home improvement could have invaded my professional life and made such an impact? I guess that sometimes you get more than a nice room from a remodel!
NOTE: Thoughts expressed in this blog are those of the author and not her employer.
Measurement is a problem is many organizations. It is relatively easy to measure the time and costs to complete a development project, and those who choose to implement tactical shortcuts are rewarded for quick delivery.
However the costs associated with rushed requirements, bad architecture and the poor data quality that often results is much more difficult to measure. Long after the development team has wrapped up their celebratory post-project parties, the business is running reports and manually correcting erroneous data values, expensive work-arounds are supported to address missed requirements and follow-up projects are needed to accomodate business changes that would have been easily accomodated by a more flexible, architecturally-sound initial implementation.
Fast and cheap is good, but one must accurately measure all relevant short AND long-term costs.
Thank you for sharing your thoughts, Patrick! I wholeheartedly agree!