Eight to Late

Sensemaking and Analytics for Organizations

Posts Tagged ‘Quality

Some perspectives on quality

with 7 comments


A couple of years ago, I wrote a post entitled, A project manager’s ruminations on quality, in which I discussed meaning of the term quality as it pertains to project work. In that article I focused on how the standard project management definition of quality differs from the usual (dictionary) meaning of the term. Below, I expand on that post by presenting some alternate perspectives on quality.

Quality in mainstream project management

Let’s begin with a couple of  dictionary definitions of quality to see how useful they are from a project management perspective:

  1. An essential or distinctive characteristic, property, or attribute.
  2. High grade; superiority; excellence

Clearly, these aren’t much help because they don’t tell us how to measure quality. Moreover, the second definition confuses quality and grade – two terms that the PMBOK assures us are as different as chalk and cheese.

So what is a good definition of quality from the perspective of a project manager? The PMBOK, quoting from the American Society for Quality (ASQ), defines quality as, “the degree to which a set of inherent characteristics fulfil requirements.”  This is clearly a much more practical definition for a project manager, as it links the notion of quality to what the end-user expects from deliverables. PRINCE2, similarly, keeps the end-user firmly in focus when it defines quality, rather informally, as, fitness for purpose.”

Project managers steeped in PRINCE and other methodologies would probably find the above unexceptional. The end-goal in project management is to deliver what’s agreed to, whilst working within the imposed constraints of resources and time.  It is therefore no surprise that the definition of quality focuses on the characteristics of the deliverables, as they are specified in the project requirements.

Quality as an essential characteristic

The foregoing project management definitions beg the question:

Is “fitness of purpose” or the “degree to which product characteristics fulfils requirements” really a measure of quality?

The problem with these definitions is that they conflate quality with fulfilling requirements. But surely there is more to it than that. An easy way to see this is that one can have a high quality product that does not satisfy user requirements or meet cost and schedule targets. For example, many  people would agree that WordPress blogging software is of a high quality, yet it does not meet the requirement of, say, “a tool to manage projects.”

Indeed, Robert Glass states this plainly in his book, Facts and Fallacies of Software Engineering. Fact 47 in the book goes as follows:

Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets or reliability.

So what is quality, then?

According to Glass quality is a set of (product) attributes, including things such as:

  1. Reliability – does the product work as it should?
  2. Useability – is it easy to use?
  3. Modifiability – can it be modified (maintained) easily?
  4. Understandability – is it easy to understand how it works?
  5. Efficiency – does it make efficient use of resources (including storage, computing power and time)?
  6. Testability – can it be tested easily?
  7. Portability – can it be ported to other platforms?  This isn’t an issue for all products – some programs need run only on one operating system.

Note that the above listing is not in order of importance. For some products useability maybe more important than efficiency, in others it could be the opposite – the order depends very much on the product and its applications.

Glass notes that these attributes are highly technical. Consequently, they are best dealt with by people who are directly involved in creating the product, not their managers, not even the customers. In this view, the responsibility for quality lies not with project managers, but with those who do the work. To quote from the book:

…quality is one of the most deeply technical issues in the software field. Management’s job, far from taking responsibility for achieving quality, is to facilitate and enable technical people and the get out of their way.

Another point to note is that the above characteristics are indeed measurable (if only in a qualitative sense), which addresses the objection I noted at in the previous section.

Quality as a means to an end

In our book, The Heretic’s Guide to Best Practices, Paul Culmsee and I discuss a couple of perspectives on quality which I summarise in this and the following section.

Our first contention is that quality cannot be an end in itself.  This is a subtle point so I’ll illustrate with an example. Consider the two  “ends-focused” definitions of quality mentioned earlier: quality as “fitness for purpose” and quality as a set of objective attributes. Chances are that different project  stakeholders will have differing views on which definition is “right”. The problem, as we have seen in the earlier sections, is that the two definitions are not the same.  Hence quality cannot be an end in itself.

Instead, we believe that a better definition comes from asking the question: “What difference would quality make to this project?” The answer determines an appropriate definition of quality for a particular project.  Implicit here is the notion of quality as an enabler to achieve the desired project objective. In other words, quality here is a means to an end, not an end in itself.

Quality and time

Typically, project deliverables – be they software or buildings or anything else – have lifetimes that are much longer than the duration of the project itself. There are a couple of important implications of this:

  1. Deliverables may be used in ways that were not considered when the project was implemented.
  2. They may have side effects that were not foreseen.

Rarely, if ever, do project teams worry about the long term consequences of their creations.  Their time horizons are limited to the duration of their projects. This myopic view is perpetuated by the so called iron triangle which tells us that quality is a function of cost, scope and time (i.e. duration) of a project.

The best way to see the short-sightedness of this view is through an example.  Consider the Sydney Opera House as an example of a project output. As we state in our book:

It is a global icon and there are people who come to Sydney just to see it. In term of economic significance to Sydney, it is priceless andi rreplaceable. The architect who designed it, Jørn Utzon, was awarded the Pritzker Prize (architecture’s highest honour) for it in 2003.

But the million dollar question is . . . “Was it a successful project?” If one was to ask one of the two million annual tourists who visit the place, we suspect that the answer would be an emphatic “Yes.” Yet, when we judge the project through the lens of the “iron triangle,” the view changes significantly. To understand why, consider these fun filled facts about the Sydney Opera House.

  • The Opera House was formally completed in 1973, having cost $102 million
  • The original cost estimate in 1957 was $7 million
  • The original completion date set by the government was 1963
  • Thus, the project was completed ten years late and over-budget by more than a factor of fourteen

If that wasn’t bad enough, Utzon, the designer of the opera house, never lived to set foot in it. He left Australia in disgust, swearing never to come back after his abilities had been called into question and payments suspended. When the Opera House was opened in 1973 by Queen Elizabeth II, Utzon was not invited to the ceremony, nor was his name mentioned…

Judged by the criteria of the iron triangle, the project was an abject failure. However, judged by through the lens of time, the project is an epic success! Quality must therefore also be viewed in terms of the legacy that the project leaves – how the deliverables will be viewed by future generations and what it will mean to them.

Wrapping up

As we have seen, the issue of quality is a vexed one because how one understands it  depends on which school of thought one subscribes to. We have seen that quality can refer to one of the following:

  1. The “fitness for purpose” of a product or its ability to “meet requirements.” (Source: PRINCE2 and PMBOK)
  2. An essential attribute of a product. This is based on the standard, dictionary definition of the term.
  3. A means of achieving a particular end.  Here quality is viewed as a  process rather than a project output.

Moreover, none of the above perspectives considers the  legacy bequeathed by a project;  how the deliverables will perceived by future  generations.

So where does that leave us?

Perhaps it is  best to leave definitions of quality to pedants, for as someone wise once said, “What is good and what is not good, need we have anyone tell us these things?”

Written by K

December 13, 2012 at 2:35 am

%d bloggers like this: