Dynamic Project Management Framework: A Brief

PMI Virtual Library © 2009 Andrés Falcón

Dynamic Project Management Framework: A Brief Approach to the PMBOK® Guide Execution By Andrés Falcón, PMP

Abstract

®

What we all know, so far, is that the A Guide to the Project Management Body of Knowledge (PMBOK Guide) is the master book for project managers. However, it is often subject to personal interpretation. In this paper, I present the conceptual steps needed to use the PMBOK Guide processes in accordance with the projects that need it. Therefore, this paper is about the integration Knowledge Area, and it covers why phases of a project life cycle should not be considered as a part of the Project Management Process Groups referenced in the PMBOK Guide. Furthermore, it explains how to use the processes groups within the project life cycle. Understanding the process of carrying out a project and keeping this concept clear are the main objectives of this paper. This paper is based mostly on the PMBOK Guide—Fourth Edition, but there are some references to the PMBOK Guide—Third Edition as well.

®

®

®

U

sing the A Guide to the Project Management Body of Knowledge (PMBOK Guide)—Fourth Edition (Project Management Institute [PMI], 2008) with a project is not always a straightforward task. Many times we have difficulties selecting the task we should use first, determining the correct order in which to proceed, and deciding whether we should use all of the tasks included in one group. The primary goal of this paper is to help establish a conceptual mechanism, guidance, or high-level approach to the practical use of the PMBOK Guide processes in a given project. We will use 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 methodology and practical use. The steps we are going to cover lead you through a quick review of the concept of framework and a more explained use of the project life cycle, on which this dynamic concept is based. Finally, the iteration and dynamic concept will be introduced.

®

®

®

The PMBOK® Guide as a Framework In general, a framework is an empty structure that is applicable, with some rules and specific methods, to a given purpose. This implies that something was previously created, proved, and normally already applied. Since this framework has already been created, we do not have to reinvent the wheel, which helps us to improve the quality of our work. Following this direction, the PMBOK Guide is an organized collection of best practices (inserted into its processes) already used in many different situations. It is aimed at increasing the probability of project success, and in well-applied cases, assures it. For further information on frameworks, please see Appendix A.

®

The Project Life Cycle What is a project life cycle (PLC)? According to the PMBOK Guide—Fourth Edition: “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” (PMI, 2008, p. 15). The main goal of defining a life cycle to projects is to establish a logical division in order to understand the progress and to gain deeper control of the project. Normally, the PLC is split into different parts named phases. The phases can be made to avoid control getting diffused 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—Fourth Edition (PMI, 2008, p. 41). However, sometimes a PLC is inappropriately related to the Project Management Process Group. Phases of a 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, a PLC has its own deliverables that are related to the product or service being delivered and are different from the deliverables produced with the Project Management Process Groups that are related to the activities that the project manager has to perform during the project to accomplish its goal. Those activities may cross different phases or be within them. As Frame (2003) said, 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. For considerations you need to have when creating or defining a PLC please see Appendix B.

®

Materializing the Theory It is time to use these concepts in real-life projects. We clarified the purpose of frameworks and the PLC. Now, we are going to see how using it relates to the processes groups in the PMBOK Guide—Fourth Edition. If we consult the PMBOK Guide—Fourth Edition (PMI, 2008, p. 41), we will see that the project management processes are grouped. First, we may think 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 the 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 Figure 1 taken from the PMBOK Guide—Third Edition (PMI, 2004, p. 69), this cyclic concept is expressed. In the uppermost level, you can see that there is a process 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 the industry/organization situation. What we are interested in now is the lowest level of the pyramid, where the processes groups being cycled iteratively from start to end are shown. And, as you can see, each time the close group is reached, the initiation group is the following step, iteratively, until the project ends.

®

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 initiation and closing methods 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 the entrance and exit processes to them. The rest of the processes groups must be executed as described in the following. 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 executed only by the project management team. Though execution processes are continuously executed during the phase, monitoring and control are being inserted

PMI Virtual Library | www.PMI.org | © 2009 Andrés Falcón 2

once in 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 2). It should be mentioned that the normal execution is not the common situation; 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, project may be delayed and corrective

