"Sometimes," Bob mused, "It seems like senior management doesn't care about the quality of the systems we build. I wonder if they care about quality at all?"
"Oh, there is no question in my mind!" Sue assured him. "I know that they don't care. All they care about it hitting a schedule. They couldn't care less about how well the software works!"
Meanwhile, in the boardroom: "What's wrong with your people?" the COO barked at the CIO. "They can never seem to deliver a system the works right. Between the bugs that have to be fixed and the difficulty that people have with figuring out how to use it, I wonder if we might be better off using pencil and paper!"
Any executive will tell you that they want (no, they need) high-quality software systems. Yet from the vantage point of those of us who are tasked with building those systems, the opposite can seem to be true. Where is the disconnect and what can we do about it?
Talking About Quality
The disconnect about quality has its beginnings in the ways we talk about quality or in the ways that we fail to talk about it. Quality tends to be a fuzzy concept. We know that absolute perfection is not a reasonable target. So what should we try to achieve? Good? Better? Good enough?
This difficulty means that quality is not being discussed most of the time. Instead, we focus on things that we can talk about, such as product features, project activities, and delivery dates. If we talk about quality at all, we put the focus on the negative by reviewing bugs, deficiencies, and problems.
Because quality is not a topic of discussion, it tends to slip off of our radar screens. The things we do talk about must be what is important. Everything else (like what I had for lunch, the price of bottled water, and product quality) is relegated to interesting chitchat that doesn't really have a bearing on our project.
If it is true that the quality of what we deliver is important, then we must find a way to talk about it. Having a language for quality that is shared by both the development staff and senior management will allow us to start treating it as the important facet of our project that it is. We will then be able to agree about what we are trying to achieve quality-wise, what would be the impact of not achieving it, and what quality-related investments are appropriate.
A Language For Quality Objectives
Let's return to the questions we raised earlier: "If absolute perfection is not a reasonable target, then what should we be trying to achieve?" In order to answer this question, we need to have a way of understanding the COO's concerns. A statement about never delivering systems that work right doesn't give us insight into the nature of the deficiencies that are being referred to. References to bugs and figuring out how to use a system starts to point us into some potentially useful directions.
What about those bugs? Since perfection is out of the question, we expect that there will be at least some defects. Was it a matter of too many defects? If so, what is the definition of "too many"? If we talk with him (or with the managers who reported the problems to him), we will start to get some insight into the real issue. Perhaps this comment comes from the fact that on a recent release into production, the order entry (OE) system had so many problems that the OE staff's productivity was reduced by 25% during the two weeks it took to correct most of the problems.
By understanding what specifically was wrong that made this prior project fall short of expectations, we can begin talking about quality by using language that describes what sufficient quality actually means to the stakeholders. With this kind of understanding of the impact of a quality problem, we can instead turn it into a statement about what sufficient quality would have meant in that case.
Perhaps we could set a quality target of no more than a 15% productivity hit during the post-release shakeout period and ensure that productivity recovers in a week or