This is a 7 minute read that summarizes the author’s frustrations with today’s approach to quality and proposes a model that characterizes quality as an inherent attribute rather than an add-on.
I was half-way through my career before I woke up to the fact that I didn’t know what quality was. Any quality our projects enjoyed was attributable to a good team and perhaps a bit of that rare commodity, common sense. I was in good company – Robert Pirsig, in his 1970’s cult classic Zen and the Art of Motorcycle Maintenance, concluded that quality cannot be defined. Henry Ford declared quality to be doing it right even when nobody was looking. And Mr. and Mrs. Consumer just recognized quality when they saw it!
Rant
The world currently does not seem receptive to quality. Misspellings proliferate even in the established media. Profanity is ubiquitous as it meets no resistance. Grammar is ignored, often to the point of unintelligibility. The skill of objective argument to get to the truth of a matter is in decline. The concept of checking and double-checking to ensure the validity of a fact or statement is derided.
The notion that precedent human endeavour, over previous years or possibly centuries, retains some usefulness in addressing today’s problems is discarded. Safe driving is seen as secondary to keeping up with the smartphone! Oh, and jeans are worn with rips not through poverty but in thrall to delusory fashion. This is the backdrop to our cultural malaise and, just as people take their cues from the behaviour of leaders, so do projects reflect the culture in which they execute.
Never, never, never give up
OK, now I’ve got that off my chest! The point is that in addition to the considerable difficulties of defining and managing quality, project managers (PMs) must also deal with antipathetic societal conditions. Quality is misunderstood, tough to define, subject to ‘sloganeering’ by management, a victim of lip service, and its demands for discipline and process are unpopular.
There’s been a game played over the past 30 years that goes like this: is quality describable using inherent characteristics and is therefore objective, or is it subjective, only existing in the eye of the customer? Of the many methodologies that have bloomed and mostly withered during this time period, two persist and represent each part of the game – ISO9000 and Customer Satisfaction. (I characterize prevalent corporate implementations of Six Sigma as a statistical approach to ensuring the application of ISO9000 or similar processes.)
Incidentally, an unanticipated effect of the corporate ownership of quality initiatives such as ISO and Six Sigma is that it disempowers the PM. Quality gradually comes to be seen as something imposed, and ultimately the responsibility of a project outsider.
Having worked with both objective and subjective approaches for decades and striving to make sense of the conundrum, I have reached a verdict: subjective customer assessment can be a valid approach, but it is not quality. It is something else. Quality has to be intrinsic, measurable, and capable of meeting a quality specification and budget trade-off. Anything else leads to a multi-dimensional view that makes definition even more painful, removes any hope of clarity, and enables ‘window dressing’ and posturing.
So now PMs are on the hook. We can’t declare that fickle customer satisfaction is proof of quality. We can’t presume quality occurs when generic off-the-shelf quality methods are installed. Sorry, it is not that easy – but don’t give up. When quality is clearly accepted as an inherent feature of the product, then the logical approach – setting the requirements, design, and implementation of quality factors – can be part of the project design with huge gains in efficiency.
Dispelling the myths
To help get on top of this, it is very important to understand that PMs are actually faced with two distinct quality dialogues. The first concerns the quality of the product; second, the quality of the project. The myth of today’s thinking on quality is that project quality, currently interpreted as ‘just follow the process’, and expensive Six Sigma or ISO9000 at the corporate level, will automatically lead to the desired product quality. I call this the faith-based approach to quality, in which quality is not interpreted as inherent in the development of the product, but defined as an add-on, second-order, supportive QA/QC process. Support is important – I am not saying dispense with your QC procedures – but many procedures only cut-in when the product is already built. That’s a bit late, isn’t it?
A fresh view of quality
Quality is not a sprinkle of fairy dust. The endgame, namely a product that exactly meets functional and quality specifications, and the means to the end (the project activities) deserve a lot more attention. These two aspects should be a natural, or inherent, part of our project design.
1 The first aspect of product quality means that the product possesses discernible, tangible and measurable quality factors. As a simple example of how quality factors are developed from subjective needs, let’s assume the client stated that he wanted a ‘robust’ system. Discussion then established reliability as a quality objective. Using one of the techniques described in ‘Commercial Project Management – A Guide for Selling and Delivering Professional Services’ summarized here, we worked with the client to quantify this objective in terms of Mean Time Between Failure, for example. Experts from the project team are now needed to establish the quality factors that will achieve this objective. One factor might be the need for specific critical components to be redundant. Conclusion:
Product quality is the degree to which quality factors that serve objectives are incorporated into the product.
2 The second aspect, intrinsic project quality, means that the activities to design and implement the product quality factors are automatically included, and these activities are done well. A colloquial expression might be ‘doing the right thing and doing it right’. Project quality ensures product quality is coming into being and activities are being performed to a specified standard. The feedback is immediate – no waiting for the test phase. Changes are naturally controllable through the normal change control system. And there are no out-of-the-ordinary expenses being added to existing project costs. Conclusion:
Project quality is the degree to which activities create the product quality factors, coupled with the quality of the specified activities as measured against an accepted standard.
Completing the definition
But what about features, customer appeal, value for money, exceeding expectations, and all that other complicated, multi-dimensional subjective stuff we have been told means quality? Though I contend that much of this is something other than product quality, there is an evident need for the product to meet general customer requirements. That must be addressed, perhaps by a reference to Deming’s ‘fit for purpose’ quality goal.
Adding this to our conclusions on quality leads to my proposal for a more useful and specific definition of quality that should provide more guidance to PMs than is found in the PMBOK Guide. Here is my proposed definition:
“Product quality is the degree to which quality factors proven by analysis are incorporated into the product through the natural development and application of project activities based on a quality reference model, and thus the extent to which the product meets its purpose”.
Project and quality models
Now we are left with the need to explain the quality reference model! This concept allows for more freedom in activity design than sticking with the notion of a standard. As this post is really a back-to-basics analysis, the best approach is to first re-establish a basic project model, one that captures the elements of a project under the control of the PM. If these elements represent the essence of a project, then the PM’s job during project design is to deploy techniques and methods to ensure they carry the attributes of quality, and will meet product quality objectives. The quality reference model would then be designed to support this.
To start, what project model should we use?
The problem is that the triple constraint model is too simple, and the PMBOK and PRINCE2 models are too complex. What I suggest is a modest enhancement to the triple constraint that gives us a platform for the analysis of intrinsic project quality and acknowledges the goal of product quality. Thus, the new project model substitutes Scope with Objectives, Deliverables, and Activities. Trade-offs are added explicitly, to keep the model in balance.
Does this represent the essence of projects? Well, a good test is to ask the analyst’s three favourite questions: Why? What? and How? The generic answer from most experienced PMs would be something like: “The project must meet objectives through the development of deliverables created by the activity of the team.” This statement clearly identifies the significance of objectives (product quality and all others), deliverables, and activities. If these are our project essentials, possessing a naturalness of belonging, then we can speculate that project quality is achieved when each element possesses the attributes of quality – and is complete and correct.
The takeaway
The emphasis must move away from add-on processes that attempt to create quality retrospectively, to firstly, a renewed effort to identify product quality factors, and secondly, to an improvement in activities that deal with the essential elements of a project. These elements are identified in a basic project model, whose inherent quality can be specified using a quality reference model. The elements in the basic project model are:
Objectives: The specification of project objectives, and especially product quality objectives, is a foundation for quality results. They must be tangible and support the client’s goal. Weaknesses to be surmounted are a tendency to specify in subjective terms, and the lack of good analytic tools to assist the vendor and client develop a correct set of relevant product quality factors.
Deliverables: Quality depends on completeness, an understanding of the deliverable’s purpose and how it supports the objectives, and careful attention to protocols for approvals. In my experience it is rare for a client to properly fulfill this transactional role. There must be an equality of obligation and responsibility on both parties for development and approval of deliverables. The concept of quality is purposeless without the role of a customer who has explicitly (or implicitly) specified the requirements.
Activities: Quality is often viewed retrospectively by PMs using QC techniques, with insufficient attention given to efficiency and the complete creation of deliverables. A major area of improvement for PMs during up-front project design is to work more diligently with the team to specify their activities and optimize execution prior to starting.
Trade-offs: Again, a good quality trade-off procedure is a rarity. Clients are indoctrinated with ‘faster, cheaper, better’, and see no need for trade-off. Vendors, unfortunately, adjust surreptitiously, or more likely let the situation ride until something breaks. Inevitably this provides a worse result than if trade-off negotiations were conducted earlier, allowing for proper project planning.
Do you believe that PMs have lost control of project quality and are failing to provide leadership? Unfortunately, in situations where quality systems have been imposed, control has been taken out of the PM’s hands and a feeling of disempowerment may prevail. But as project managers, we have no choice but to lead on quality. It is our job.
The ideas in this post can help re-establish accountability for quality with the PM, which is where it belongs. In a future post I will expand on tasks, techniques and methods that ensure elements in the basic project model carry the attributes of quality, contributing to the development of a project quality reference model.
