The Project Life Span
The project life cycle deserves special attention in my remarks.
As an aside, does anyone think that we might now stop calling it
a life cycle giving the impression that the project
should go round in circles? While that might unfortunately be true
on many projects, it is certainly not the intent of project management.
The intent of project management is to drive a project forward through
a series of periods, phases and stages tailored to the specific
project and its particular development and implementation strategy.
These time intervals should be reflective of the product and its
environment. Driving a project forward means steering it through
these intervals separated by "gates" as a means of ensuring
control and continued support by all of the partners involved. More
on "control" in a moment.
According to M. B. Patel and Prof. P.G. W. Morris in their document
Guide to the Project Management Body of Knowledge published by the
Centre for Research in the Management of Projects: "The life
cycle is the only thing that uniquely distinguishes projects from
you would have thought that the matter of the project life span
would have received considerable attention. The project life cycle
gets a good description in the first chapter of Kim's book,
but it is brief. But then the PMBOK Guide only devotes one subsection
to the topic and that is mostly illustrations of life cycles published
elsewhere. So, this is a major weakness of the PMBOK Guide, especially
for those who consider it a "standard".
But the project practitioner public is desperate for a methodology
to apply to its projects, so Kim has done her best to develop the
book with a project evolutionary structure. Like so many others,
she may be forgiven for turning to the PMBOK Guide process groups
"Initiating, Planning, Executing, Controlling and Closing"
as a collective surrogate for the project life span. Indeed, she
actually refers to these labels as "phases". Well, except for "Controlling"
which is a situational response rather than a sequential response,
it does look like a project life span, doesn't it?
The superficial reaction is that if the rest of the labels are
phases then "Controlling" must also be a phase. This interpretation
tends to be underscored by a Real World Scenario description: "The
project is in the Controlling process ..."
Good. Once we are done with the Controlling phase or process we
don't have to worry about "Controlling" anymore! The waters
get even more muddied when we read about the four Contracting Life
Cycles of requirement, requisition, solicitation and award, under
Measuring and Controlling Project Performance.
For those who do not follow this line of thinking, the process
group of "Initiating, Planning, Executing, Controlling and
Closing" is, as Kim points out, intended to be a repetitive
management process revisited throughout the project life. That is to say, it really is a cyclical
management effort. Figure 1 illustrates
the relationships between the project management knowledge areas
functions, the project life span and the really cyclical management
process of planning, organizing, doing, tracking and steering.
I suspect that the problem is with the labels adopted by PMI
central process group which leads to all this confusion. As an
aside, slavishly following all the inputs and outputs to the
can lead to an awful lot of unnecessary bureaucracy, even on quite
Figure 1: The Function-Process-Time relationship
in project management
The problem with this "Controlling" business is that
having established this over-arching process group, the PMBOK Guide
then needs to cover the subject in most of the separate knowledge
areas. Realizing that control of one necessarily affects one or
more of the others, the PMBOK Guide introduces the concept of Integrated
Change Control. Accordingly,
Kim provides an in-depth look at Managing Integrated Change Control,
Controlling and Control Techniques by bringing together the corresponding
references under each knowledge area in the PMBOK Guide. This is
a valuable exercise if only to highlight how problematic is this
whole area of control and controlling. There must be a better way.
PMBOK Guide updaters, please take note.
CRMP Guide to the Project Management Body of Knowledge published by
the University of Manchester, UK, 1999, p52
4. PMP Study Guide pp22-23
5. PMP Study Guide p24
6. PMP Study Guide p264, under Resource Requirements
7. PMP Study Guide p372
8. PMP Study Guide p331
9. PMP Study Guide p25
10. PMBOK Guide p47
11. PMP Study Guide pp367-386