The views expressed in this article are strictly those of Max Wideman.
The contents of the book under review are the copyright property of the author.
Published here February 2015

PART 1 | What We Liked – Part 3: Reconstructing Project Management
Downside | Summary


Earlier we noted Peter Morris's remarks that in contrast to PMI's PMBoK:[8]

"The APM based its Body of Knowledge not on the knowledge that is 'unique to project management' but on what you need to know in order to manage projects successfully. In practical terms, it considered the PMBOK® Guide misguided in its omission of the front end and too narrow in its definition of the subject. APM thus produced a broader document which followed the 'management of projects' model, recognizing topics such as objectives, strategy, technology, environment, people, business and commercial issues, and so on."

And concluded that:

"The model of project management represented by the PMBOK® Guide is one essentially of delivery execution: one where the requirements have at most to be 'collected'; where the cost, schedule, scope and other targets have already been set. The ethos of the discipline is then to 'monitor and control', not to actively shape and drive solutions."

There are several observations that we can make about Peter's position:

  1. PMI's focus is on the knowledge required of the project manager and the corresponding body of knowledge thus required. True, this is narrow, but then the reality of the market place is that project managers, whether in-house or external are contracted to deliver whatever has been decreed. Thus, the responsibility of the project manager is to be satisfied that what has been decreed, together with any constraining terms, is in fact realistic and doable. It is not the responsibility of the project manager to invent the project in the first place – unless specifically directed – which would be unusual. There are others much more qualified.
  2. Nevertheless, project management as thus contained is much more than just the start of "digging the hole for the foundations". There are typically one or more phases, albeit late in Peter's so-called "front end", which are indeed the responsibility of the project manager. For example, setting up for the project execution (initiating), and preparing a (detailed) plan (of the work to be done, together with mobilizing the team, procurement arrangements, pre-ordering, logistics, administration and so on.)
  3. Unfortunately, we did not find a satisfactory definition of Peter's "front-end", but if we had we would expect it to cover all of that period of time in the (overall) life span of a project that occurs upstream of the afore mentioned activities.[9] That is not to say that "front-end" work is not important, it is – desperately so – as Peter goes to great lengths to emphasize. It is just not the kind of work suited to the skills of the average project manager. Business analysts, for example, are better qualified to fill this gap further upstream, see Figure 1.
Figure 1: Roles in the management of projects
Figure 1: Roles in the management of projects[10]
  1. So while PMI's position may be viewed as strictly limited, in contrast, APM's recognition of such topics as " objectives, strategy, technology, environment, people, business and commercial issues, and so on" smacks of everything to everyone. In our view, this is equally an untenable position in practice. Can you really satisfactorily certify an individual on such a compass?
  2. Further, while the shortcomings of the PMBOK® Guide are clearly evident, nevertheless, PMI was the first to attempt the institutionalization of the domain of project management. And in so doing, they faced at the time, considerable pressure to avoid trespassing on any of the knowledge domains claimed, and hotly defended, by "other professions". By adopting the stance of "unique to project management", they had the perfect defense.
  3. There is another fundamental that we feel is missing from Peter's extensive repertoire. That is a clear distinction between "project management as the work of managing the project according to the given terms of governance imposed by the-next-level-up in the corporate hierarchy" and "technology management, the work of actually creating the envisioned product." In the real world, this distinction is frequently evident by the assignment of "project/product" responsibility to two people acting in concert. That is, a project manager, expert in managing projects and a technical manager, who is a subject matter expert (SME) in the technology vested in the product to be delivered.[11]
  4. While the two, "the work of managing the project" and "the work of creating the product", are practically inseparable, nevertheless, their separate distinction and study would eliminate a lot of the conflict in the discussions on both topics.

Look at it this way. The study of the heart in humans is quite separate from the study of the brain. Yet, in real life, neither will perform without the other, and the interaction between the two is not always exactly clear.

What We Liked – Part 3: Reconstructing Project Management  What We Liked – Part 3:
Reconstructing Project Management

8. Ibid, p61
9. Peter does provide three possible definitions of "Front-End", p164, but these do not cover the very original formulation of the project's "Concept" (his Figure 11.1). These costs, if captured, are also capitalized when the project goes into service. But if the project is aborted, these costs form part of corporate overheads.
10. Peter Morris's Figure 11.1
11. Peter does raise the question of how involved project management needs to be in managing the technical development of a project, p167, but tends to avoid a definitive answer by referring to the "right processes and practices" being in place and followed, p173.
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page