I was recently reviewing and providing feedback to the early draft of the PMBOK 7th Edition. I was so happy to see that the authors are taking a very fresh approach of completely throwing out the old Knowledge Areas / Process Groups framework and replacing it with a more flexible and adaptable set of Principles. Not surprisingly, the new Principles can be directly mapped to the Agile values and principles, yet they are foundational enough that they can be applied to more traditional projects as well.
This is a big shift from the PMBOK 6th Edition where there were some token Agile mentions, but they seemed bolted on top of the old process-based framework. The 7th Edition is truly a revolutionary departure from the old PMBOK as we know it, for good!
...
As I was reading the Principles draft, I kept wondering:
"Hmm, if they removed everything else, did they also remove the "project" concept?!?"
Agilists generally dislike the project-based paradigm and prefer to think and talk in terms of 'product,' 'flow,' or 'value stream.' For historical reasons, the word project has too much 'waterfall' connotation implying that the endeavor has a predefined end date and an expected, set-in-stone output. I was fully anticipating there will be some changes around the project concept as well...
... but to my biggest surprise - there still was the good o'le project definition:
“A project is a temporary endeavor undertaken to create a unique product, service, or result.”
How's one (Agilist) to reconcile a new Agile-friendly PMBOK with an old "project" definition!
I, myself, did a few mental flips going back and forth – if they/PMI want to join the cool-kids wagon-of-Agile, they should get rid of “project” or just change the definition!
However, upon a careful (re)read:
“A project is a temporary endeavor undertaken to create a unique product, service, or result.”
“Definite end" does not mean "pre-defined end", it means that there is "an end." (One ought to agree that anything that has a beginning must have an end.) Agile efforts too have a definite beginning (someone has an awesome idea and gets the funding to execute it), and a definite end (the idea is materialized, the money ran out, the idea is no longer awesome, or a new awesome-r idea came along). There might be multiple iterations and increments to get there, but the definition is non-prescriptive for what happens in the middle between the beginning and the end.
The definition also talks about “unique" outputs* ("product, service, or result"), but nowhere it says they must be pre-defined and delivered all at once. The definition itself is open to iterative delivery and adaptation. The keyword here truly is "unique" to distinguish project delivery from operations. (And before the DevOps folks come after me, distinguishing the two doesn't necessarily put boundaries and silos between them. The PMBOK is simply not meant to govern and standardize Operations (Business or IT). Not to mention that nowadays, IT Ops with all the DevOps automation, Infrastructure as Code, and "pushing to the left" is a lot more akin to project delivery than operations.)
(* Yes, we all agree outcomes are more important than outputs as a measure of success! And there is plenty of discussion on that in the 7th edition. )
It turns out, and to my personal surprise, that the project definition itself has been very broad and open all along. It is just our conditioning to think and associate projects with waterfall execution that gets in the way.
Looking at it with fresh eyes, large Product Epics (or even Program Increments and Releases) do fit quite well the above definition and could be considered (mini) projects. Epics do have a definite beginning, a definite end, and they are expected to deliver unique results expressed as Acceptance Criteria. (The Epics are funded and managed very differently, but again - the project definition itself is broad enough and not bound to the funding or management approach.)
This was the long way to get to the bottom-line question: (re)reading the “project” definition with an open mind, do you still see it as a fundamentally anti-Agile concept. Why?
Comments