November 2

The Quality of Quality

Scope, Time, and Cost are the three recognized core constraints of any project (known as the “triple constraint” or “PM triangle”). Quality is often included in a discussion of the triple constraint as either a 4th constraint or as a sort of holistic attribute of the product of a project (The typical graphic is of a triangle with each corner being scope, time, and cost, and the middle being quality – food for thought: as a model, wouldn’t it be more useful for scope to be the area of the triangle, with the other constraints being the lines that define it such that if one were to be shortened, the others would have to be lengthened to accommodate the same area/scope? But I digress).

The reason it is difficult to cement quality within a widely agreed upon framework of project management is that it is not generally clearly articulated just what quality is. And the reason for that is that quality does not have a fixed definition for all projects, nor, generally, even a fixed and explicit definition within each project. Time and cost are easy to define and measure. Scope clearly requires more effort to define, but once defined, the product of the project either has all of the attributes defined in the scope, or it does not (I’m simplifying somewhat, but bear with me). Some argue (as I argue with myself) that quality is either an attribute (or set of attributes) defined as part of the scope, or is a condition of the scope being adequately addressed (as in, if it does everything it was intended to, it meets the quality objective). However, when we talk about quality we typically mean the implicit characteristics of the product rather than those explicitly defined. For instance, when we build a house, we don’t generally stipulate that it should be weather tight and last more than 50-years, but we certainly would not label a home built without these attributes as quality. Likewise, software that is developed to solve a particular business challenge should be able to be maintained and adapted to change with reasonable efficiency.

Among other implicit attributes, what we generally mean by a quality product, then, is one that endures. What we output from our projects should not only satisfy the scope requirements initially, but continue to deliver the intended value over their expected service lifetimes. If endurance or longevity were always an explicit constraint, the cost and value of quality would be less ambiguous. If not as a fourth corner of our Project Management (PM) triangle, something along the lines of intended length of service should be addressed in every scope definition.

In any case, quality should not occupy the ambiguous middle of the triangle. In fact, as I explore this topic, I am becoming compelled by the idea presented in my digression in the first paragraph. Scope is that area bounded by time, cost, and some measure of implicit quality, which, as I’ve argued here, generally includes an expectation of durability. It requires less time and cost to build a throw-away version of the scope, and more time to build one that is likely to last. Notice that the measure of quality has an inverse relationship with the length of the line defining the edge of the triangle. An interesting by-product of this model is that the all-too-often stated constraint of perfect quality would be represented as a zero-length line, which means no amount of time nor resources will result in a triangle with sufficient area to accommodate any scope whatsoever (but again, I digress).

The next challenge I plan to explore: balancing time-to-implementation (value now) with quality (defined as endurance, or value over time).