By Cyndi Snyder Stackpole, MBA, PMP
26 Jan2009
26 Jan2009
A lot of people are wondering what is going to change with the PMBOK® Guide: Fourth Edition. There is not that much that will change with regards to the content. There are a few additions and deletions to processes, but mostly of the work was done in making the standard internally consistent. We wanted the chapters to feel more cohesive as if one person wrote the standard instead of a group of people.
In addition to internal consistency, our charter required that the PMBOK® Guide: Fourth Edition be aligned with The Standard for Programme Management: Second Edition and The Standard for Portfolio Management: Second Edition. We accomplished that by having one person architect and layout chapters 1 and 2 across all three standards so that they are in agreement. This is not to say that they are identical, but the chapter structure is aligned and the content is not contradictory. There are several figures and tables that are identical across the standards to keep a consistent message when talking about the relationship between the standards.
Another step in making the standard consistent is that all process names are now in the same verb-noun format. And the inputs and outputs have a similar sequence. For example, for those processes that have enterprise environmental factors and organisational process assets as an input, we have listed these as the last inputs and have listed some examples that might apply. We have sequenced common outputs such as change requests, project management plan updates and project document updates. Like the common inputs, we have included examples of plans and documents that might be updated.
The concept of project documents is new to the PMBOK® Guide: Fourth Edition. The project management plan contains plans and baselines that are used to plan and control the project. However, there are many other documents that project managers use to help carry out the project. These are called out specifically as project documents. Examples include issue logs, duration estimates, resource requirements, change logs, etc. While not part of the project management plan, they are important tools used to keep projects on track.
In addition to clarifying the difference between the project management plan and project documents we also made a more definitive distinction between contents in the project charter and the project scope statement. The charter contains more information, but it is at a high level. The scope statement does not progressively elaborate as much of the information. It does elaborate some information, but it also contains separate information such as the project boundaries.
We have lumped together the change request, corrective action, preventive action and defect repair grouping into one heading called change requests. Where appropriate we distinguish the type of change request such as a preventive or corrective action and provide examples that might be relevant.
A final change to the inputs and outputs is that we did not have the project management plan as an input to any planning processes. While understanding that planning takes place throughout the project and that the planning project group is not a phase, we felt it would be clearer to have the specific planning process outputs as inputs to developing the project management plan and not the other way around. However, in the executing and monitoring and controlling process groups the project management plan is a key input, and the specific components are listed under the project management plan. For example, the cost performance baseline is an element of the project management plan and an input to the Control Costs process. The input is listed as the project management plan with a notation that the element in the project management plan is the cost performance baseline. This approach brings a cohesive and consistent approach to the processes across the document.
A final note change in the look of the Fourth Edition is the graphics. The figures that showed the data flow at the start of each chapter in the Third Edition were a great addition. The Fourth Edition has expanded on that concept. The figures at the beginning of the chapter have been deleted, but they have been replaced with a data flow diagram for each process. The data flow diagram shows where the inputs come from and where the outputs go to. These figures help emphasize the process orientation of the PMBOK® Guide.
In addition to internal consistency, our charter required that the PMBOK® Guide: Fourth Edition be aligned with The Standard for Programme Management: Second Edition and The Standard for Portfolio Management: Second Edition. We accomplished that by having one person architect and layout chapters 1 and 2 across all three standards so that they are in agreement. This is not to say that they are identical, but the chapter structure is aligned and the content is not contradictory. There are several figures and tables that are identical across the standards to keep a consistent message when talking about the relationship between the standards.
Another step in making the standard consistent is that all process names are now in the same verb-noun format. And the inputs and outputs have a similar sequence. For example, for those processes that have enterprise environmental factors and organisational process assets as an input, we have listed these as the last inputs and have listed some examples that might apply. We have sequenced common outputs such as change requests, project management plan updates and project document updates. Like the common inputs, we have included examples of plans and documents that might be updated.
The concept of project documents is new to the PMBOK® Guide: Fourth Edition. The project management plan contains plans and baselines that are used to plan and control the project. However, there are many other documents that project managers use to help carry out the project. These are called out specifically as project documents. Examples include issue logs, duration estimates, resource requirements, change logs, etc. While not part of the project management plan, they are important tools used to keep projects on track.
In addition to clarifying the difference between the project management plan and project documents we also made a more definitive distinction between contents in the project charter and the project scope statement. The charter contains more information, but it is at a high level. The scope statement does not progressively elaborate as much of the information. It does elaborate some information, but it also contains separate information such as the project boundaries.
We have lumped together the change request, corrective action, preventive action and defect repair grouping into one heading called change requests. Where appropriate we distinguish the type of change request such as a preventive or corrective action and provide examples that might be relevant.
A final change to the inputs and outputs is that we did not have the project management plan as an input to any planning processes. While understanding that planning takes place throughout the project and that the planning project group is not a phase, we felt it would be clearer to have the specific planning process outputs as inputs to developing the project management plan and not the other way around. However, in the executing and monitoring and controlling process groups the project management plan is a key input, and the specific components are listed under the project management plan. For example, the cost performance baseline is an element of the project management plan and an input to the Control Costs process. The input is listed as the project management plan with a notation that the element in the project management plan is the cost performance baseline. This approach brings a cohesive and consistent approach to the processes across the document.
A final note change in the look of the Fourth Edition is the graphics. The figures that showed the data flow at the start of each chapter in the Third Edition were a great addition. The Fourth Edition has expanded on that concept. The figures at the beginning of the chapter have been deleted, but they have been replaced with a data flow diagram for each process. The data flow diagram shows where the inputs come from and where the outputs go to. These figures help emphasize the process orientation of the PMBOK® Guide.
Thanks
ReplyDelete