This Old House—Part 3: Lessons from Water in the Basement

The systems I encounter in health care project work are far more complex than my old house.  The interplay of people and technical tools present many opportunities for mysterious failures and performance below expectations.  Nonetheless, between mopping up water and caulking joints, I thought about connections between our basement trouble and my day job working with teams to solve problems and improve performance.

Problem-solving in Seven Steps

Our basement situation is an example of one type of problem, described by Gerry Nadler as an ‘operating and supervising’ problem, discussed in two previous posts here and here.  This type of problem occurs when an established system or solution does not produce the expected, standard result.  Takahashi and Kume show how to document solutions to operating and supervising problems in “The QC Story”, Statistical Methods for Quality Improvement, 3A Corporation, Tokyo, 1985.  If you have used A3 problem-solving, you can see how the QC Story’s seven steps match elements of the A3 format.

1. Problem Identification In our case, it was easy to identify the problem:  before February, dry basement; in February and March, wet basement when it rained.  Our aim is to have a dry basement.

2. Observation As described in the first two posts, we observed the system:  foundation, driveway, roof, gutters, downspouts, rain events.   “Generally speaking, problem-solving should be based on data.  Information not based on data, i.e. memory or imagination, can be used only for reference… If possible, those involved in the investigation should be at the site; not in an office, but actually on-site.  Here they can observe and obtain information that cannot be put into [numerical] data form.  This kind of information, which works like a catalyst in a chemical reaction, gives new hints for solving the problem during the thinking process.”  (QC Story, p. 197).   Go see!

3. Analysis As we observed and reflected, we thought about main causes of our problem. Three main causes appear to be jointly sufficient for water in the basement.   A simple Cause-Effect diagram that is also a Directed Acyclic Graph makes it easy to show our theory.  While we haven’t established what constitutes a high volume of water, some volume of water adjacent to the driveway-side foundation appears to be a necessary cause.

4. Action Our actions to eliminate the causes focused on (1) reducing water volume by raking snow off the roof and getting rain and snow melt to flow through gutters and downspouts away from the foundation and (2) caulking a driveway expansion joint and gaps in the L shaped barrier that got disturbed in the 2018 summer driveway repair.  

5. Check A display of weather data from the local airport weather station helps to see the impact of the actions. After we left for our trip on 28 March, the precipitation graph shows five days with maximum hourly precipitation as great as the days with water in the basement. While the ground has now thawed and does not match conditions in February and early March, intense rain on 22 April and a dry basement have increased our belief in the effectiveness of the actions.

6. Standardization (permanent elimination of the causes).  While we can’t eliminate rain and snow, next winter I need to find different places to mound up snow from the driveway to reduce water volume from snow melt during rain storms.  We must maintain the caulking in the expansion joint and along the L shaped barrier.  We’ve also decided to have the basement contractor seal the legacy foundation crack when he installs an interior drain and sump pump next month—addressing the third of our major causes.  

7. Conclusion and Reflections The rain and temperature graphs help make the case that we may have solved the water problem for now.  Ideally, we would have had rainfall and temperature data measured at our house, not from the airport seven miles away; still, the weather data looks good enough to guide analysis and interventions.  And good enough data is a reasonable guide in applied problem-solving.

The monitoring method we used while we were away—video camera and water sensor—worked well.  On the other hand, it relied on household power that runs the Wi-Fi network and camera (the water sensor is battery operated).   If a storm had knocked out power to our house, we had no ability to monitor and no electricity to run a pump.  However, our back-up to powered technology was a neighbor with a key to the house; we hoped his ingenuity would be enough to address any water in the basement if there were no power.  It seems like a good decision to have a human somewhere in a system to be able to improvise a fix if high tech solutions fail.

In our analysis, the failure of the barrier between the driveway and the foundation is a major cause of water coming through the legacy foundation crack. An interface is a typical place for systems to fail—a failure of the relationship between parts rather than a failure of the parts themselves.  When you replace a part in a system, the repair is incomplete unless you connect the part correctly to the other parts.  You must repair the relationships in order to restore performance.  We neglected repair of the foundation-driveway relationship and had to mop up a lot of water.

Here’s a link back to my day job.  In our oral health project, adhesion between sealant and tooth surface must occur to prevent tooth decay.   Unless the clinician prepares the tooth surface properly, uses the right amount of material, and cures it correctly, the relationship between sealant and tooth will fail.

Considering the oral health learning community as a system, we ask health centers to test changes, measure performance, and share progress with faculty and improvement coaches.  Each health center has a team and team leader to do the project work. Turnover in team leaders typically disrupts project progress and communication with the learning community.  The relationship between health center and learning community changes. Very few health centers manage to maintain previous levels of process testing, performance measurement and reporting after a team leader moves to a new position and is replaced. 

A Reminder on the difference between Improvement and Control

I teach and coach teams to use the Model for Improvement, a general algorithm to achieve an aim.

I kept the Model’s three questions in mind:   Aim?  No water in basement.  Measure?   Water in basement.  Changes to achieve the aim?  We developed fixes based on analysis.  And then multiple PDSA cycles:  planning the fixes, doing the fixes, studying the effects, and trying to act rationally based on what we learned to achieve a dry basement.

Is our now-dry basement an improvement?   Dry is better than wet, so yes, in a sense we’ve improved the situation.  Nonetheless, we were working to get back to a previous level of acceptable performance—our wet basement was a problem in quality control rather than quality improvement.   That’s why the Quality Control Story outline provides a good way to summarize what happened this past winter at our old house.