Planning Is Not A Project Life-cycle Phase
By William R. Duncan
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. 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, 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.
Originally published at pmtip.wordpress.com
William R. Duncan is the principal of Project Management Partners of Lexington, MA USA. He currently chairs the Board of PMCert, the certification body of the American Society for Advancement of Project Management (asapm). He was the primary author of the original (1996) version of A Guide to the Project Management Body of Knowledge and was one of the founding members of the Global Alliance for Project Performance Standards (GAPPS) which has recently published a framework for performance-based competency standards for project managers.
© 2009 William R. Duncan – http://www.pmpartners.com/