PART 2 | Recap
Section III - The Project Management Knowledge Areas
What We Liked | Downside -1 -2 -3 | Summary

Section III - The Project Management Knowledge Areas

Downside, 2/3
Comments on Chapter 5: Scope and Chapter 8: Quality

In Chapter 5, the biggest problem continues to be with articulating an effective understanding of Project Scope Management. To start with the Guide provides three distinct entities as follows:

• "Scope" (on its own) is defined as "The sum of the products, services, and results to be provided as a project. See also project scope and product scope."[27]
• "Project Scope" is defined as "The work that must be performed to deliver a product, service, or result with the specified features and functions."[28]
• "Product Scope" is defined as "The features and functions that characterize a product, service or result."[29]

To recap, "scope" (on its own) is the deliverable. "Product scope" is the "features and functions" of the deliverable, and "project scope" is the work that must be done to create the deliverable. These are three separate and valuable concepts. But then there are further definitions:

• "Statement of Work (SOW)" is defined as "A narrative description of products, services, or results to be supplied"[30] i.e. the deliverable.
• "Work" is defined as "Sustained physical or mental effort, exertion, or exercise of skill to overcome obstacles and achieve an objective."
• "Deliverable" is defined as "Any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project."[31]
• "Product scope description" is defined as "The documented narrative description of the product scope."[32]
• "Project scope statement" on the other hand "describes, in detail, the project's deliverables and the work required to create those deliverables."[33]

Not necessarily the fault of the Guide, but as a standard, Statement of Work (SOW) appears to be a misnomer since "work" is part of the project scope, i.e. "the work", rather than "scope" as in "products, services, and results". In any case, and at least in some industries, "SOW stand for "scope of work" rather than "statement of work" even though it too is misused. "Product scope description" is evidently a description of the "features and functions" of the deliverable. A legitimate question in all this is: Can the description of the product or service be separated from a description of its functionality and from the work attributable to either one, and does it matter? In our view it can, and it does.

This becomes self-evident when we see that subsection 5.4, "Scope Verification" is characterized as "formalizing acceptance of the completed project deliverables", while subsection 5.5 "Scope Control" is characterized as "controlling changes to the project scope", i.e. the work.[34] The project manager's dilemma is further compounded by the fact that a change to the "scope" and/or "product scope" and/or "project scope", all as defined above, are all handled by the Guide's Integrated Change Control, a "process performed from project inception through completion."[35] However, changes to the work may be necessary to correct variances-from-plan in the progress of the project, which is the responsibility of the project's management. Changes in the "scope" and/or "product scope", on the other hand, are most likely the subject of a change requiring formal approval under the authority of the project's sponsor, with concomitant changes to schedule and budget.

Especially where work is being done under contract, these are two very different processes. In our view, this chapter of the Guide requires more work. Definitions are required that clearly separate the conceptual goals and objectives of the project, justified in the project's original Project Business Case approved for initiation; the names of the deliverables, stated in the Project Charter; the features and functions of each of those deliverables, as described in the Product Scope Statement; and the work required to create all of that, as described in the Project Scope of Work for execution.

Chapter 8 deals with Project Quality Management. In Part 1, under Missed Opportunities, we criticized the sequence in which the knowledge area chapters are presented. The saddest part is that "Quality Management" appears like an orphan after chapters 5, 6, and 7 covering the subjects of scope, time and cost respectively. As we observed in Part 1, "quality" ultimately transcends all else, whether in terms of performance, productivity, or final product. Who will remember that last year's project was late and over budget? That's all lost in last year's financial statements. It is the quality of the product that endures throughout the product's life.

No, the proper place for the subject of quality is immediately after scope. Why? Because in the logical sequence of the four "core" knowledge areas, i.e. scope, quality, time and cost:

• You cannot reliably estimate the "cost" of a project until you know the pace of (i.e. "time") for its production.
• You cannot reliable estimate the durations of the work activities until you know the "quality" grade to be produced by those activities, i.e. how much effort will be required, and
• You cannot discuss those quality grades until you know the "scope" i.e. the deliverables that you are going to produce in the first place.

Hence, the logical planning evolutionary sequence of first "scope", then "quality", then "time" and finally "cost".

This positioning would not only emphasize the importance of quality in the management of a project but that it, like the other three, requires a baseline of reference against which it can be managed. That baseline is the quality "grade" so briefly mentioned in Chapter 8,[36] and not mentioned anywhere else in the Guide except the Glossary.[37] How can you Perform Quality Assurance[38] unless you know the quality grade requirements that you are trying to meet, i.e. conform to?

Few people seem to have latched onto this fundamental concept for project quality management. The text and diagrams in Chapter 8 might have been simplified had this been recognized. Incidentally, neither "conformance to requirements", nor "fitness for use"[39] nor "Quality Baseline"[40] is defined in the Glossary.

Section III - Downside, 1/3

Section III - Downside continued, 3/3

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page