With project delivery approaches evolving more rapidly than ever before, there is no singular way to deliver outcomes. This is why our new standard in project management will shift from a process-based standard to a principle-based one. Here’s what that means.
Process-based standards, while effective in supporting good practice, are prescriptive by their very nature. The focus on process results in a standard that cannot reflect the full value delivery landscape of approaches, and cannot rapidly evolve with the profession. By shifting to a principle-based standard, PMI can reflect effective management of projects based on predictive, agile, hybrid, or emerging approaches. (This is in alignment with other recently published standards.) Learn a clever way to tell the difference The principles, which are under development, will be built around a set of statements. The principle statements capture generally accepted objectives and underlying concepts for the practice of project management. Then, the principle statements provide broad parameters within which project practitioners can operate and still remain aligned with the standard. The result of this transformation will be a standard that reflects our current and future practitioners’ needs – and remains relevant as practitioners identify the appropriate approaches to deliver outcomes.
PMBOK® Guide 7th edition: Interesting Changes
By Nader K. Rad
As some of you know, I’m a member of the core development team (12 people) responsible for the next edition of the PMBOK Guide, and we’ve recently started our project.
I’m glad to announce that there’s going to be an exciting change in the 7th edition of the PMBOK Guide: It’s going to be principle-based instead of process-based.
So, I’m going to briefly explain what this change means from my point of view (this is not an official article from the team/PMI).
The Process-Based Standard
All previous editions of the PMBOK Guide have been process-based, meaning that the primary, fundamental building blocks were processes, with their inputs and outputs connecting them and creating an integrated network that can be effective in projects.
Although invaluable, the difficulty with this approach is that the processes can be either high-level, which makes them more abstract and less practical, or detailed, which makes them more dependent on the type of project, and so probably not applicable to all.
On the other hand, a process-based perspective is limited to what is considered in the standard, while it would be more helpful if the standard provides something that can be useful even in unexplored situations.
The Principle-Based Standard
One solution to the difficulty I mentioned above is to change the perspective of the standard. Instead of explaining the project management processes (and related activities) that are probably needed for the project, it can describe the most effective way of carrying out activities. This approach can benefit anyone who’s leading a project, regardless of the delivery method, management methodology, etc.
As an example, my all-time favorite principle is that we should have a purpose for everything we do (NUP5): If you want to prepare a business case, do it only if you have a purpose and can use it to improve something in the project, and not just because everyone else is doing it, and not because project management resources say you should do it. When you prepare a business case with a purpose in mind, the chances are much higher that it can serve the purpose and play a positive role in the project rather than being a bureaucratic annoyance. If you’re using an Agile approach to the project, you need to understand and consider the purpose of incremental delivery and iterative development, and let those increments really serve the project and make it adaptive, rather than just imitating the rituals and artifacts that others have used in their Agile projects and hoping to get the same results (which is a form of Cargo Cult).
What Will the Principles in the PMBOK Guide 7th Edition Be?
We will be working on the principles for a while, and when we’re done, an internal draft will be prepared for the review team (70+ people). We will receive their suggestions and use them to refine the principles, and then a public exposure draft will be released to everyone. At that point, anyone interested can read the new standard and give us comments, which we will again use to refine the standard before releasing the final version.
Since this is a work in progress, I can’t talk much about the principles now. However, we have decided to publicly state the fact that the new version is going to be principle-based (as you see here), to prepare the community for their upcoming participation.
Meanwhile, to get an idea of the possibilities, you can check out NUPP (Nearly Universal Principles of Projects), which has the same approach and goal. I started working on NUPP about a year ago, and it was released just a few months ago. To be sure there’s no misunderstanding, NUPP is just one way of structuring and suggesting principles, whereas those in the PMBOK Guide will be developed by a team of 12, with more diversity and new ideas, so it will not be the same as NUPP.
Soon you can find more information about the 7th edition of the PMBOK Guide in The Critical Path Blog, and especially, the announcement about the exposure draft and the invitation to contribute.
I hope we can do a good job and provide the community with a new standard that can solve more problems. Wish us luck :)