Revisiting Table 7.1

Table 7.1 G. Langley et al. (2009), The Improvement Guide, 2nd edition, Jossey-Bass, San Francisco © Associates in Process Improvement, used with permission.

Over the past 25 years, my colleagues at Associates in Process Improvement (API) have taught me many ways to think and act to improve system performance. I regularly turn to Table 7.1 of their The Improvement Guide, 2nd Edition, discussed in posts here, here and here.

Does Implement Mean ‘No More Testing’?

No! 

In our current project to integrate medical and oral health care for people with diabetes, several dental teams have changed workflow:  each dental team knows whether or not each patient on their schedule, every day, has a diagnosis of diabetes.

These teams are getting ready to implement the ‘know each patient’s diabetes status’ change, making this change an expected part of the regular care process. 

Support systems--training for new staff, quality control monitoring and feedback, written documentation, and purchasing/supply management—provide new contexts for testing.  The Improvement Guide 2nd edition gives a project team worksheet in Table 8.1 (page 180); the worksheet summarizes testing opportunities in implementation.

In the long run, over weeks and months, the intentional change to know each patient’s diabetes status will be buffeted by variation in the clinic’s environment.  Inevitable changes to mix of patients and staff, changes to the electronic record systems, changes in insurance coverage will all affect performance.   Applying Steve Spear’s insight, clinic teams that want to maintain the new practice will need to continue to learn.  Efficient learning requires explicit testing.

Build Skill in Testing to reduce Cost of Failure

Table 7.1 highlights Cost of Failure as one dimension in choosing the size of a test.  In health care, cost of failure includes injury to patients or staff; cost of failure also includes wasted time and money, along with depleting enthusiasm of patients and staff to try new ideas.

The table shows that if your expected cost of failure is high, you should consider small or very small tests unless your belief in the change is high and you have high organizational commitment.

If you’ve ever purchased an insurance policy for a car or home, you know that there are two ways to reduce the chance of incurring costs from a failure:  reduce the chance of failure or pay for insurance that will cover the cost when a failure occurs.  If you reduce the chance of failure, the cost of insurance goes down—the insurance company uses past experience over many customers and makes a prediction about your risk of failure.  Your predicted risk drives the cost of your insurance. 

In terms of Table 7.1, tests over a range of conditions reduce the chance that your change idea will fail on implementation.  Effective testing reveals problems with workflow, documentation, and communication.  Jump on the problems and prevent long-term damage.

What about an insurance policy?   I don’t know of any insurance companies writing policies to compensate you when you fail to implement a change like ‘know each patient’s diabetes status.’  However, if I were in the business of implementation insurance, my calculations of premiums would surely depend on my assessment of your management capacity:  demonstrated skill by your teams and managers to monitor performance, distinguish signals from noise, and rapidly test solutions to problems uncovered during operations.