“After all, when you come right down to it, how many people speak the same language even when they speak the same language?” Russell Hoban quotes
“The LORD said, “If as one people speaking the same language they have begun to do this, then nothing they plan to do will be impossible for them. Genesis 11:6
The Rosetta Stone is a granodiorite stele found in 1799, inscribed with three versions of a decree issued at Memphis, Egypt in 196 BC during the Ptolemaic dynasty on behalf of King Ptolemy V. The top and middle texts are in Ancient Egyptian using hieroglyphic script and Demotic script, respectively, while the bottom is in Ancient Greek. As the decree has only minor differences between the three versions, the Rosetta Stone proved to be the key to deciphering Egyptian hieroglyphs. (Wikipedia).
And that is a core value of the PMBOK!
In several of my posts I critiqued the Sixth Edition of the PMBOK by going into the detail of what is contained there. I think that it is incumbent upon Project Mangers around the world to use their “real world” experiences to ensure that the PMBOK reflects the most current and best thinking about project management. It is also important that the predictive and adaptive project management tools and techniques are continually compared and contrasted so they are the best that they can be.
Stepping back from that, what is the real value of the PMBOK? One key value is that it provides a common framework (language) for project managers around the world to hold intelligent discussions about project delivery! I do many international facing projects, and when I say the word “requirements” virtually everyone understands what that term refers to. That common understanding means that we can focus on the process immediately and speeds product to market.
This is true of all the core concepts such as scope, cost, schedule, baseline, risk, quality and change control. Each of these terms of art hold a specific meaning that allows professionals to jump start project regardless of where they are working! Note I specifically left out configuration management. In my experience, project management professionals often disagree as to exactly what that process is supposed to accomplish and the correct way to implement it. You can find a more in-depth discussion of that (and other articles) at www.projectmanagementforum.net.
The PMBOK helps agile and predictive projects share a common language. Let’s examine requirements. Predictive projects gather detailed requirements and decompose them into Work Packages with the ultimate product being the development of a Work Breakdown Structure. That serves as the basis for the project baseline by facilitating an understanding the nature of the work, how long it will take and what it will cost. Agile projects generally start with a Feature or Epic and decompose that to a User Story, then to a Task. That is also used to understand the nature of the work and how much can be accomplished given the time and funding the project is allocated.
In both instances, everyone knows we are referring to requirements. And we can thank the PMBOK for that common understanding.
The PMBOK terms of art are also very helpful in communicating technically complex project management principles to non-project stakeholders. An example of this is Scope Creep. The technical challenges a project manager faces in ensuring that only the work of the project is being done and that all proposed changes are assessed and disposed of through Integrated Change Control are very difficult! However, a term of art like Scope Creep is very descriptive. Stakeholders can easily understand the concept, and that is invaluable to the project manager as they gain support for a robust Change Control process.
The terms, processes and procedures are also universally understood within other project management frameworks such as PRINCE2. While PRINCE2 is viewed as a different methodology, a quick glance through the principles, themes and processes will be familiar to anyone with a Project Management Professional® certification! I was recently involved in an international project where PRINCE2 was used, and the project manager and I spoke the exact same “language” in governance meetings. This greatly simplified things.
The same applies to the International Organization for Standardization (ISO) document 21500, which provides projects with core principles and good project management practices. I have worked on projects where ISO 21500 was a heavily reference document. Anyone with a working knowledge of the PMBOK would feel comfortable following these principles and would understand the governance framework of the project.
The PMBOK serves as a Rosetta Stone for project management terms and principles, and provides a universally recognized framework for project delivery. It is also compatible with almost every other project management framework in common use today. While we have an obligation to point out flaws or suggest improvements, the document’s impact and usefulness is profound.
Coda
I spend a lot of time thinking about interesting topics for these posts and focusing exclusively on project management while not getting bogged down in heavy technical areas is a challenge. The topic is rich, but it can be repetitive if you aren’t careful. A few days ago, I had a conversation with a friend of mine who reminded me of my first job as a bag boy for Piggly Wiggly® Southern. After reminiscing about that job and the positions I held there, I realized that although I have had an extraordinary amount of education, all the real-world management lessons that have made me successful were learned at Piggly Wiggly! I think I’m going to explore that a bit.