Introduction | Content in General | Project Life Span
Technical Content | Pearls of Wisdom

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 non-projects".[3] So, 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,[4] 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"[5] as a collective surrogate for the project life span. Indeed, she actually refers to these labels as "phases".[6] 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 ..."[7] 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.[8]

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.[9] That is to say, it really is a cyclical management effort. Figure 1 illustrates the relationships between the project management knowledge areas or 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 for this central process group which leads to all this confusion. As an aside, slavishly following all the inputs and outputs to the process groups can lead to an awful lot of unnecessary bureaucracy, even on quite large projects.

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.[10] Accordingly, Kim provides an in-depth look at Managing Integrated Change Control, Controlling and Control Techniques[11] 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.

About the Content in General

Technical Content

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page