Introduction | Book Structure | What We Liked
Downside | Summary

What We Liked

Chapter 1 starts out by taking aim at the distinctions between portfolio, program, and project management. The authors suggest that while these terms are common in today's lexicon, "a clear, concise, and commonly accepted understanding of these concepts does not exist".[5] They suggest that the distinctions between them are blurred at best, partly because these concepts are broad and complex, especially at a time when solutions are desired quickly and simply.

The authors observe that in particular it is not easy to find a shared understanding of "what" program management is and, more critically, "how" to do it. They suggest that there are three main definitions:

1. Simply a large project [overseeing a collection of sub elements]
2. A group of interrelated projects [which amounts to more or less the same thing]
3. A composite of identifying and selecting major change initiatives, and seeing them realized.

Assuming the last definitions, then portfolio management is a matter of doing the right things, while the project context is a question of doing things right. Therefore, focusing on Program Management is the way to bridge between corporate strategy and project execution. That's all well and good, but that means a significant impact on the tools and techniques of each domain. This is illustrated by a Table comparing the different foci between Project, Program and Portfolio for such tools and techniques as Context, Scope, Change, Planning, and so on.[6]

However, this structure enables a series of initiatives with a broader life span, than is normally attributed to the management of a single project. For example:[7]

As an aside, what can we call this logical assembly of activities? The term "Project Management" is being used more and more to cover the whole domain of portfolio management to project management, notwithstanding that its "official" definition still refers to a single project. In any case, we suggest, as the authors advocate, the list shown above is more than (just) project management because it includes "Value Management" at the front end and "Operational Improvement" at the back end, neither of which are within the purview of the typical project manager.[8] In short, this broader life span represents a much more complete picture.

Incidentally, we really like the idea of the underpinning of a program by a program "Decision Case", just as projects should be underpinned by a project "Business Case"[9]. At the project level, the authors also emphasize the importance of a communication plan that necessarily starts out with a project vision because "it is the one guiding statement that brings people on board and allows them to maintain a consistent focus to their activities."[10]

So, back to the issue of "scope" and scope changes. Within the context just described, the authors observe:

"Scope is the high-level set of characteristics that defines the targeted solution. The target, however, can change as the understanding of the problem or strategy (or even alternative solutions) are analyzed by the various stakeholders."[11]

"In the past, nearly every change to scope was viewed as 'scope creep'. That is not the case. Scope creep occurs when the requirements, design, or development dictates or implements a feature that does not meet the objectives or the needs of the solution being produced. If, however, scope is changed as a result of the requirements, design, or development processes in order to meet the objectives and business needs, it is a valid evolution or fluctuation in scope."[12]

Later the authors state that:[13]

"The need to change from the original scope should not be seen as a negative, but actually a necessary, positive, and enabling reality."

In traditional project management terms, this is all part of the Concept and Feasibility phases of the project life span, so it is not surprising that the so-called "scope" is highly volatile. It is after the project has been formalized, i.e., a "contract" has been established with schedule and cost obligations, that changes to scope involving corresponding changes to time and cost commitments are both disruptive and costly. This is when such changes are likely to be labeled as scope creep, and if not scope creep, then certainly as "Clarifications".

Chapter 3, Stakeholder Engagement, tackles the difficult area of the "I'll tell you when I see it" brigade. Such groups are unavoidable because they simply do not have the background and experience to visualize the proposed product in the abstract. Moreover, they frequently do not like to admit this shortcoming. Interestingly, this discussion leads to a description of several different Types of Participation that a manager should be aware of in dealing with personality conflicts in the team. These types include The Non-Participant, The Heckler, and The Hijacker that are familiar to most meeting facilitators.[14]

Book Structure

Downside

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