The Project Management Institute's Guide to the Project Management Body of
We start with this one because it is, perhaps, the most widely known. However,
it is more of a cult than a rigorous methodology. As the Guide itself says "The
primary purpose of this document is to identify and describe that subset of
PMBOK® that is generally accepted. Generally accepted means that the knowledge
and practices described are applicable to most projects most of the time, and
that there is widespread consensus about their value and usefulness. Generally
accepted does not mean that the knowledge and practices described are or
should be applied uniformly on all projects; the project management team is always
responsible for determining what is appropriate for any given project."
Notwithstanding, the Guide has all the hallmarks of a methodology, and in the
absence of anything else is often used as such. The frequent basis of this methodology
is the infamous set of process groups: Initiating; Planning; Executing; Controlling;
and Closing, which are intended to apply to each and every phase of the project
life span as a management cycle.
Understandably, with these labels, this series is often taken as the set of phases
of the project life cycle itself. The consequence is that "Controlling"
looks like a "phase" to be entered into and then abandoned when done.
In reality, "control" should be exercised throughout the project
life span, but the Guide does not discuss overall project control in its discussion
of project life cycles. As Forsberg et al have clearly illustrated,
a distinction must be drawn between "situationally" applied management
elements and the "sequential" project cycle. The control process and
its supporting components of baseline planning, measure, compare and correct,
are clearly situational and hence cannot, in any way, be considered as a "phase".
Beyond this, and other than a general discussion of several displays of project
life cycle, the expectation of each "knowledge area" discussed in the
Guide is that you first figure out the project's requirements (in the knowledge
area) and then move on to planning and then execution. Well and good, but this
is a linear progression that does not seem to serve the software development
3. A Guide to the Project Management Body of Knowledge (PMBOKČ Guide), 2000 Edition, Project Management Institute, PA, 2000, p3
4. Ibid, p30
5. Kevin Forsberg, Mooz, M. and Cotterham, H. , Visualizing
Project Management, 2nd Edition, Wiley, 2000, p43