In part one of this thread we looked at how the PMBoK® Guide is a framework of processes that can be used to initiate, plan and then manage a project through to closure. In part 2 we’ll start looking at how much value the PMBoK Guide offers real world projects. Are the processes practical? Are they really useable across a broad range of project types?
To start to answer those questions we need to first understand the range of different types of project that exist. In reality there are of course a wide range of different project types. Each of which have different characteristics and hence require different management techniques to ensure success. There are big projects and there are small projects, there are simple projects and there are complex projects. Although all projects have a start, need some sort of plan, have a middle and then come to an end, it is hard to equate the project that put man on the moon with a more humble project that involves painting a house.
Because the Guide is intended to be useable across a wide range of project types, the processes in the Guide need to be robust enough to cover the extremely large projects (billions of dollars), while being flexible enough that they are still applicable to much smaller ones (tens or hundreds of thousands of dollars). To achieve that goal, the writers of the Guide have documented a very robust framework first (i.e. one that is suitable for the very large projects) and then request that the reader scales the processes back to the point where they are appropriate if you are managing smaller projects.
The challenge of course lies in learning how to scale the processes to make them suitable for smaller projects. Unfortunately the Guide gives no direction on how to do that. That missing piece is one of the keys to understanding some of the criticisms you sometimes hear about the Guide. Among the common criticisms is that the Guide encourages Project Managers to create too many documents (there are about 70 types of documents listed as outputs from the processes in the Guide). If you were to create all of those documents you could end up with a mountain of paperwork. On a larger project (billions of dollars) it may make sense. In a small project it makes you look like a paperwork-obsessed bureaucrat who is out of touch with the realities of today’s workplace.
Sadly, it is not unusual to see people doing just that. They blindly apply the processes intended for very large-scale projects to small scale projects and end up using a sledge hammer to crack a nut. Spending their days buried in paperwork they are heads-down in their cubes rather than heads-up interacting with the stakeholders and engaging the team. In this case the fault is not with the Guide, the problem comes down to the fact that some of the available training classes out there do little to help people understand the framework properly and say little if anything about how to scale the processes.
While size is one dimension, there is another important dimension that warrants discussion. Of the many possible factors that you could use to categorize projects, to me one of the most important is the stability of the requirements. There are projects where the requirements are relatively clear, can be properly documented and remain relatively stable throughout the project. There are others where it is hard to know what the real requirements are and as the project moves forward requirements emerge, mature or even morph.
To illustrate the continuum consider the two extremes. At one end is a construction project in which a house is to be built from standard, pre-approved building plans. The presence of the blueprints means that the requirements are relatively stable. Yes there are likely to be some changes along the way, but as a whole the body of the requirements should remain relatively stable. Contrast that with a political campaign in which the campaign manager (the Project Manager) may have some overall themes they are working with but need to constantly react to the latest cycle of news, political polls and unfortunate gaffe’s their candidate or the opponents may have made.
Where requirements are stable, we are able to create detailed plans to guide the execution of work. Where requirements are volatile or emergent we need to use more fluid and dynamic plans. While the Guide is intended to be a very flexible framework, to me there is little doubt that the essence of the framework does lean towards the “stable requirements” end of the continuum. Although the Guide suggests the use of rolling-wave planning and progressive elaboration, the comprehensive nature of the processes in the Guide do imply more detailed plans than more fluid ones.
In part that tendency comes from the history of the Guide. In speaking with Mr Max Wideman (the chairman who oversaw the creation of the earliest versions of the Guide) the early precursors of the Guide were largely influenced by projects from the ECP sector (Engineering, Construction and Procurement). Such projects are often very large scale, but the presence of engineering blueprints for the product being produced usually means that the requirements are towards the more stable end of the continuum. This time I think it is the Guide that is partly at fault. Perhaps because of its historical roots, the handling of the more volatile projects is not very clear. In principle there are words in the Guide that give hints at what to do with projects that are volatile, I think in reality the treatment of those projects is not very strong.
Perhaps because they recognize that the traditional PMBoK Guide has not been a great fit to the more volatile types of projects, the Project Management Institute (PMI®) has recently introduced the new “Agile Certified Practitioner” (PMI-ACP®) exam. This extension of the practices in the full PMBoK Guide is largely focused on software development projects, but does offer a broad roadmap of ideas, tools and techniques that can add value to projects in the volatile zone. Using “adaptive lifecycles” and techniques that apply the “progressive elaboration” concept in ways that allow the requirements to shift as the project progresses, these “agile” practices are better suited to projects at the volatile end of the continuum. I think this extension to the original materials is a good idea and although the PMP® exam is the more prevalent designation, I do encourage all professional Project Managers to understand both the PMBoK Guide based processes as well as the concepts in the agile extension.
In conclusion, the issues of how to scale the PMBoK Guide framework and how to apply the framework to the volatile end of the project continuum are two additional areas that leave the PMBoK Guide and the PMP certification process open to criticism. Again my own feeling is that the core of the problem really comes down to the teachings rather than the content. When instructors lack the depth of knowledge needed to see these issues, students leave class with a superficial understanding of things and then dive headfirst into some of the traps outlined above (failure to scale appropriately, failure to adapt to situations in which the requirements are less stable, etc). This is an injustice to the students who have paid a lot of money for training and also a disservice to the writers of the PMB0K Guide itself.
In part 3 of this series we’ll go beyond the “process-centric” view of a project and look at the broader context of managing a project.
PMI, PMP and PMBoK are registered marks of the Project Management Institute, Inc.
Note: Upcoming open enrollment courses