Downside
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:
- 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.
- 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.)
- 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[10]
- 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?
- 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.
- 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]
- 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.
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.
|
What
We Liked – Part 3: 
