Eight to Late

Sensemaking and Analytics for Organizations

Some perspectives on quality

with 7 comments

Introduction

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

7 Responses

Subscribe to comments with RSS.

  1. Please go read Gilb.

    Like

    flowchainsensei

    December 13, 2012 at 2:37 am

    • Hi Flowchainsensei,

      Thanks for taking the time to read and comment. Do you have any particular recommendations for reading?

      Regards,

      Kailash.

      Like

      K

      December 13, 2012 at 3:19 am

      • I suggest “Principles of Software Engineering Management” for starters, then maybe “Competitive Engineering”. #books #recommended

        Cheers
        Bob

        Like

        flowchainsensei

        December 13, 2012 at 4:07 pm

        • Hi Bob,

          Many thanks for the references. The point I’m trying to make, however, is that there are many different perspectives on quality in management theory and practice. An awareness of some of these may help managers take a more open view of what quality means in their day to day work and how they might work towards achieving it.

          Regards,

          Kailash.

          Like

          K

          December 14, 2012 at 7:46 pm

  2. 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.

    I think I have an issue with ‘…not even the customers’ – apart from being a very elitist view, you may not make any money or work again if you do ignore the customer’s perception of quality.

    “What is good and what is not good, need we have anyone tell us these things?”

    I am sorry, but we have to, again and again!!!

    Like

    Ravin Kurian

    December 13, 2012 at 8:59 am

    • Hi Ravin,

      Thanks for reading and for rightly taking me to task on this point. Just to clarify, I’m sure Glass does not mean to suggest that customers should not have any input into what constitutes a quality product (…and I certainly did not intend to imply that either). The point is that quality (at least in the case of software) has highly technical elements that are best dealt with by people who are directly involved in making the product. That said, my wording could have been a lot better….:-(

      The quote is more an expression of the futility of trying to come up with a universal definition of quality than anything else.

      Thanks again for taking the time to read and comment.

      Regards,

      Kailash.

      Like

      K

      December 13, 2012 at 10:46 am

      • I think the issue may be a misunderstanding or project quality versus product quality. There is an important distinction that must be made concerning the difference between quality in a project and quality in a product. For the purposes of this comment, assume anything software development related is a project (since software never really exists as anything more than a bundle of electrons) and not necessarily a product; by product, I am speaking of something that you make that has a physical component (that statement is intended to include things like designs for parts). Project quality applies to the work done to complete the project, whereas product quality applies to the attributes of the product upon its fabrication to a set of requirements (developed by a project!).

        For an example of product quality, as a product is manufactured, the following questions can be asked:
        Was this product built according to the specification requirements determining how to build it?
        Was this product built according to the dimensional requirements governing what to build?

        For an example of project quality (which you speak of above), the following questions should be asked before manufacture ever begins:
        Are these specifications written in such a manner to allow simple manufacturing?
        Are the drawings/models/specifications/etc governing this part meeting the requirements mentioned above (from Glass)

        Project quality leads to an easier time of achieving product quality, but in no way guarantees product quality. Of course, if Glass’s requirements are ignored during the knowledge-work taking place during the project, achieving product quality may still be possible, but maintaining product quality will become ever more difficult as time goes on and changes are required, enhancements are desired, etc.

        As for the bit concenring customer involvement, I totally agree for project quality (never let a business man tell you what makes good design!); however, for product quality, customer involvement is, of course, required as much as possible throughout the product lifecycle (otherwise, how will you know changes are required, enhancements are desired, etc).

        The problem I’ve noticed (I work in manufacturing, if you couldn’t tell), is that the product quality definition of “conforming to requirements” is too often applied to project work, to the detriment of the project. This problem is made worse by the fact that certain aspects of the project work, such as modelling practices for engineers to follow, can be measured based on whether or not the requirements were met.

        It is difficult, then, to ensure people remember that hard requirements that can be measured against cannot be developed concerning the process by which the engineer developes the design for the part in the first place.

        Like

        Chris

        January 5, 2013 at 1:29 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: