Besides bonds, bank loans, accounts payable, lease payments and other common forms of corporate debt, your company also holds “technical debt,” according to Mike Orzen, co-author of Lean IT and an LEI faculty member with deep experience implementing continuous improvement at tech and service companies. Technical debt is the burden of future IT rework caused by superficially firefighting problems instead of eliminating their root causes. Fortunately, the scientific problem-solving method of plan-do-check act (PDCA) can get you out of hock. Orzen explains how in this response to a question from an attendee at the webinar Beyond Problem-Solving: Other Facets of the A3 Process You Should Know and Practice. The attendee asked if the A3 process, which is based on PDCA, worked only for manufacturing, not information technology processes.
It’s a mistake to think that lean management’s continuous improvement methods and tools are exclusively applicable to manufacturing. You can think of manufacturing as the original development and testing ground for many lean principles and tools, such as the A3 problem-solving methodology, but by no means is it a boundary.
In working with many large organizations that spend hundreds of millions of dollars on IT, I have seen them all discover that the scientific reasoning of plan-do-check-act (PDCA) embedded in the A3 process pays off. IT, banking, insurance, and other service industries have gotten incredible returns from the structured problem-solving of the A3 process. To think you can use the PDCA process only when looking at a pile of damaged raw material on a factory floor or a bottleneck in front of a painting department is wrong.
Act now to get off the technical debt treadmill by using A3 problem-solving to solve and document root causes … and allow the rapid pace of change of IT to retire obsolete systems and technical debt as time goes by.
But when teaching the A3 problem-solving process, the first thing I do — particularly in an IT company or department — is to start with a draft problem statement. We call it a draft because the statement is going to be refined. I never begin with the A3 form because people tend to think the objective is to fill out the form. It’s not. The A3 form is there to capture our thinking and learning. It’s not there as a compliance tool.
Often what I find is that IT professionals are very clear on the symptoms or pain points that they’re experiencing. Because they’re so knowledgeable on their platform, technology stack, or whatever project they’re working on, they tend to blend symptoms, problems, and solutions into a single problem statement.
But we know that effective A3 thinking is all about decomposing a problem. We must honestly ask if we really understand the problem. Can we clearly define it? Have we done a situation analysis to really know what’s going on? Do we have data? Do we clearly understand cause and effect? What’s the gap between where we are now and where we need to be? Often in IT, that’s a performance measure such as delivery time, the responsiveness of the service, or the time to restore service after an outage. All this information is captured on the left side of the A3 form.
But the type of problem-solving that most people are good at is “how do I minimize the damage of the current problem.” We call that firefighting: restore service, bring it back up, appease the customer. And that’s fine. We all need to firefight. But many organizations lack the rigor and the discipline to get to the root cause of the problem to prevent it from happening in the future.
Lingering IT Liabilities
The result of firefighting in IT is work-around, after work-around, after work-around. This results in what’s called technical debt. We firefight to fix a problem with a solution that is not healthy for the overall system. A good example would be to quickly create a temporary table, extract some data from one source, manipulate that data, stick it into another source and just write a little script to do this. It’s like putting patches on a leaky tire. Pretty soon, there are more patches than there is original tire.
Unfortunately, we have IT systems like that. Someone puts out a “fire” but there’s little to no documentation. If that person leaves, they leave with the knowledge of what they did. The A3 corrects this flawed process by getting to the root cause and documenting how we got there on the A3 form.
It’s always easier to create a little technical debt to just get rid of today’s problem. And it’s easier just to pay the interest on your credit card than paying down the principal. But in either case, sooner or later there is a reckoning.
I’ve heard many CIOs confess that it would take millions of dollars and 20 years to make a dent in their technical debt. So, they are forced to wait until things break. The trick is to act now to get off the technical debt treadmill by using A3 problem-solving to solve and document root causes. Stop creating more technical debt and allow the rapid pace of change of IT to retire obsolete systems and technical debt as time goes by.
People in IT work under incredible pressure; they have the proverbial gun to their collective head. They find it very refreshing when management creates some space to do rigorous PDCA by following the A3 problem-solving process. The reason is that PDCA requires presence and clarity of mind. It requires concentration. And it requires stopping the noise. You just can’t announce burning platform after burning platform then ask people, “Let’s be creative.” No one is that creative when they’ve got a gun to their head.
How to Keep Learning:
- Watch the free webinar by David, Beyond Problem-Solving: Other Facets of the A3 Process You Should Know and Practice.
- Read his answers to other follow-up questions from Beyond Problem-Solving webinar attendees:
- Get real-world case studies and a practical roadmap for applying lean principles to IT in the Lean IT Field Guide, co-authored by Mike Orzen.
Managing to Learn
An Introduction to A3 Leadership and Problem-Solving.
