Project Management

A Common-Sense Guide to the PMBOK Program, Part Two–Plan and Execution

James W. Marion

• Publisher: Momentum Press
• Year: 2018
• ISBN:
  9781949449082
• Topic: Technik & Maschinenbau
• Subtopic: Projektmanagement im Maschinenbau

This book clarifies the differences between plans and schedules, takes the project manager through the process of plan development, and finally, points the way toward successful project execution.

Although the terms "plan" and "schedule" are at times used interchangeably, they are in fact very different. A complete project plan contains a project schedule—but it also includes much more than that (e.g., risk management, quality management, human resource management, and procurement). These differences have implications for the layman as well as the experienced project manager and have implications for successful project management practice.

Additionally, the contents of the project plan have evolved over time as versions of the Project Management Body of Knowledge (PMBOK) were updated. Due to this, project plans today include important elements that were not included in project planning in the context of earlier versions of the PMBOK and the execution of the project plan requires guidance beyond that which is outlined in the PMBOK framework. The PMBOK emphasizes planning and monitoring and controlling—but very little support is provided for project executing. This begs the question, just what does it mean to execute a project plan?

PART I

UNDERSTANDING THE PROJECT PLAN IN THE SIXTH EDITION OF THE PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK^®)

THE PROJECT PLAN—AND ITS EVOLUTION

Completing a project plan as described by the Project Management Institute is different today than it was 10 to 20 years ago. The processes associated with the development of a project plan have been updated over the years since the first PMBOK guide was published. Understanding how to develop a project plan today requires an understanding of the current PMBOK framework. This is a much easier task if the current guide is understood within the context of its evolution. In 2017, the Project Management Institute introduced the sixth edition of the Guide to the Project Management Body of Knowledge or PMBOK^®. When encountering this process framework for the first time, the 49 different processes, including five process groups in 10 knowledge areas, will likely seem difficult to wade through and apply at first. However, if the rationale behind the framework as well as how the framework has evolved over time is better understood, developing a project plan using the PMBOK will likely make more sense. This is made especially clear when the current PMBOK is compared to the fourth edition launched 10 years ago. Examining the PMBOK^® from the fourth through sixth edition will aid in understanding what the framework does, and why it does what it does as well as its underlying intent.

WHAT IS IT?

What is the project management framework anyway? It is a process-oriented series of guidelines for project managers. One of the reasons that the PMBOK framework is process oriented is that the management of projects occurs outside the normal ebb and flow of ongoing operations. It therefore requires policies, procedures, and processes to govern it. The fact that projects are different than ongoing operations becomes obvious when examining the framework beginning at the top left-hand corner of the framework (Table 1) at the intersection of the “Project Integration Knowledge Area” and the “Initiating Process Group.” Integration implies “summing up” or tying things together—and this is exactly what is done when the project charter is created. The project charter authorizes the project using formal documentation that advises all project team members (as well as all who have an interest in the outcome of the project) of the authority granted to the project team to carry out its mission. In an ongoing operation, the head of the department may verbally assign work to individuals or teams without a documented charter. The department and hierarchy of leadership are already authorized to do their ongoing work—so only in the project context is such authorization truly necessary. The project team once assigned may draw people from different functional groups and interact with different departments—and the charter enables this. This one simple example helps explain the need for a project management framework that governs the sequence of events from starting a project, planning it, carrying it out, finishing it, as well as listing the subject areas project managers need to know within these processes. The framework is not only useful—it is a necessity for planning and executing project work.

THE STARTING POINT FOR USING THE FRAMEWORK

The project charter example implicitly illustrates how to go about using the framework. Rather than thinking of it as “49 processes,” think in terms of the five process groups. Every project must be started, planned, carried out, followed-through, and finished. This commonsense series of steps for completing any type of work is captured in the five process groups that are labeled “Initiating, Planning, Executing, Monitoring and Controlling, and Closing.” The five process groups have not changed since the fourth edition of the PMBOK (Table 2). But, the processes that exist today in the sixth edition within each of the process groups have evolved considerably over 10 years. The process changes are found within the knowledge areas of the PMBOK. Knowledge areas are those specific skills, knowledge, or domain expertise that must be applied in the process groups to get the work of the project accomplished. While the process groups clarify the order of events or the steps in the process, the knowledge areas provide a content view—or what needs to be done at each step. The flow of PMBOK processes remains very similar when comparing PMBOK 5 and 6 (the current and previous edition of the framework), but as the PMBOK has evolved more direction is provided in knowledge areas and, in some cases, additional knowledge areas are given to support project activities. This is a consequence of the evolution of the field of project management over time. To fully understand the framework that exists today, it helps to understand what came before. The examination of the sixth edition therefore begins with understanding what changed between versio...