What Have We Learned?
Clearly, "quality" (unqualified) means different things to different people because it depends on their perspective. This in turn depends on a number of factors:
- In common usage "quality" may imply "of a superior nature", or it may refer to some notional scale such as from "poor" to "excellent".
- In business management "quality" may reflect on the cultural attitude of the organization ranging from minimal performance to pride of workmanship and ownership of the results.
- In reference to delivered products or services "quality" may refer to superior features or performance.
- In terms of project management, "quality" may refer to the degree of excellence in managing the project, or it may refer to the dedication of the workers producing the product, or it may refer to the superior features or performance of the project's end goal, i.e. the product. In the case of the latter, this may be reflected in the benefits to the sponsoring organization in the short term such as immediacy of competitive sales with an earlier break-even point. Or it may show up in long-term benefits through lower service and maintenance costs, and so on.
Thus, "quality" is an ambiguous term that needs careful qualification for any meaningful discussion.
But our specific interest is in the application of "quality" to project management. Here again we have a problem because, as reflected in the LinkedIn discussion, it depends on the type of project and the conditions under which it is being executed. For example, is the work being conducted under the owner/sponsor's direct supervision, or is it being conducted under contract? What are the priorities of the project: scope perfection, a deadline, or absolute budget value? And then, what is the environment in which the product or service is going to be used - is safety a priority for example?
In project management planning, obviously you first have to have some idea of what the outcome is that you are planning, i.e. the scope. But then you need to know the quality grade of that scope and sometimes the quality of the workmanship that will go into the product. In a global market, different cultures will produce different results. Only then can you realistically estimate the time to do the work and the consequential cost.
That's why we strongly believe that the so-called "knowledge areas" should be presented in that order: 1. Scope, 2. Quality, 3. Time and 4. Cost. While it may not be a big deal to some, by not assembling the subjects in that order in the PMBOK Guide, the Guide's authors do miss an important opportunity to make the point. That criticism is especially pertinent for those new to project management and are learning the discipline for the first time.
You can find a good illustration of the relationships between scope, quality, time and cost, as well as between product and project management in an opportunity/risk environment here: www.maxwideman.com/papers/conceptdraw/pro.htm.
We do not agree with those who insist that quality is automatically a part of scope and typically a "given". In practical specification documents, it may be convenient to include the quality requirements in with the scope description, but that quality is, nonetheless, subject to different degrees, meaning that it is a separate variable. Take a simple example like building a house. It may appear exactly like what the client wants, but it could be very well built, or it could be just well built, or worse, poorly built. These are three variations in quality and presumably the poorly built house will be cheaper. Hence, unless the project manager sees that quality is specifically and separately identified, the chances are that the outcome will be a poorly built house.
|
LinkedIn Discussion Group Views
