Focused Improvement

Sam is a quality assurance engineer at a fictitious software company called Hilanderas. For the third time this year, Hilanderas has released a new software version only to have it fail at the same critical customer site. Senior management asks Sam to lead a tiger team to find a solution. Sam and his team visit the customer site, collect information about the problem, and analyze the data. They discover that the customer’s configuration is incompatible with some coding in the new software release, causing the mysterious system crashes. They realize that the customer's configuration was not tested during product verification. Sam works long hours with the developers to fix the problem. The customer is excited that the problem is now eliminated. Hilanderas rewards Sam for his successful efforts.

Six months later, another new release, another crash. This time, Sam realizes testing should routinely include simulations of the customer configuration. He defines a process for the test team to collect information on customer configurations for use during product verification. Sam feels good about solving the problem at hand and preventing it from happening again. The process is filed away in a very thick binder full of similar documents. Things return to normal.

Everything goes smoothly until Hilanderas releases yet another new version. Not surprisingly, the customer reports another crash. Yet again, Sam investigates and discovers the customer configuration has changed since the last release. Testing had not included these differences because no one followed the process Sam had developed for recording changes in customer configurations. By this time, Hilanderas is in considerable trouble with the customer. In the customer's eyes, Hilanderas continually releases software that crashes. The customer blames Hilanderas. Hilanderas blames Sam. How could Sam have saved his reputation? How can you keep this from happening to you—and your company?

Developing and Implementing Your Improvement Project
Sam’s immediate reaction to the problem was appropriate—get the customer online as soon as possible. All of his code changes eliminated the immediate crisis at the customer site. Sam's second reaction—try to prevent future flare-ups—was also on target. The process he developed to help testing keep track of customer configuration changes, however, was not a true solution. Even if testing had followed his process, it wouldn't have solved the underlying problem: the product architecture made the system overly dependent on configuration. Sam needed to uncover this buried root cause. To do this, Sam (and Hilanderas) needed a formal improvement project.

A formal improvement project is carried out by a team. This team searches for root causes, then proposes and implements a solution. The team should be headed by at least one change agent : an individual specifically tasked with process improvement and trained in identifying improvement opportunities and making changes. The remainder of the team should include individuals with knowledge of the problem and time available to work on the improvement project. If Hilanderas had had such a team in place, Sam could have reported the configuration problem to the change agent, joined the team (bringing his personal experience with the incompatibility issue with him), and worked to bring about real change. Instead of being blamed for failure, he would have been praised for helping to eliminate a large and costly software development mistake. Hilanderas would have avoided future cost and embarrassment from similar incompatibilities.

Figure 1 presents a template for developing your own improvement project. Use the finished template as a tool to justify the project, build consensus on the basic project parameters, set expectations on schedule and cost, provide tracking baselines, and list project goals and measurements.

The best improvement projects include