In a previous article, we discussed a few gaps in the PMBOK® Guide. That topic is a chapter in an upcoming e-book on how the guide current reality. In another e-book, we discuss improvements to the guide; this article is a chapter in this second e-book.
- A methodology,
- Organizational system,
- Tailoring and customization,
- Project classifications,
- Templates and forms,
- Project life cycle,
- Benefits realization, and
- References for external resources.
Since the PMBOK® Guide design is to be a generic guide it cannot be a method and our recommendation is to keep it that way. The guide should not offer a method, and this point need to be stressed, more than it is now. Therefore, adding a few sentences in various places explaining why the guide is not and cannot be a method would be of significant benefit.
The basis of the PMBOK® Guide is that it covers the processes required to manage a single project (a generic project). It is also designed on the basis that an organizational project management (OPM) system already exists. We agree with this approach and emphasize that the guide should not include an OPM system. This recommendation is for two reasons:
- The guide is not the proper platform to include an OPM system.
- OPM systems must be highly tailored to the organizational and project context and would not be practical to address here.
Therefore, our recommendation is to emphasize this principle in various part of the guide and show examples to help visualize the link and differences between an OPM system and the actual processes to manage a project.
Tailoring and customization
The PMBOK® Guide does not include industry/application area specific processes or knowledge areas. This situation is perfectly acceptable and should be emphasized in the same way as the previous two points.
We have a dedicated chapter on this topic in Section II.
Templates and forms
The guide is not a manual and cannot be and should not be. Templates and forms should be part of the organizational project management system, as discussed already.
Project life cycle
Since the guide is not industry or domain specific and is not a method, it cannot offer a fixed project life cycle. However, to remind the reader, in the earlier editions, the PMBOK® Guide used to show sample project life cycles from different industries. That was helpful, and we do recommend adding a few images showing the project life cycles from various domains.
It would also help if the PMBOK® Guide shows how the process groups relate to the phases of these project life cycles, but that is also a dedicated chapter in Section II.
Benefits realization and new project definition
Benefits realization is directly related to the definition of what is a project.
The definition of project in the guide focuses on the output – the output being a product, service, or result (The Project Management Institute, 2013). However, projects are about delivering an outcome and realizing the benefits expected when the project was approved. Therefore, it is important to distinguish between output and outcome and change the project definition accordingly.
The current definition of a project is “A project is a temporary endeavor undertaken to create a unique product, service or result.” (The Project Management Institute, 2013) Our recommended revision of the definition of a project would be to add: ‘and deliver benefits to the organization.”
There are many reasons for this recommendation:
- It emphasizes that projects are about delivering benefits and not just outputs.
- It encourages, or mandate, the team to define criteria for measuring success.
- It also clarifies the need to have a dimension for measuring success that is not limited to technical delivery of the output or time and cost.
- It will help minimize the confusion between projects and sub-projects or phases since each phase or sub-project deliver an output and cannot deliver benefits until all of the parts are connected.
- The previous point also helps clarify the different between projects that have phases and sub-projects, each delivering an output but not benefits; and programs that have projects each delivering benefits independent of the overall program benefits.
References and external resources
The recommendations here are obvious and would align with the three points we raised in Part 1. These are:
- Provide references and credits to the source of the content like all publications are obligated to do.
- Eliminate the PMI mandates that the volunteers assign their copyrights to PMI for any content that they submit. The volunteers can assign PMI the rights to use the information, but the original contributor also retain ownership. This is a form of joint ownership.
- It would be good if the guide includes references to other publications and resources that would help the practitioners, even if PMI does not publish it. There are many organizations that publish resources that are more in depth than what PMI covers, for certain topics. Examples of this would be what is published by the International Project Management Association (IPMA), The Association for Advancement of Cost Engineers (AACE) International, and numerous others.