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 less.  Of course, we would prefer no impacts at all. Given our past performance, though, jumping immediately to no post-release problems is not a reasonable expectation. If we make incremental improvements with each project, we may be able to achieve no impacts on release at some point in the future.

 

Translating Quality Language Into Actions
Having a way to talk about quality and agree on objectives provides the information we need to be able to do something about it. The example about post-release impacts above is not only a concrete statement of what better quality is, but it also gives us several clear options we can pursue in order to achieve it. For example:

 

·       Examine the types of problems that were discovered during the shakeout period and look for ways to avoid them in the future (e.g., better understanding of how the end users will use the system).

·       Do some additional testing before release: possibly some acceptance testing by actual end users who will use it.

·       Improve the problem correction process we use so that post-release problems are corrected more quickly.

None of these options comes for free, so this is where being able to discuss quality with senior management comes in. For example, the first bullet suggests making an investment in better requirements engineering. This would mean extra costs and time on the next project that would have to be approved by senior management. 

Since these sorts of projects are always overhead costs, management's first response is to keep costs as low as possible.  Because of this, a request for a larger investment is not likely to be received well. If it is reframed as an investment that will avoid a significant quality problem that was experienced on prior projects, though, management will be able to more accurately weigh their options.

 

How much did those problems cost the company last time versus how large an investment will avoid them this time? We must examine cost versus benefit, investment and ROI. When presented with a discussion of quality in these terms, management will be much better prepared to understand the issues and to make appropriate decisions.

 

Yes, senior management does care about quality, but it is not quality for quality's sake. Rather, they care about the costs associated with achieving quality and the penalties that accrue from missing the quality mark. Having a language that allows us to discuss quality in these terms will allow us to make the appropriate investments to achieve the levels of quality that we need.