Article ReviewProject Management - Quality
Introduction
This paper sets out to review and analyze an article that offers definitions of and discusses the concept of quality in terms of project management. The subject article is entitled: “Some perspectives on quality” (2012), by Kailash Awati.
Article Summary:
The article opens with quoting two different dictionary definitions of the word “quality”, which – because they give no indication of how quality is measured – are dismissed by the author as inadequate. He quotes the PMBOK (Project Management Body Of Knowledge guide) definition of quality, which is: “the degree to which a set of inherent characteristics fulfil requirements”, stating that this definition is a more practical one from a project management perspective, as it provides a link between the term “quality” and the deliverables expectations of end-users. He also quotes the “PRINCE2” (PRojects IN Controlled Environments) (UK government standard) definition of quality as “fitness for purpose.”
But then Awati asks the very valid rhetorical question that although quality is an essential factor in project management, where the objective is to “deliver what’s agreed to, whilst working within the imposed constraints of resources and time”, is either of those two definitions really a measure of the quality of the deliverables?
In his view they confuse “quality” with merely fulfilling requirements. One can have something that is of the highest quality, yet does not fulfil the requirements. (For example, one might claim that Microsoft Word is a high quality word-processing software, but it would not be the tool of choice for project management). The question that then has to be asked is just how should we define quality in project management terms?
Awati quotes Robert Glass, author of “Facts and Fallacies of Software Engineering” (2003), who defines what it is not (Fact 47), as: “Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets or reliability.” Then Glass describes quality as “a set of product attributes”, perhaps including – in no special order of importance:
- Reliability: Does it function as intended?
- Useability: How easy is it to use?
- Modifiability: How easy is it to modify or maintain?
- Understandability: Can one easily understand the way it works?
- Efficiency: Does it use resources efficiently?
- Testability: How easy is it to test the product?
- Portability: (Software). Can it be used equally well on other platforms (if that is a requirement)?
Glass also notes that because these listed attributes are technical in nature, they should be the prerogative of those who design the products; i.e., not the project managers or even the end-users. (This writer would question that last point). In fact he suggests that the managers should simply let the technical people get on with it and to “get out of their way.”
Awati also quotes from a book co-written with Paul Culmsee “The Heretic’s Guide to Best Practices” (2011-2013), in which it is claimed that “quality cannot be an end in itself.” Awati suggests that depending on one’s role in connection with a project, the preferred definition of quality would vary. The better way to determine quality – according to that book – is to ask the question: “What difference would quality make to this project?” The point here is that each project is different and therefore that the ideal definition of quality appropriate to one project may not be the right definition for another project.
Awati also cites what he calls the short-sighted view of project managers considering the project duration as their timeframe, rarely considering the longer-term situation that prevails long after the project is completed. He uses the Sydney Opera House as an example. At the time it was conceived and created, over budget by a factor of fourteen and at least ten years late, the project was considered a dismal failure for those reasons. Yet over 40 years later it is a key Australian icon, recognized and admired around the world, making the project – in retrospect – a huge success. Awati sees this as validation that quality in project terms must also take into consideration the project’s legacy – how a project may be viewed in the years to come.
So, as Awati summarizes – and rightly so in the view of this reader of his article – the meaning of “quality” depends on its specific context and one’s perspective. The term quality can refer to:
- (According to PMBOK and PRINCE2): its “fitness for purpose” or whether it can “meet requirements”
- Taking a dictionary definition: “an essential attribute”
- Viewing quality as a process instead of the output of a project: “A means of achieving a particular end.”
Awati adds that none of these takes into account the legacy aspect mentioned earlier, and that essentially the definition must remain open to interpretation. He closes with an anonymous quotation: “What is good and what is not good, need we have anyone tell us these things?”
Overall, this is a thought-provoking article that attempts to challenge the accepted meaning of quality and to clarify our thinking and make us take a fresh look at what we really mean by quality in project management. Though Awati does not provide a definitive “one size fits all” answer, the article does question the validity of the so-called “iron triangle” (the cost, scope and timescale of a project) and encourages us to look at quality from different perspectives. Any project manager reading this article could well gain some advantage from considering Awati’s ideas and applying his analytical thinking to the project at hand.
References
Awati, Kailash. (Dec 2012). “Some perspectives on quality.” Eight to Late. Retrieved from http://eight2late.wordpress.com/2012/12/13/what-is-good-and-what-is-not-good-a-project-managers-further-ruminations-on-quality/
Culmsee, Paul & Awati, Kailash. (2011-2013). “The Heretic’s Guide to Best Practices.” iUniverse, Bloomington, Indiana 47403. Print.
Glass, Robert, L.. (2003). “Facts and Fallacies of Software Engineering.” Pearson Education Inc. Boston, MA. Print.
