Summary
To summarize, we have, in the very first level, the so-called Product Oriented Processes sequence that essentially sets the basic workflow demanded by the nature of the technology involved. Earlier, we labeled this as Level 1a. The next level up encompasses the Project Management Processes as described in the The PMBOK® Guide. The Guide provides advice on those aspects that should be given consideration in the running of the project rather than assembling the product. Earlier we labeled this as Level 1b.
As the The PMBOK® Guide points out, these two sets of processes overlap and interact throughout the life of the project and must therefore proceed in lockstep. Interestingly, many companies recognize this intuitively, by assigning two key people to manage a large project. One is a subject matter expert responsible for overseeing the evolving technology of the product, and the other is responsible for organizing the proper conduct of the project in terms of scope, quality, time, cost, risk and so on. Clearly, these two people must work closely and effectively together, a condition that requires compatibility of personalities - and is an added hazard of project management.
If what we have described is accepted, then what we labeled as Levels 1a and 1b should be seen as Levels 1 and 2, with the previous levels 2 & 3 renumbered to Levels 3 & 4 respectively. More importantly, however, overarching all of this are the control requirements of the sponsoring organization. These requirements are required to satisfy the organization's reviews of strategic direction, financial limitations, and the need to enable the newly emerging discipline of project portfolio management.
In this context, perhaps these requirements should more properly be referred to as the corporate organization's project "governance" requirements. They are typically imposed on the life span of each project in the portfolio as "executive control gates". Figure 6 shows examples of such "gates" at the major milestones of a conceptual project.[13] The reader should especially note the phase marked #1 in the Figure. This is where key documents should be produced such as a Value Proposition, but more particularly a Business Case that justifies the emergent project going forward. In our view, the approval of a business case is where the project really begins!
Figure 6: The project life span phase deliverables and executive control gates
But in any case, this "front end" is where the foundation of the project is established and possibly the most important decisions are made, decisions that will have a marked effect on the overall success of the project. And these major decisions can be made at this time at least cost as illustrated in Figure 7.[14]
Figure 7: Potential for adding value at least cost in the project life span
Thus, we can see how the four levels, as implied by authors Peter Morris and Joana Geraldi in their paper Managing the Institutional Context for Projects, are successively influenced by the vital "front end" of a project. Indeed, as the authors state: "there is huge evidence (going well back to DOD days) that the front end is both where the most damaging errors get built in and, alternatively, where there is the biggest scope for enhancing value".
The "front end" is the essential link in connecting the project's three other levels to the organization's strategic fourth level but is, unfortunately, so often overlooked in the project management institutional literature.
In Part 2 of this paper we will take a look at our
view of the need for basic research in project management.
R. Max Wideman,
FCSCE, FEIC, FICE, FPMI
13. Wideman, A Management Framework, Figure 5-1, p49
14. Ibid, Figure 5-17, p63
|
Managing the Product Versus Managing the Project