actions are not enough to get it back to its original planning, and project objectives have changed, etc. This will require further replanning. After this replanning, where we get a new planning document version, we should continue with the execution considering the new planning situation (Figure 3). Also, sometimes, it might happen that the replanning is needed only in some subset of work breakdown structure work packages or activities. This may allow some other work packages or activities to continue executing because they did not receive any change. In these cases, replanning can be done in parallel with execution and re-enter it by an execution thread, and then it continues normally or as the control requests (Figure 4). This might happen as many times as needed, until the phase is completely accomplished.

Figure 2: Process group in normal execution

Figure 3: Process group in replanning execution

Figure 4: Process group in parallel replanning execution PMI Virtual Library | www.PMI.org | © 2009 Andrés Falcón 3

The Dynamic Iteration Process We have covered the iterative execution and now we will discuss the dynamic execution—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. It should then 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. Different grades of detail may be zero detail, which is not executing it. According to the PMBOK Guide—Fourth Edition

®

(PMI, 2008, p. 190 ), this should be done by the project management team. Why is this method 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. This concept is shown in detail by using the dynamic execution wheel (Figures 5 and 6). In Figure 5, we can see the execution wheel rolling over the timeline. Each time the arrowhead touches the timeline, it represents the beginning of that group of processes. This is a conceptual graphic to understand the dynamic concept. The real way to combine the processes groups was explained previously. The dynamic execution wheel represents that in a circular way, and regularly we have to execute each of those group processes. So, in the first phase, we have the initiation processes, then planning, executing, monitoring and control, and then closing. Then in the second phase, it is the

Planning in phase 1

Dynamic Execution Wheel

Pl an nin g

se

In iti at e

Mo ni t C o oring n tr ol &

cu tin g

Ex e

an ni

Pl

tin cu

Clo

g

& g rin l ito tro on o n C

Dynamic Execution Wheel

M

e Ex

at e

Executin g

Planning

Dynamic Execution Wheel

g nin an

& g ri n l i to tr o on on C

Dynamic Execution Wheel

Pl

M

In i ti

g& itorin Mo n ntr ol Co

g

ng

Executin

Planning in Phase 2

Phase 2

Phase 1

Figure 5: Dynamic execution wheel

Ex ec

ut in

g

Dynamic Execution Wheel

Ex ec u

12.1 Plan Procurement

tin g

Dynamic Execution Wheel

11.1 Plan Risk Management

Planning 5.1 Collect Requirements

Planning in phase 2

Mo nit Co oring ntr ol &

Mo nit Co oring ntr ol &

Planning in phase 1

Planning 5.1 Collect Requirements

8.1 Plan Quality

5.2 Define Scope

Figure 6: Planning in two different phases PMI Virtual Library | www.PMI.org | © 2009 Andrés Falcón 4

same situation, however, the selected processes to be used in planning in phase 2 might be different. Figure 6 shows the wheel during planning in phase 1 and 2. It can be seen that in phase 1 the planning processes group is executing different processes than in phase 2. Also, although it is not shown in the figure, it might happen that a process is repeated in different phases, or not repeated at all, just executed once. This kind of behavior is expected in all of the other processes groups. This is an example of what can be executed, because the processes decided to be used in each phase should be establish by the project management team according to what is expected in each phase. This is how the PLC impacts the execution on planning by selecting the processes to be used. At the end of the project, the planning group should have executed all its processes. For example, let’s examine a software project life cycle. First, we have to define the PLC: initiation, requirements collection, planning, design, implementation, and closing. (Note: I will highlight the terms used 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 used to name the group of processes, and a “brackets type” to name a specific process.) In the Requirements collection 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. In the subsequent phase of the same PLC, 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, once for initiation, planning, and execution. And we will continue with the update of the planning documents, in the Design phase, by using the rolling wave (planning as far as you know) during the Planning group of processes in the following phase. The process “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. Another example is 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 prepared for. 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. Why should it be considered in this way? Otherwise, you would end up executing the 42 PMBOK Guide—Fourth Edition processes in each phase of your project. If that were the case, you would not only have delays in your project, but you would not finish your projects.

®

Conclusion I hope that 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’s time for you to do your homework: review you current PLC and check which 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. Keep in mind that the processes groups are iterative and dynamic; apply it in your project using the method provided. Appendix A: An Introduction to Frameworks We have already seen that a framework is an empty structure that is applicable, with some rules and with specific methods, to a given purpose. Many other similar definitions can be found: “the structure of a particular system” (Oxford Advanced Learners’s Dictionary, p. 510 ); “a basic system of rules or ideas which guides people in their work or thinking” (Longman Dictionary Language Activator, p. 1358 ); “a basic conceptional structure (as of ideas) ” (Merriam-Webster’s Collegiate Dictionary, electronic version Franklin Bookman); “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). These definitions give us the idea of something that has been previously created, proved, and sometimes already applied. Following 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. Following this assumption, the PMBOK Guide is an organized collection of best practices that are already used in many different situations. It is aimed

®

PMI Virtual Library | www.PMI.org | © 2009 Andrés Falcón 5

at increasing the probability of project success, and in wellapplied cases, assures it. Some have come to the conclusion that the PMBOK Guide as a framework is a written-in-stone structure, suggesting that it is an already settled and 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 for the work to be done. However, such rearrangements or replacements have one simple rule to be followed: it should be approved by PMI and should be published in the PMBOK Guide. Between versions, no change is allowed and each new version should result in a better revision. That is why we have, and sometimes need, updates and new 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 like a skeleton; however, it does not have self-movement. We need to add muscles and give it a path to ride: the life cycle comes to play this role.

®

®

Appendix B: An Approach to Creating and Defining the Project Life Cycle Project Life Cycle and Product Life Cycle We have seen briefly what a project life cycle (PLC) is and reviewed the definition in the PMBOK Guide—Fourth Edition (PMI, 2008, p. 15). It is important to distinguish the PLC from the product life cycle so not to confuse both concepts. The PLC is related to how you structure your project and is considered to last until the project ends. The product life cycle is conceived to understand a product life cycle periods, and how a product changes during its life, finally the end of its life cycle means that the product is useless. Remember, PLC phases may overlap, product life cycle phases never overlap.

®

Phase’s Definition The main goal of defining a life cycle for projects is to establish logical divisions in order to understand its structure, report its progress, and to get deeper control of it. These logical divisions are called phases and can be used to avoid control getting diffuse when projects are too complex or large. Normally, they are created to relate them to a certain function or group of deliverables and, in most cases, should be attended or carried out differently. The communication strategy might differ from one phase to the other (Verma, 1996). Furthermore, sometimes different project managers are needed to manage them.

Phases are made previous to the first stage in a highly detailed concept. As the project progresses and knowledge about its characteristics grows, the phases are updated in deeper detail. It is common and useful to relate phases with the first level of the work breakdown structure (WBS). Phases and Project Management Process Groups Phases should not be considered the same as the Project Management Process Groups mentioned in PMBOK Guide—Fourth Edition (p. 41). Although sometimes the Project Management Process Groups are related with the PLC that is not appropriate. Let me explain why. First, the phases of the PLC are created, changed, or adjusted based on what kind of project they are going to be applied; notwithstanding, the Project Management Process Groups are always the same in all kind of projects. Second, the PLC has its own deliverables that are only related to the product or service being delivered, which are different from the deliverables produced with the Project Management Process Groups. In this case, they are related to the activities that the project management team does during the project; sometimes those activities may cross different phases or be within them.

®

Creating Phases in the PLC We should bear in mind that there is no single way to define the ideal structure of a project (see PMI, 2004, p. 22). To create the phases, we must consider the type and quantity of deliverables included. At the end of each phase, if it is not the last one, a hands-off process should be accomplished. Also, each phase in the life cycle has their own characteristics and produces outputs that serve as inputs into the next phase. As projects grow in size, it becomes clearer which phase(s) should be used. PLC comprises the stages of a project from beginning to end (Newell & Grashina, 2004). Defining a PLC Then, should we consider the PLC a pre-existent entity? Yes, we should, if it is already created. But if it is not the case, then we should create it for the first project. Then, we would already have it used and tested once the first project finishes and ready when the next project begins. It is important to keep in mind that there is no unique and standard project life cycle applicable to any situation. Therefore, must we create a new one each time a project starts? Also, should we consider creating it from scratch every time? Not at all, we should get the one that the organization uses as the standard for that type of project and create it only just for

