Dynamic Project Management Framework (A brief approach to the PMBoK® Guide execution)
By Andrés Falcón, PMP.
[email protected] Version 2 – Release 1
Content Content
1
Abstract
1
Acknowledgments
2
Introduction
2
The PMBoK® Guide as a Framework
2
The Project Life Cycle
2
Materializing the Theory
3
The Iterative Execution
3
The Dynamic Iteration Process
6
Closing up
7
Appendix A: Description of a Framework
7
Appendix B: Creating and Defining the PLC
8
References
8
Abstract What we all know, so far, is that the Guide to the Project Management Body of Knowledge is the master book for Project Managers. However, as it is, it has, sometimes, personal interpretations. Here I present the conceptual steps to use the PMBoK® Guide processes in accordance with the Projects that will be needing it. So this paper is about the integration knowledge area. And this covers why phases of a project life cycle should not be considered as the Project Management Process Groups referenced in the PMBoK® Guide. That is the key point of understanding the process of carrying out a project and having this in mind is the main objective of this paper. This paper is based mostly on the PMBoK® Guide 2008-Fourth Edition but a few references to the PMBoK® 2004Third Edition are been made as well.
Pa ge |1
Acknowledgments I would like to thank to all of them that have help me in getting a clear, clean and understandable paper. Especially to Veronica Cvitkovic and Nicolás Rigo. Many thanks to them all.
Introduction Using PMI’s PMBoK® Guide 2008 with a project is not a straightforward task. Most of the times, we get stuck trying to select the task we should use first, in which order, whether we take those included in one group, or worse when we need to proceed iteratively with PMI processes going through each phase of our project. The primary goal of this paper is to help to establish a conceptual mechanism, guidance, or high level approach to a practical use of PMBoK® Guide processes in a given project. We will be using the idea of a rolling wave process over an entire life cycle, keeping the intention of providing a tool to fill in the gap between the methodology and practical use. The steps we are going to covers leads you through a quick review of the concept of Framework, a more explained use of the Project Life Cycle, on which is base the dynamic concept. And last, the iteration and dynamic concept introduction, the main goal of this paper.
The PMBoK® Guide as a Framework In general, a framework is an empty structure which is applicable, with some rules and with specific methods, to a given purpose. This give us the idea of something previously created, proved and sometimes already applied. And most of the time used to save time, help us to improve the quality of our work and to avoid reinventing the wheel. In this direction, The PMBoK® Guide is an organized collection of best practices (inserted into its processes), already used in many different situations. And it is aimed at increasing the probability of project success, and in well applied cases, assure it. If you feel you need further detail, then check the Appendix A: Introduction to Frameworks.
The Project Life Cycle What is it a project life cycle? Let us first take the reference from the PMBoK® Guide 2008-Fourth Edition which says: “A project life cycle is a collection of generally sequential project phases whose name and number are determined by the control needs of the organization or organizations involved in the project. … The life cycle provides the basic framework for managing the project, regardless of the specific work involved”.(PMBoK® Guide 2008-Fourth Edition – 2.1 The project life cycle – overview, page 11). The main goal of defining a life cycle to projects is to establish a logical division in order understand the progress and get deeper control of the project. Normally, the PLC is splitted into different parts, named phases. The phases can be made to avoid control getting diffuse when Projects are complex or large. They are related to a certain function and group of deliverables and, in most cases, should be attended or carried out differently. Phases should not be considered the same as the Project Management Process Groups mentioned in PMBoK® Guide 2008-Fourth Edition (p. 41). Though some authors relates the Project Management process group to the PLC, that is not appropriate.
Pa ge |2
Because, first, phases of PLC are created, changed or adjusted based on which kind of project they are going to be applied, the Project Management Process Groups are always the same in all the projects. Second, PLC has its own deliverables that are related to the product or service being delivered, and different from the deliverables produced with the Project Management Process Groups, that are related to the activities that the project manager has to do during the project to accomplish its goal, and those activities may cross different phases or be within them. Certainly, as Frame says, establishing a life cycle for a project must be the first step in your planning activities and then it should guide the rest of your work throughout it. If you want to know which considerations to have when creating or defining a PLC in your Project Management Office (PMO) please read the Appendix B: Creating and Defining the PLC
Materializing the Theory It is time to use these concepts in the real life. We have just clarified the purpose of Framework and PLC. Now, we are going to see how making use of it relates it with the processes groups of the PMBoK® Guide 2008-Fourth Edition. If we check the PMBoK® Guide 2008-Fourth Edition, we will see that the PM processes are grouped. At first sight, we may see that these groups match with the phases of our PLC. However, as we already mentioned in the previous section, they are not part of the PLC of a project, because they are at another conceptual level: in particular, they represent the activities that the Project Manager has to cover during the project execution and, hence, they have different execution timing. Iterative and Dynamic Execution will help us to understand how that timing is.
The Iterative Execution Iterative execution means that we should use the processes group in a circular way, perhaps more than once in a given project or even more than once in a specific phase. It is a rule that should be used, at least, once in each phase. In the following diagram, taken from the PMBoK® Guide 2004-Third Edition (Figure 3-12 - Project Management Process Group Triangle), this cyclic concept is expressed. In the uppermost level you can see that there is a processes group as well; this represents a generic macro vision of the steps of the project and PLC. The three upper levels are those that need to be adapted by industry/organization situation. What we are now interested in is the lowest level of the pyramid, where is shown the processes groups being cycled iteratively from start to end. And, as you see, every time the close group is reached, the initiation group is the following step, iteratively until the project ends.
Pa ge |3
Figure 1 - Project Management Process Group Triangle With this concept in mind, in each phase, we have to execute the processes groups using the following method: Initiation and Closing should be executed just only once in each phase: Initiation processes at the beginning of the phase and Closing processes at the end of it. These two groups are not iterated in a phase. They are only entrance and exit processes of them. The rest of the processes groups must be executed as described below: Planning is executed in first position, and then comes the execution process group, which are both executed by the project team. Throughout the execution, monitoring and control are being executed only by the project management team. Though execution processes are continuously executed during the phase, monitoring and control are being inserted once a while to get a revision of what is being produced by them, in order to control the variables or metrics of the project and verify that it is aligned with what had previously been planned. Monitoring and Control will determine in its verification if the execution has accomplished the goal of the current phase. Remember that all the processes should be executed at least once. We may call this the normal execution of the processes; not exceptions being produced. Figure 3 shows this situation.
Pa ge |4
Figure 2 - Process Group in a Normal Execution It should be mentioned that, the normal execution is not the common situation, not in a few cases; many times the execution should be stopped because of the problems found by the control processes. Such problems may include: phase goals are not being conveyed, the project may be delayed and corrective actions are not enough to get it back to its original planning, project objectives have change, etc. This will require a further replanning. After this replanning, where we get a new planning document version, we should continue over the execution considering the new planning situation. Figure 4 shows this situation.
Figure 3 - Process Group in Re-planning Execution. Also, sometimes, it might happen that the replanning is needed only in some subset of WBS work packages or activities. This may allow some other work packages or activities to going on executing because they did not receive any change. In these cases, replanning can be done in parallel with execution and re-enter to it by and execution thread, and then continues normally or as the control requests. As the figure 5 shows:
Figure 5 - Process Group in parallel Re-planning Execution. Pa ge |5
This might happen as many times as needed, until the phase is completely accomplished.
The Dynamic Iteration Process By now, we have covered the iterative execution. The dynamic execution is the topic which is based on this paper. Dynamic execution means that, considering a specific PLC, there should be a selection of processes to be executed, whose detail must be planned. And then should be accomplished for each phase of that PLC. In this sense, the effort to execute each process, from the group of processes, should vary from phase to phase, applying each one with different depth and detail depending on what function is expected from them at that moment. In each phase the process group must be executed using the iterative execution, already seen. But each time a new phase is started, a selection should have been made. This selection refers to which process we are going to choose from each processes group and analyze them to determine which one is going to be executed and with how much detail and effort in each PLC phase. Considering that different grades of detail may be zero detail, which is not execute it. This, as de PMBoK® Guide 2008-Fourth Edition says, should be done by the project management team. Why is method this dynamic? Because if we take one phase at a time, we will find that different processes are needed for it to be accomplished. This means that the same group of processes has different behaviors in each phase of each PLC. This behavior change is represented by the appearance of different processes executed in that phase. I am going to provide you some examples from a software PLC. Let us have a look at the following phases of the PLC: initiation (pre-sales), requirements collection, planning, design, implementation, closing. Take care throughout this description because it may be confusing. To minimize the probability or to avoid it I will highlight them to better show you the idea of using this methodology: a bold-italic type will be used in names of phases, an italic type will be in name of group of processes and a “brackets type” in name of a specific process. Let us see: In the Data gathering phase of Software PLC, the Planning group may execute only the “5.3 Create WBS” and “5.1 Collect Requirements” to get what is needed. And in the subsequent phase of the same PLC, as Planning, the Execution group will “6.5 Develop a Schedule” and “4.2 Develop a Project Plan” that may not have all the subsidiary plans at this moment of evolution of the project. At the end of this phase, we have just executed Initiation groups, Planning, Execution, Monitoring and Control, and Closing three times. And we will continue with the update of the planning documents, in Design phase, using rolling wave (planning as far as you know) during the Planning Group of processes in the following phase. And “8.3 Performing a Quality Control”, on the other hand, may control different things in each phase: in Planning it controls the quality of the documents, in Implementation, it checks how well the product under development is done. And here another example, the “9.2 Acquire Project Team” may be considered during Requirements collection or Planning, and “9.3 Develop Project Team” during Planning and Design and, last, “9.4 Manage Project Team” during Implementation. And so on. This is what the dynamic concept is: The group of processes should be adapted in each phase on each PLC. And this should be arranged by each project management team as soon as possible, before the project begins. Fortunately, this is normally repetitive in the same type of project in a specific organization but must be considered this way and should be previously prepared for this. So, you may need to think about this only just once. But you need to do it before starting a new project. This method requires some training, concentration and ongoing improvement. Pa ge |6
Why should be consider this in this way? Otherwise, you would end up executing the 44 PMBoK® Guide 2008Fourth Edition processes in each phase of your project. If it were the case, you would not only have delays in your project, but you would never end your projects anymore.
Closing up We have come to the end of the road. I expect you have found this material useful, to help you visualize, more clearly, the general concept concerning the Integration Knowledge Area and how it works. Now it is time to do your homework: review you current PLC and check what function is doing each phase, what you expect from each one, which processes of each processes groups is required in each one and how much effort is needed of them. Keeping in mind that the Processes groups are iterative and dynamic, apply it in your project using the method provided. Thank you for coming with me on this short trip. Looking forward to hearing your questions, feedbacks and comments. Hoping to see you next time.
Appendix A: Introduction to Frameworks Let us see further information about Frameworks. We have already seen that a framework is an empty structure which is applicable, with some rules and with specific methods, to a given purpose. Many other similar definitions can be found, like: “the structure of a particular system” (Oxford Dictionary), “a basic system of rules or ideas which guides people in their work or thinking” (Longman Dictionary), “a basic conceptional structure (as of ideas) ” (Merriam-Webster), “A framework is a basic conceptual structure used to solve or address complex issues.” (Wikipedia.org) or “A framework is a real or conceptual structure intended to serve as a support for building a superior or more complex structure, turning it into something useful” (whatis.com) As mentioned the definitions mentioned above give us the idea of something previously created, proved and sometimes already applied. Covering this concept a framework is used to save time, help us to improve the quality of our work and to avoid reinventing the wheel. The framework should be based on an already existing piece of work, and must previously be successfully tested on it. In this direction, The PMBoK® Guide is an organized collection of best practices, already used in many different situations. And it is aimed at increasing the probability of project success, and in well applied cases, assure it. Some of us could come to the conclusion that a framework is a stone written structure, sometime suggesting an already settled-never changing tool. Luckily, this is not true! It is flexible, but with some rules. In such a conceptual idea, rearrangements or even replacements, considering new or better blocks or even new rules, makes it even more appropriate to the work to be done. However, such rearrangements or replacements have one and simple rule: it should be approved by PMI and should be settled in a PMBoK® Guide version. Between versions, no change is allowed. And each new version represents a better idea than the previous one. That is why we have, and sometimes we need, new updates, settled on versions, each one with its new and particular approach. Besides, if it were not considered flexible it would not be possible to use it in so many different industries. Finally, a framework works as a skeleton; however it does not have self movement. We need to add muscles and give it path to ride: the life cycle comes to play this role.
Pa ge |7
References A Guide to the Project Management Body of Knowledge – 3rd Edition, PMI, 2004. A Guide to the Project Management Body of Knowledge – 4th Edition, PMI, 2008. Harold Kersner – Project Management - A Systems approach to Planning, Scheduling and Controlling - 8th Edition, 2003, John Wiley & Sons d. Jason Charvat, Project Management Methodologies, 2003, John Wiley & Son. e. Kim Heldman, Project Management JumpStart, 2003, Sybex. f. Davidson Frame, Managing Project in Organizations – Third Edition – 2003 – Jossey Bass – A Wiley Imprint g. Harvey Levine, Practical Project Management, Tips - Tactics and Tools, 2002, John Wiley & Son. h. Newell,M and Grashina,M, The Project Management Question And Answer Book, 2004, AMACOM i. Muhamed Abdomerovic, Brainstorming The PMBoK® Guide, 2001, Project Management Publications. j. Wysocki, Robert K and McGary, Rudd , Effective Project Management, 2003, John Wiley and Sons. k. Course Technology, Project Management: Advanced, 2002, ISBN: 978-0-619-07538-5 l. The Human Aspects of Project Management: Human Resource Skills for the Project Manager, Volume Twoby Vijay K. Verma, P. Eng., M.B.A. Pub Date: January 01, 1996 m. A Guide to the Business Analysis Body of Knowledge (BABOK 1.6) – IIBA – International Institute of Business Analysis. n. Domingo Ajenjo - Dirección y Gestión de Proyectos – Un enfoque práctico – 2da. Edición actualizada y revisada– Alfaomega – Ra-ma
a. b. c.
Websites References: o. PLC Models: http://www.business-esolutions.com/islm.htm p. Waterfall Model: http://en.wikipedia.org/wiki/Waterfall_model from the Free On-line Dictionary of Computing q. Incremental Model: http://en.wikipedia.org/wiki/Incremental_build_model r. History of Iterative: http://c2.com/cgi/wiki/wiki?HistoryOfIterative s. Incremental vs Iterative: http://alistair.cockburn.us/Incremental+versus+iterative+development
Pa ge |8
