An Editorial Observation
The Project Management Institute's Guide to the Project Management Body of Knowledge (PMBOK ®) states that the measure of project success is based on the four pillars: scope, time, cost, and quality. Now go ask a C-Level or B-Level manager what are the attributes of a successful project and she'll likely say: profitability, delivery of value, saleable content, return on investment.
In the past, business executives may have been interested in answering the question" when will this project be completed, and how much will it cost when it is?" This is a context free question however. Any manager in a business organization these days will ask those questions as a start, but will also ask: "how will this project meet it's business goals, what risks are there to the business process? What value is delivered when we're done here? What does done mean?"
A typical discussion about PMBOK® goes like this..."Project Management and Product Management are separate discussions. The discussion of project management is the empty domain of the PMBOK®, while the discussion of product management is the domain of business."
Some background quotes to establish a context...
This suggestion is not just hearsay it is the premise put forth by some PM thought leaders.
"... product-oriented processes are excluded from the definition of project management ..., and I don't see a need for a technically skilled project manager ...."
So how are these "project processes" to be used in the context of a business or product delivery method? Are the PMBOK® "processes" in fact context-free? Are they separate from the business of managing the development of products or services? Can project management as a profession have any relevance in the presence of this domain, that is context-free approach to the profession?
If we look around the literature sources we'll find lots of material on managing product development. The majority of these materials are labeled "Project Management." Is this the same Project Management discussed in the "process" approach to project management - it appears not to be.
So What's Missing...
Missing is the acknowledgment that a "process" oriented approach is not sufficient. Putting the processes of PMBOK® to work in a context is not only necessary it is mandatory for the profession. But what context? Software development? Construction? Hard goods manufacturing? Aerospace? All have unique context dependent needs.
Software development is especially sensitive to its context when it comes to project management. The assumptions that "normative" and "rational" processes exist in software development is a myth. Applying the processes areas of PMBOK ®without this understanding will lead to failure. So one question results - does the PMBOK® have anything to contribute to software development? The literature of software development project management makes hardly a mentions of PMBOK®. Is this a failing of the software project management domain, or the failure of PMBOK®? This is likely an argument without end.
One approach is to look at the mainstream and fringe software development PM processes and try to find PMBOK® elements. Would this provide value? Maybe. But for what real purpose? Aren't the basic principles of software development management self-evident in the literature. Winston Royce's 1970 paper at WESCON defined the essence of managing software development. Many advances have been made since then, but the core processes were laid out there. What does PMBOK® bring to the party in this context? It restates the documents, processes, and sequences of steps used to manage a project. But does it add value to software development management? This is the question for the professional project manager. Our opinion is it adds little to the process, once the core processes are found in an acceptable "method."
This is the key. PMBOK® is not a method (nor do the authors claim it is). But as a non-method, PMBOK® leaves the PM professional without the tools to move forward. Methods are the means to problem solving. Without methods, the discipline of project management is simply a list of processes - it is context free. Interesting perhaps to the Project Management Professional (PMP®) testing suppliers, but not too interesting to those asked to manage a project in a specific context.
So can we move on from PMBOK® discussions to context based PM discussions? It seems hard to do for some reason. Without a context, we'll be relegated is "has beens" while the world moves one to new and valuable methods of delivering products and services.
If we take the description of project management from the PMI site, http://www.pmi.org/info/PP_AboutProfessionOverview.asp. An analogy would be like giving someone a dictionary, thesaurus, and the Chicago Manual of Style and asking them to produce a creative writing artifact. The dictionary, thesaurus and the style manual are necessary but far from sufficient to produce a good story.
The Project Management Institute's Guide to the Project Management Body of Knowledge is a "Knowledge Structure" most suited to teaching and hence for "education". Why then do so many people insist on using it as a "methodology"? The answer is easy because people want to know how to apply it. Until the distinction between knowledge and methodology is recognized we are not going to get past the present dichotomy.