Priorities in repair

There are costs when you develop a product. One of the easiest to forget is the cost to repair it later. I don't mean when the customer breaks something by mis-using it; you can charge for repairs like that. I'm thinking of the ordinary cost of warranty repair. What happens when the product breaks down through normal wear and tear, inside the warranty period? Or in a product powered by software, what happens when the customer has an unexpected use-case, and discovers a brand-new bug?

You fix it, of course. All reputable companies do. But that costs time and money. In the high-tech case, it may require the attention of very talented engineers.

Long ago—and yes, it seems like it was in a galaxy far, far away—I worked for a startup that had a problem. We were developing a NewProduct™ that was late. It relied on a very specialized technology. The whole work rested on just one or two of our engineers.

To make things worse, we had recently released an OldProduct™ that relied on similar technology. When problems were reported, they were routed to the same engineers to fix. But every hour those engineers spent fixing a bug in the OldProduct was one more hour they weren't working on the NewProduct. So the NewProduct continued to get later.

One day, our President had had enough. In a moment of frustration, he fired off an email that said, "Effective immediately we will stop fixing bugs on OldProduct until NewProduct is released!" Clearly he hoped that this message would set the right priorities for the company, so that we could finally make some progress.

By coincidence, our annual ISO 9001 surveillance audit was scheduled for just a month later. And you can probably guess what happened. At one point the auditor asked me, "How do you respond to customer complaints?" In the course of the discussion, I mentioned the recent email about OldProduct.

Our auditor took a very dim view of this story. Had we really stopped fixing all bugs on OldProduct? He reminded me that clause 8.5.2 of ISO 9001:2000* specifically requires the organization to review nonconformities, including customer complaints. If we really had stopped fixing all reported bugs, he would have to write that up as a Major process nonconformity in the audit. 

I hadn't worked closely with this product, so I called the Customer Service Department. They explained that no, we hadn't stopped fixing bugs. When he sent that email, our President was just blowing off steam. What we had done in reality was to set up a filtering system to prioritize bug-fixing.

• If OldProduct genuinely didn't work, we fixed the problem.
• But if OldProduct actually did work, but just not the way the customer wanted it to work—this was by far the majority of the cases!—we took the customer's improvement suggestions and put them all in a big pool to be addressed when we had time. This meant we would look at them after NewProduct finally got released.

The Customer Service folks brought objective evidence to prove that yes, one or two bugs really had been addressed since President's email, so the filtering system was working. Our auditor downgraded his finding to a suggestion that it would be helpful if everyone in the organization had the same understanding about this policy, and the rest of the audit was uneventful.

This all took place long ago, but I remember it because the distinction is important. 

• On the one hand, there are things—like repairing genuine flaws under warranty—that you simply have to do: all responsible companies do them, and they are required by external standards like ISO 9001. 
• But on the other hand, you often have broad latitude to prioritize your work in a way that makes sense based on current conditions.

This flexibility can make all the difference. 

__________

* Yes, we were still working to the 2000 edition of the standard. Remember this was many years ago!