Introduction | Book Structure | What We Liked: Content
What We Liked: WBS & PMO | Downside | Summary

Downside

We do have some quibbles.

For example, planning a project should be at the heart of sound project management. In this regard, Jolyon states that: "Planning a projects consists of the following fifteen activities:"[11] and then provides a list that starts out with: "1. Defining project risks and identifying actions to mitigate them." Of course, this presumes that the goals, objectives and scope of the project have already been determined, a subject dealt with in Section 3.

But there is a broader issue. What activities does the planning of a project truly consist of? Jolyon lists 15 in somewhat random order. The Institute's PMBOK Guide, under the heading "Develop Project Management Plan" also lists fifteen items as subsidiary plans.[12] The problem with both these lists is that they contain items that are subsidiary to other items in the list. In other words, in project management, many important activities are naturally nested within broader activities. So, might not the first order of business be the development of a product breakdown structure (typically but incorrectly termed WBS) with its logical sequences or relationships?

In our view, a good project management plan should address each of the eight knowledge areas of the Institute's PMBOK at a level and detail appropriate to the project at hand. That means that there are up to eight subsidiary plans, calling for just eight broad planning activities - period. The rest are simply elaborations of the first to the extent necessary for manageability, as explained under Work Breakdown Structure discussed earlier!

Jolyon also states that:

"To define a project, you must define, document, and gain client approval for two things: the deliverables and the scope."[13]

Later he says:

"In preparing a scope statement, remember that there are two types of scope: the scope of the product and the scope of the project. The scope of the product defines the work that the project will carry out, the scope of the project defines how the work will be executed."[14]

Well, almost. Certainly, there has been much confusion over the years as to the meaning of "scope" and equally certainly there are two types of scope, i.e. product scope and project scope. However, the project management Institute, in its 2000 edition PMBoK Glossary made the distinction between the two as follows: Project Scope is the work involved while Product Scope represents the end products. It is true that only when you know the extent of the Product Scope, i.e. the deliverables, can you determine how much work is involved, but we prefer to think of the extent of that work as the Scope of Work - yet another term.[15]

In discussing Scope Change Mechanisms, Jolyon says that: "Regardless of how conscientiously you define scope, it will change, which means you need a mechanism for managing it."[16] He then goes on to describe that mechanism. In our view, what is missing here is any mention of a "Scope Baseline" against which comparison can be drawn to determine whether or not there has been a change in scope.

Jolyon states categorically that:

"Advocates of many SDLCs [System Development Life Cycles] refer to their approaches as 'methodologies.' This is incorrect. A methodology is a specific set of processes to prepare a set of deliverables."[17]

We can well imagine people getting hot under the collar over this one. But in truth, an SDLC is no more than a particular sequence of activities, i.e. a "process". A "methodology" is also a particular sequence of activities, i.e. a "process". Ergo, an SDLC is a methodology - more or less. The difference is purely a matter of semantics.

Jolyon declares that:

"Consulting services and training can be major expense items that can sometimes be trimmed by finding lower-cost alternatives. Some of these services may be available in-house, and the rates will be far lower than outside organizations will charge."[18]

In our view, if such resources exist in-house and, of course, are available, then obviously use them. However, don't be misled by the apparent higher charge-out rates of external consultants. Internal hourly rates rarely include for down time, lost time, proposal preparation time and so on that is lost elsewhere in the corporate accounting system. In other words, the apparent saving to the organization shows up only in the project's records.

Our biggest beef has to do with a "Project Management Roadmap"[19] that introduces the main sections throughout the book. It consists of boxes representing these main sections, namely: Understanding the Project; Defining the Project; Planning the Project; and Running the Project. This looks to us like an unfinished project life span, so it would be nice to see the last few subsections of the book hived off under a final main heading along the lines of "Finishing the Project".

Considering that the success of any project depends heavily on how well the product is transferred into the "care, custody and control" of the users, this, and all that it implies, is an essential final step. Perhaps in the next edition of the book this omission can be rectified and a little more of Jolyon's experience added as to how best to conduct this vital transfer phase.

What We Liked - WBS & PMO

Summary

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