PMI Virtual Library | www.PMI.org | © 2009 Andrés Falcón 6

the first time each type of project appears in your organization. Most of the time, PLCs from different organizations in the same industry are very similar. In those situations, there is the advantage of getting it from another organization in the same industry. Then you have a preapproved and used PLC that, if necessary, can be adjusted to your needs. As project management knowledge has been used for several years, it is not unusual to find many cases of PLC implementations in the same industry, in almost all industries. For example, the software industry has a variety of different kinds. Then, if many industries have created some standard PLCs, why should we bother having one of our own? Even though we can take one from the industry, our company has its own criteria, metrics, and control depth definition that may impact the structure of the PLC, so adapting it would be the normal path. Once it is adapted, it will be used in the manner specified. Those are the ones that would be improved with use. So, what should we consider to adjust a PLC? We need to analyze some variables such as type and size of the projects, checkpoints required, quantity and types of deliverables, areas of the organization and teams involved, working methods among of the teams participating and other context characteristics (e.g., financial structure, etc.). Finally, having a standard PLC in each organization is always a good practice, whether it is taken from the industry or created it from scratch. Adjusting a PLC Since what should be done depends on where you are in the PLC (Frame, 200, p. 28), establishing a life cycle for a project must be the first step in your planning process, and then it should guide the rest of your work throughout the project. Certainly, the PLC is the primary project structure. We can use the PLC as step one of our WBS—essentially a phaseoriented WBS. Recognizing and using the PLC structure is important to identify and organize the work associated with the project (Levine, 2002). On the other hand, you should be aware that not all projects can be simply transposed into life cycles; for example, research and development (see Kerzner, 2003, p. 81). Each organization should define, and have at hand, its own PLC set. The organization, or the project management office, should typify their projects to attend different needs they may have and generate a set of project types. Once the set and PLCs are defined, it should be considered as a common reference tool and be used in each project. The improvements come with its use, and then a relationship

table between types and PLC is always a good tool to have at hand. PLCs Models As we mentioned earlier, since the project management discipline is not new, many completed projects have given us several tested PLC models, and thanks to their validations, they are classics by now. There are many examples of PLC in software industry, including: Pure Waterfall, Spiral, Modified Waterfall, Evolutionary Prototyping, Code-and-Fix, Staged Delivery, Evolutionary Delivery, Design-to-Schedule, Design-to-Tools, Off-The-Shelf, Sashimi Model, Extreme Models, Rapid Application Development, V-Model, Dual Vee Model, RUP, etc. Each one has its own characteristics and strengths and weaknesses (www.business-esolutions.com/islm.htm; http:// en.wikipedia.org/wiki/Waterfall_model; http://en.wikipedia. org/wiki/Incremental_build_model; http://c2.com/cgi/wiki/ wiki?HistoryOfIterative; and http://alistair.cockburn.us/Incre mental+versus+iterative+development). Acknowledgments I would like to thank everyone who helped with this paper, especially Veronica Cvitkovic and Nicolás Rigo. References Frame, J. D. (2003). Managing projects in organizations: How to make the best use of time, techniques, and people (3rd ed.). San Francisco: Jossey-Bass. Kerzner, H. (2003). Project management: A systems approach to planning, scheduling and controlling (8th ed.). Hoboken, NJ: John Wiley & Sons. Levine, H. (2002). Practical project management: Tips, tactics and tools. Hoboken, NJ: John Wiley & Son. Newell, M., & Grashina, M. (2004). The project management question and answer book. New York: AMACOM. Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK guide) (4th ed.). Newtown Square, PA: Project Management Institute. Project Management Institute. (2003). A guide to the project management body of knowledge (PMBOK guide) (3rd ed.). Newtown Square, PA: Project Management Institute. Verma, V. J. (1996). Human resource skills for the project manager: The human aspects of project management (Vol. 2). Newtown Square, PA: Project Management Institute.

® ®

About the Author Mr. Falcon is available via e-mail at [email protected].

PMI Virtual Library | www.PMI.org | © 2009 Andrés Falcón 7