Many of you probably know the old joke about the comedians’ convention where the professional comedians all knew all the jokes and had them catalogued and numbered. To save time, they just called out the number instead of telling the whole joke.
Well, the folks who know me have heard some of my rants often enough that they probably have them catalogued and numbered as well. So for those of you who don’t know me, here comes Rant #3 …
Planning is not a project life-cycle phase. Planning is an ongoing activity throughout the project. The only time planning looks even a little bit like a phase is when you are managing a single phase of the project and someone else is defining scope for you. [Side note: scope = the characteristics of the product of the project. That is rant #1.] The classic example is “construction” which is really just one phase of an asset development project. If you manage single phase projects, you can use planning as a phase name, and you can also stop reading now. The rest of this rant does not apply to you.
If your project life-cycle uses planning as a phase, toss your life-cycle and start over again. If your project life-cycle uses planning as a phase, you probably also use initiating, executing, and closing. Someone in your organization decided to use the process groups from the PMBoK Guide as life-cycle phases. Odd that they were smart enough to realize that “controlling” was not a phase, but not smart enough to look at the diagram that showed the process groups repeating within each phase.
Why is this a problem? Let’s take a simple example from the field of application software development. Say you want to develop a new application system to support web-based ordering of the latest version of your ultra-modern framistan. How will you determine what the client or user needs? You might start with a feasibility study, then follow that with requirements definition. Once the requirements are agreed, you’ll do some design work, followed by some programming and some testing. Once the test results are satisfactory, you’ll put it into operation.
I don’t think there are many who will argue with those steps. Even if you’re into agile software development (not agile project management; that’s rant #2), you can probably see that you go through those steps within each iteration. Agile iterations serve the same function as project life-cycle phases.
So here’s the issue … if your project life-cycle consists of initiating, planning, executing, and closing (or maybe initiation, planning, execution, and closing), where do you put the feasibility study? Where do you develop the requirements document? If you do it in the initiating phase, when and where do you do the planning for who’s going to do that work? Not in the planning phase, because that phase doesn’t start until initiation is finished.
How about design? You’ve got two choices: initiating or executing. If you do it as part of initiating, you now have two of the most critical and vital aspects of your project that have been done without any planning. If you put it in the executing phase, that means that you will be planning all of the programming and implementation activities before any of the design work has been done.
Get a grip world. Name your phases after the product-oriented steps relevant in your business. Then you can initiate, plan, execute, control, and close each phase. Project plans will be more reliable. Life will be easier. We might even have the time and resources to bring peace to the Middle East and halt the spread of AIDS in sub-Saharan Africa.
Actually, those last two may be easier than getting people to admit that their project life-cycle is wrong.
Tags: phase names, PM methodology, PMBoK Guide, Process groups, project management, project management methodology, Project phases, project success, SDLC, software development
November 3, 2009 at 5:59 pm |
Hi Bill,
I would like to publish this article on PM Hut. Please either email me or contact me through the “Contact Us” form on the PM Hut site in case you’re OK with this.
November 4, 2009 at 5:03 am |
Hi Bill,
I agree with your observation.
Abitlity to discriminate between project execution (lifecyle) and project management is oen fo the first fundamental understanding requirement. During training session I share about sequential and situal aspects of managing projects. Project Lifecylce represent the sequential aspects of how the project will be executed. This doesn’t take away the fact that there could be overlap in the sequential phases/stages but the key is that PM is the situational aspect and all the required processes under the performanin domains (IPECC) is used with in different rigour all through out the lifecycle. When viewed as an ovelapping discpline (PM with Lifecyle), it faciliates discrimation as well as clarity of role between the Tech Leader and Project Manager.
November 6, 2009 at 7:39 pm |
Bill,
This is a great article. This clarifies the classic confusion of product development lifecycle and project management lifecycle. As you pointed out, a lot of folks confuse the PMBOK project management process goups with project management lifecycle.
Thank you.
November 6, 2009 at 8:03 pm |
Samad — thanks for the compliment, but I’m not sure what you mean by the “project management lifecycle.” To me, there is a product lifecycle and a project lifecycle.
November 6, 2009 at 8:54 pm
Bill,
I meant Project Lifecycle.
November 7, 2009 at 10:21 am |
Just came across this in the Visual Thesaurus blog about “soap-free soap”:
“This paradox isn’t actually so paradoxical if you look at the word soap as filling what semanticists call “marked” and “unmarked” categories. The unmarked category is the more general one, while the marked one is more restricted. Some words can be either marked or unmarked, depending on the context. For instance, the word cow can refer to cattle in general, but it can also refer to the female only (as opposed to bull).”
If we think of “planning” as unmarked, I doubt that anyone would argue that planning activities should be localized to a single project life-cycle phase. So when an organization uses “planning” as a marked word, they are suggesting a narrow meaning along the lines of “most of our planning is done at the start of the project.”
The problem arises when there is a need for real phases where the characteristics of the product of the project are figured out. When that happens, the marked sense of planning is just plain wrong and causes problems in deciding what should be done and when.
November 10, 2009 at 12:14 am |
In my experiences, this is kind of like the “chicken and egg” problem for project managers. Often times one finds him/herself doing 2 planning phases – the first plan is performed to get the funds for the project (sometimes a feasibility study occurs here) – hence you need a project plan before you have done an initiating (or planning) phase for the “real” project.
November 11, 2009 at 4:20 pm |
Marshall — not quite. You need to plan for EVERY phase. You need to develop a plan for the feasibility study, then you need to develop a plan for each phase of whatever project life-cycle you are using. For example, let’s say that you are developing a new ride for Disney World. You do a feasibility study, and then you can plan all aspects of design and construction based on the results of that study? I don’t think so.