PMP®s vs Agile Project Managers: Clash of the Titans

Introduction

 

To the casual observer, a PMP® is in one corner and in the opposite corner we have an Agile Project Manager. This seems to be the situation because both advocate different visions of how to run a project, and even different concepts about what a project really is. The PMBOK® has been mainstream for years in project management, but in the last decade Agile gained more popularity and now seems to be ready to challenge the champion for the belt. But is it really true that these two are opposed, or would it be possible to find common ground? Don’t miss this fight that doesn’t promise knockouts but instead may go the distance.

Introducing the Opponents

 

For a PMP®, a project is basically control and detail planning; "plan the work and work the plan". Schedule, resources, risks and other competing constraints are evaluated, measured and specially controlled. Reactions to risks are not spontaneous, but rather come from a risk plan already elaborated. The principle does not sound bad and it has worked very well in various engineering fields. Proof of this are the bridges, pipelines and refineries built under the wise leadership of notable PMP®s.

But, and here is the big but, what happens when you cannot plan everything at the start or when the plan is too costly to maintain? Or what happens when you cannot know all the scope in advance? A PMP® simple answer would be, "for that we have rolling wave planning and that’s Agile enough".

On the other side of the ring we have the Agile prophets who say that they can lead complex projects with values, post-its and especially empowering people. That does not sound too bad either but who will be responsible for hiring, performance evaluations, procurement, contracts, budgets and other "insignificant" project matters?

Round 1 – PMP®s Attacking

 

Having competing constraints under control and identifying all risk in a project is definitely not a bad thing to have. Even knowing in advance the scope and freezing it would be a perfect thing in a project. Monitoring a project based on simple indicators that provide solid data is also another great thing to have. All this is not utopia, it actually happens in many large projects with large number of resources attached.

C-level executives making informed decisions based on solid data professionally compiled, analyzed and presented by capable PMP®s is also not utopia. For instance, oil and construction companies around the world have reported very successful experiences by running projects following the guidelines described on the PMBOK® framework.

Still, something seems not to be adding up. Oil and construction projects are large and complicated but not necessarily complex in nature. Software development projects on the other hand belong to a much more complex knowledge domain.

Round 2 – Agile Project Managers Defending and Counter-Attacking

 

PMP®s around the world recognize that one key factor in all projects is communication. And here is where Scrum with its team-centric approach has something better to offer. Tackling complex problems with empowered teams thinking creatively seems not have a rival in the PMBOK® process.

Agile Project Managers do a great job cultivating their teams and fostering communication and Agile values. They play a vital role helping their teams and organizations to transform to Agile. Things become tricky though when Agile organizations become bigger and bigger and more projects are added and team members are counted by dozens. Project areas like procurement or staffing, for instance, are not likely to be attended to by an empowered developer.

It can be inferred then that, even though Agile values and principles live in an organization and Scrum found a home in the heart and soul of team members, still someone needs to take care of some other project aspects.

Round 3 – Locking for the Knockout Punch

 

Successful PMP®s with years of experience managing multi-million dollar projects can be driven crazy by the all-the-time-changing-requirements environment of an IT project. Of course, a prescriptive approach like creating all the plans that the PMBOK® recommends can be taken. But this approach is doomed to fail due to the complex nature of software development projects. Adaptability and Agility seems to be the only way to cope with the changing requirements. But are the PMP® mindsets ready for these?

By the same token, PMP®s tend to look at communication as a process that can be formalized, monitored and even regulated. In a complex-knowledge domain, teams are cultivated. And communication occurs spontaneously with no barriers or hierarchies to prevent it.

The knockout punch from the PMP side tries to come from the side of prescription and emphasis in planning, monitoring and specially controlling.

In the other corner Agile Project Managers believe in the values and principles that they help their teams to cultivate. These values in time help team members to interact in such a way that a positive synergy is created. Still, some important areas of a project are running unattended because projects are not just about team members, technology and client’s requirements.

Scrum as a framework was not thought out as a complete instrument for attending to all project aspects. As light a framework as it is, Scrum is not equipped to deal with project aspects that require interfacing with other areas of the organization, client organization or third party organizations. Crucial aspects like watching the budget are things that cannot be ignored for the sake of keeping Scrum pure in its form.

The Agile side attacks back with a knockout punch that in reality is no punch but Agility to dodge punches and throw debilitating small punches.

Going the Distance

 

Good project managers on both sides need to recognize that the selected framework is just the vehicle for the ultimate goal of having a successful project at four levels: commercial, financial, technical and personal.

Frequently enough PMP®s fail to understand that Scrum as a framework is not about process and mechanics, but about values and mindset. This failure in understanding usually causes dysfunction and suboptimal results, if not complete project failure, in the attempt to adopt Scrum. The problem again seems to be in the oversimplified vision of a project that can be conceived-of only as a collection of processes and plans. Planning is indeed an important aspect of Scrum, but inspection & adaption, transparency, values and especially people are considered more important.

Agile Project Managers should also consider that they still need to somehow manage some portions of the projects, not necessarily people but processes to keep the project running. Not paying attention to anything but the team and Agile could create a bubble that might burst at any moment.

PMP®s can become Agile Project Managers, but this is not simply a matter of changing titles. A deeper transformation is required. As this transformation occurs, no one says that a PMP® needs to forget about the processes required to support the project. It is just that their mindset needs to be open enough to find the right balance. Needless to say, the command-and-control mentality has to go away to be replaced by openness and a trust-the-team mentality. That mentality has to transform, but the PMP®s’ other skills can still find their uses to support projects, as “adapters” to effectively interface between teams and the bigger organization.

Agile Project Managers can also take the time and energy to learn about the PMBOK®. There’s Agility there if we look carefully and with a very receptive mind.

One Japanese proverb says that “there is no small opponent, only small thinking” and small thinking is what might lead us to think that either PMP®s or Agile Project Managers have discovered the silver bullet approach for project management. Both approaches have something to contribute if rivals are ready to hear the other side and add the other’s lessons into their own toolkit.