Cost of Non-Quality

August 12, 2015 by
Filed under: Leadership, Quality 

I just read an article, albeit a year old, that suggests preventable medical errors persist as the number 3 killer in the US, behind heart disease and cancer. I wasn’t surprised for two reasons: a) I had seen similar literature before from other sources, and b) I had worked with companies in the medical field and large IT infrastructure projects.

Having also worked on a large air traffic control system in the past, I’ve got an understanding of the sort of focus that should be in place for projects where lives are at stake. While some people might suggest a project that comes in about a billion over budget and a decade late would fall into the failure category, I would counter that the emphasis on robustness and safety trumping money and time made that project a rousing success.

Alas, in my experience, the most appropriate prioritization of values does not always win out.

For all of the appropriate focus on safety at NASA, the reports following the two shuttle disasters pointed toward elements like complacency and adhering to launch schedules winning out.

I have seen medical device companies give lip service to quality and safety, investing enough to ensure they have a good story for the auditor, rather than simply ensuring through sufficient oversight that there shall indeed be a safe, high quality product go out the door. My sample space may be relatively small, but the laughable emphasis on true quality by the majority of my data points suggests trouble in paradise.

Remember that formula for recalls from Fight Club? Negligence Law suggests that it’s good business that if the Burden of Taking Precaution > Probability of Flaw * Loss, then don’t take that precaution. In monetary terms, the right business thing to do can easily be justified as less than the ethical thing to do.

I have seen (and heard many more anecdotal stories) large infrastructure projects, such as the electronic health records projects that are in vogue these days, deemed successful because they deliver acceptably close to on-time and on-budget. Generally this declaration occurs when the system goes live, only to find the end-users are massively disrupted by the system they had little say on to ensure their needs are addressed, and little change management (including training) to ensure they are benefitting from the value promised by the new system.

The challenge here, again, is the narrow focus on success as cost and schedule, compounded by the narrow focus on scope as functionality, rather than taking the bigger picture of delivery of value.

Connecting Data A to System B is the easy part.

It’s making that information usable by Nurse C or Administrator D, with a goal of keeping Patient E alive and healthy that should all be part of the calculus of success on these projects.

The referenced article talks about data and metrics being key, and baselines for these should be readily available (or easily mineable) given this generation of electronic health records projects.

The key is to use this information from day one on projects, along with comprehensive stakeholder engagement, to define success as improving on these baselines by a measurable difference, with less emphasis on cost and budget. It’s not rocket science, but it means deeper up-front analysis and more comprehensive project scope.

It’s achievable with today’s knowledge and technology, but not with today’s emphasis on the bottom line, increasing neglect of effective analysis approaches, and the obfuscation of the true costs of non quality in today’s complex systems.

For now, eat healthy, exercise, and for goodness sake, stay out of the hospital. – JB

If you enjoyed this post, make sure you subscribe to my RSS feed!

Comments

One Response to “Cost of Non-Quality”

  1. Geoff on August 13th, 2015 10:22 am

    Well… perhaps I just felt like writing this morning and you already know all of this.

    Cost and schedule are always the fall backs because they are just easier to quantify, more so than to trying to put number decals onto the Mothership of Quality. Let me adjust that a touch – “schedule” is the easiest to quantify but “costs” related to development are not as precise although still a quantum improvement over many of the aspects of “quality”.

    Some things like test coverage (code, branch, paths, design integration, etc.) are less perplexing and will cover many of the quality characteristics like maintainability or testability, etc. It’s those other ‘softer’ quality attributes, however, like usability and functionality that are less quantifiable and require stronger “human” capability in managing customer relationships, finding someone who understands what (most of the) customers really want, specification, design, etc. Factor that against an amazing demand for capable human beings and often companies can only take what is available and do their best to try and train as best as possible.

    We take on varying levels of risk in order to pay the operational costs of our business – the operational costs are easily quantifiable. Often the customer doesn’t really quite know what they want and we take our best shot at it. Unfortunately the users are often our best testers of solution quality.

    So… what is easily measured always seems to win.

    To me it’s always been so surprising how little we know about what we are trying to build for customers and then are asked to deliver to a precision of a single day. It’s never changed, ha ha.

    But then, you and I already know all of this. It’s a tough world out there.

    Cheers,
    GF

Feel free to leave a comment...





  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.


    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    Jim is extremely knowledgeable, and just as important, he is very interested in sharing that knowledge with his audience and working with his clients to ensure they are successful. He was very ‘hands-on’ prior to the training, during, and followed up with us afterwards. It was important to us that we partnered with someone who really took an interest in providing that value.

    — Chris Lauzon, Autodesk