“Some is not a number and soon is not a time”
Jim Harris in Blogs, Books, Data Quality tagged Best of 2010, Change Management, Philosophy Thursday, August 26, 2010 at 3:00PM In a true story that I recently read in the book Switch: How to Change Things When Change Is Hard by Chip and Dan Heath, back in 2004, Donald Berwick, a doctor and the CEO of the Institute for Healthcare Improvement, had some ideas about how to reduce the defect rate in healthcare, which, unlike the vast majority of data defects, was resulting in unnecessary patient deaths.
One common defect was deaths caused by medication mistakes, such as post-surgical patients failing to receive their antibiotics in the specified time, and another common defect was mismanaging patients on ventilators, resulting in death from pneumonia.
Although Berwick initially laid out a great plan for taking action, which proposed very specific process improvements, and was supported by essentially indisputable research, few changes were actually being implemented. After all, his small, not-for-profit organization had only 75 employees, and had no ability whatsoever to force any changes on the healthcare industry.
So, what did Berwick do? On December 14, 2004, in a speech that he delivered to a room full of hospital administrators at a major healthcare industry conference, he declared:
“Here is what I think we should do. I think we should save 100,000 lives.
And I think we should do that by June 14, 2006—18 months from today.
Some is not a number and soon is not a time.
Here’s the number: 100,000.
Here’s the time: June 14, 2006—9 a.m.”
The crowd was astonished. The goal was daunting. Of course, all the hospital administrators agreed with the goal to save lives, but for a hospital to reduce its defect rate, it has to first acknowledge having a defect rate. In other words, it has to admit that some patients are dying needless deaths. And, of course, the hospital lawyers are not keen to put this admission on the record.
Data Denial
Whenever an organization’s data quality problems are discussed, it is very common to encounter data denial. Most often, this is a natural self-defense mechanism for the people responsible for business processes, technology, and data—and understandable because of the simple fact that nobody likes to be blamed (or feel blamed) for causing or failing to fix the data quality problems.
But data denial can also doom a data quality improvement initiative from the very beginning. Of course, everyone will agree that ensuring high quality data is being used to make critical daily business decisions is vitally important to corporate success, but for an organization to reduce its data defects, it has to first acknowledge having data defects.
In other words, the organization has to admit that some business decisions are mistakes being made based on poor quality data.
Half Measures
In his excellent recent blog post Half Measures, Phil Simon discussed the compromises often made during data quality initiatives, half measures such as “cleaning up some of the data, postponing parts of the data cleanup efforts, and taking a wait and see approach as more issues are unearthed.”
Although, as Phil explained, it is understandable that different individuals and factions within large organizations will have vested interests in taking action, just as others are biased towards maintaining the status quo, “don’t wait for the perfect time to cleanse your data—there isn’t any. Find a good time and do what you can.”
Remarkable Data Quality
As Seth Godin explained in his remarkable book Purple Cow: Transform Your Business by Being Remarkable, the opposite of remarkable is not bad or mediocre or poorly done. The opposite of remarkable is very good.
In other words, you must first accept that your organization has data defects, but most important, since some is not a number and soon is not a time, you must set specific data quality goals and specific times when you will meet (or exceed) your goals.
So, what happened with Berwick’s goal? Eighteen months later, at the exact moment he’d promised to return—June 14, 2006, at 9 a.m.—Berwick took the stage again at the same major healthcare industry conference, and announced the results:
“Hospitals enrolled in the 100,000 Lives Campaign have collectively prevented an estimated 122,300 avoidable deaths and, as importantly, have begun to institutionalize new standards of care that will continue to save lives and improve health outcomes into the future.”
Although improving your organization’s data quality—unlike reducing defect rates in healthcare—isn’t a matter of life and death, remarkable data quality is becoming a matter of corporate survival in today’s highly competitive and rapidly evolving world.
Perfect data quality is impossible—but remarkable data quality is not. Be remarkable.
Reader Comments (9)
That might be my favorite title for a blog post in the last year, man.
Great post as ever Jim.
I used to get incredibly frustrated with the data denial aspect of our profession. Having delivered countless data quality assessments, I've never found an organization that did not have pockets of extremely poor data quality, but as you say, at the outset, no-one wants to believe this.
Like you, I've seen the natural defense mechanisms. Some managers do fear the fallout and I've even had quite senior directors bury our research and quickly cut any further activity when issues have been discovered, fortunately that was an isolated case.
In the majority of cases though I think that many senior figures are genuinely shocked when they see their data quality assessments for the first time. I think the big problem is that because they institutionalize so many scrap and rework processes and people that are common to every organization, the majority of issues are actually hidden.
This is one of the issues I have with the big shock announcements we often see in conference presentations (I'm as guilty as hell for these so call me a hypocrite) where one single error wipes millions off a share price or sends a space craft hurtling into Mars. Most managers don't experience this cataclysm so it's hard for them to relate to because it implies their data needs to be perfect, they believe that's unattainable and lose interest.
Far better to use anecdotes like the one cited in this blog to demonstrate how simple improvements can change lives and the bottom line in a limited time span.
@Phil — Yes, as soon as I read Donald Berwick’s story in Switch, knowing that quote had to be the title of a blog post at some point, I scribbled it into my writing ideas notebook (I am old school, so yes, I actually have a writing ideas notebook) even though I wasn’t sure at the time what the blog post would be about.
@Dylan — I definitely agree that a strong correlation exists between data denial and the shock and awe, doom and gloom messages often cited (and I’m as guilty as hell too) in conference presentations, whitepapers, webinars, and blog posts about The Poor Data Quality Armageddon (hmmm, that would make a great title), which unless you get data quality religion, will bring about The End of Your Data’s Days (oh, I am on a copy-editing roll now).
Last month, in his blog post Why do you watch it?, Henrik Liliendahl Sørensen called for all of us to tell more success stories, and using Muppets references, he called for us to spend more time as the funny Fuzzy Bear on the stage, and spend less time as the ornery Statler and Waldorf on the balcony.
As usual, we should all be following Henrik’s excellent advice.
What an excellent example you found. Drives the point home.
No more:
"We need to improve our data quality."
"There. Is it better?"
"Yeah, it's better."
Even if you have numbers, you need to decide what is good, and what is remarkable. Each is probably less than perfect.
@Terri — Yes, both good and remarkable are less than perfect. And although perfect is impossible and numbers of any kind can be misleading, the healthcare example helps here as well.
It's easy to imagine wanting to be perfect in healthcare since, after all, anything other than perfection (i.e., zero defects) would mean that patients are dying needless deaths — even one defect a year can be heartrendingly intolerable. But this is also why emergency medical situations use triage techniques — because attempting to save everyone means that you could end up saving no one.
It's far easier in healthcare to sleep at night by telling yourself that “our hospital doesn't have a defect rate.”
It's far easier to deny a problem exists, than to challenge yourself to battle against it, especially knowing that, despite your best intentions, sometimes you will lose.
But you must also be prepared to celebrate your successes.
Here are the closing words of Dr. Berwick's speech back on December 14, 2004, when he issued the challenge, and predicted how the world would look when they achieved their goal of saving 100,000 lives:
“And, we will celebrate. We will celebrate the importance of what we have undertaken to do, the courage of honesty, the joy of companionship, the cleverness of a field operation, and the results we will achieve.
We will celebrate ourselves, because the patients whose lives we save cannot join us, because their names can never be known. Our contribution will be what did not happen to them.
And, though they are unknown, we will know that mothers and fathers are at graduations and weddings they would have missed, and that grandchildren will know grandparents they might never have known, and holidays will be taken, and work completed, and books read, and symphonies heard, and gardens tended that, without our work, would have been only beds of weeds.”
I really, really love this blog post, Jim.
It's something that drives me crazy!
And not just how this relates to data quality, but success measures and poor communication in general.
If you ask someone how the task is coming and their response is: "it's coming", or how much time do we have to complete this and you hear: "yesterday". If (ok, when) someone says that to me I respond with: "how many days does 'it's coming' mean"?, or "what is the drop dead date for 'yesterday' and what happens if it isn't met"?
I really bugs me that in instances such as these, and they happen all the time, that I have to waste my precious time trying to extract exact, honest and accurate information from people who don't even know what it means.
GRRRR...
Thanks once again for astute insight.
Jill
@Jill — Thanks for your GRRRR...great comment :-)
In my blog post The Winning Curve, which also referenced books by the Heath brothers and Seth Godin (hmmm, I am detecting a pattern), I wrote about how setting specific times when you will meet (or exceed) your goals is so difficult because most people view that delivery date as something that forebodingly looms on the calendar.
The delivery date is when your definition of success will be judged by others, which is why some people prefer the term Judgment Day since it seems far more appropriate.
“The only purpose of starting,” writes Godin, “is to finish, and while the projects we do are never really finished, they must ship.” Godin explains that the primary challenge to shipping (i.e., accomplishing your goal by or before your delivery date) is thrashing.
“Thrashing is the apparently productive brainstorming and tweaking we do for a project as it develops. Thrashing is essential. The question is: when to thrash? Professional creators thrash early. The closer the project gets to completion, the fewer people see it and the fewer changes are permitted.”
Thrashing is mostly about the pursuit of perfection.
We believe that if what we deliver isn’t perfect, then our efforts will be judged a failure. Of course, we know that perfection is impossible. However, our fear of failure is often based on our false belief that perfection was the actual expectation of others.
Therefore, our fear of failure offers this simple and comforting advice: if you don’t deliver, then you can’t fail.
Success or failure—or even worse, mediocrity—could be the judgment that you receive after you have delivered.
Success rocks and failure sucks—but only if you don’t learn from it.
Being remarkable means always delivering on the promises of your specified goals at your specified times.
From the LinkedIn Group for Enterprise Data Quality, Gordon Hamilton commented:
“Good topic Jim, too many people have never actually measured the quality of their data and that forces them to use the mushy numbers. It seems that they would be happier, or at least more conscious, if they could begin with one solid DQ metric that they can begin to manage to and grow their organizations IQQ around.”
And I responded:
Yes, mushy numbers are as useless as data quality metrics that do not provide insight into how data is being used to make business decisions.
From the LinkedIn Group for Data Quality Pro, Duane Morrison Smith commented:
“Great pep talk Jim. We all need to be realistic when striving for excellence in data quality.
However, if we don't aim for perfection we will never know what is possible. I am always asked about measurement when it comes to data quality and constantly see some people expecting 100% accuracy while others being prepared to accept double digit percentages when it comes to error rates.
These sorts of beliefs or attitudes reflect the culture of an organisation as to what expectations exist and also what the level of commitment to quality is in general. Take a barometer of the quality of information in an organisation and you will get a good feel for the attitudes and standards in the organisation or lack thereof.
As data quality practitioners we need to constantly strive for excellence, accept that imperfection will exist and persist, and find remarkable ways to constantly deliver quality outcomes.”