Does Senior Management Really Care About Quality?

"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. And yet from the vantage point of those of us who are tasked with building those systems, the opposite can seem to be true. Why the disconnect? And what can we do about it?

Talking About Quality

This disconnect about quality has its beginnings in the ways we talk about quality (or in the ways 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 be trying to achieve? "Good"? "Better"? "Good enough"?

This difficulty means that quality ends up not being talked about most of the time. Instead, we focus on things that we can talk about, like product features, project activities, and delivery dates. If we talk about quality at all, we focus on the negative, like bugs, deficiencies, and problems.

Because quality is not a topic of discussion, it slips 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 projects that it is. We will 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. His statement about "never" delivering systems that "work right" doesn't give us any insight into the nature of the deficiencies to which he is referring. His references to "bugs" and people "figuring out how to use" the systems start 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? And if so, what is his 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 sort of understanding of the impact of this quality problem, we can 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 ensuring that productivity recovers in a week or less. Sure, we would prefer no impacts at all. But given our past performance, 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 quality 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:

We could 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).
We could do some additional testing before release: possibly some Acceptance testing by actual End Users who will use it.
We could 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, so a request for a larger investment is not likely to be received well. But, if it is reframed as an investment that will avoid a significant quality problem that was experienced on prior projects, management will be able to more accurately weigh their options.

How much did those problems cost the company last time vs. how large an investment will avoid them this time? Cost vs. 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.