Agile Project Management vs. PMBOK® Guide and EVM- 

 “Revolution or Evolution?”

1)      Introduction – Overview  

 It has been a little over ten years since the Agile Manifesto was published.  Over these 10 years, the interest level in APM (Agile Project Management) and the specific methodologies included within the “Agile umbrella” – such as Scrum, Extreme programming, Lean, Crystal, DSDM and Feature Driven Development – has steadily increased. APM is certainly not a passing fad. More and more people are departing from running their projects using the traditional methods, and are using Agile methodologies instead.  

 In the last few years it appears that Agile Project Management has crossed a key boundary from being in an “early adoption phase” into “mainstream adoption.”  With PMI’s recent announcement of the PMI-ACP Agile Certification, this will further increase the interest level in Agile Project Management, and validate its acceptance as a key way to manage many types of projects. For companies and project managers who have been slow to get educated on this new approach, the time is now: get up-to-speed with APM and its benefits, or perhaps risk becoming obsolete!

APM was originally conceived of as just a new way of project management for software projects only, but today it’s being applied successfully in many different industries and applications. It is most applicable for projects where it is expected the requirements will change significantly during the course of the project: the customer does not up front exactly what they want; .therefore, we will iteratively create prototypes of the product or service, and allow the requirements to “emerge” or be discovered in progress. Since software projects often include the most malleable requirements, they are excellent candidates for using APM. But today, many other projects are excellent candidates too. In Jim Highsmith’s excellent book, Agile Project Management: Creating Innovative Products – he points out that many products that were once thought to be hardware only are now really hybrid products with a significant software component, and the software component keeps increasing. Cell phones are great example: in just a few years they have evolved from being products with relatively little software to being products with hundreds of thousands of lines of software code that drive all aspects of the operation of the phone. Even in architecture and building design, the use of CAD and other modeling and prototyping techniques has had huge implications for how to approach the project.  

In the January 2012 PMNetwork magazine, there is a feature article on the adoption of Agile, and of 4,770 software project managers that PMI interviewed, 90% said they were using some form of Agile. Additionally, most of these PMs cite having much a higher level of success using Agile than they had with the just traditional methods. Also, as reported by PMI, the use of Agile methodologies has tripled from December of 2008 to May of 2011.

So, today, we seem to have two dominant schools of thought regarding project management: the traditional approach whose practices and processes are best articulated in the PMBOK® Guide, and this new school of thought – Agile Project Management (APM).  The key writers and authors of books on APM describe this new approach as a revolutionary approach: a complete departure from the traditional way of managing projects. Is this really correct? Are they recommending discarding many of the key practices and processes that are defined in the PMBOK®  Guide? Yes, oftentimes, this seems to be the case! In Doug DeCarlo’s book, Extreme Project Management, he quotes a PMP managing pension implementations, “I always believed that the project management profession is doing itself a disservice if it doesn’t recognize that many, if not most, projects don’t follow the guidelines set forth by PMI’s PMBOK®  Guide.”

In APM, they certainly have adopted a whole set of new concepts and terms and terminology, and they rarely reference the tried-and-true core concepts defined in the PMBOK®  Guide: creating a very detailed WBS, managing project performance against baselines, using Earned Value Methodology, having formal change control and configuration management systems, and thoroughly documenting all aspects of our projects. Though many of these terms do map onto the old tried-and-true terms, or there is a lot of overlap at least, the authors of APM say it’s very important to come up with new terminology to connote the key themes they are emphasizing in APM.

On the other hand, can we make the case that Agile Project Management is really a refinement and extension of tools-techniques and processes that are already defined in the PMBOK® Guide? This, of course, is the PMI view. They would remind us that the PMBOK® Guide is not meant to be a menu of how to do projects. Instead, it is to be understood as a higher level framework of best practices and methodologies that support projects in any industry, no matter how simple or how complex. It has always been understood that added to the 42 processes described in the PMBOK® Guide, there can be many other more specific approaches and methodologies that fit different projects in different situations, and in different industries. These more specific methodologies could be seen as extensions of tools and techniques that are defined for the processes. On the pmi.org website, on the FAQ page for the new PMI-ACP certification, the distinction between PMBOK® Guide and Agile is described in this way: “The PMBOK® Guide – Fourth Edition contains principles of project management and project management processes. These processes describe “what should be done during the management of a project.’ Agile methodologies are different in that they describe ‘how to do the things that should be done’ – in short, ‘what versus how’.”

So, can we reconcile this apparent disconnect? I think, in large part, we can! I think there are three major areas where Agile supporters reject Traditional Project Management – (and, in the same breath, the PMI view and PMBOK® Guide) – where this criticism either does not apply to the PMBOK® Guide, or they have misunderstood or misrepresented the PMBOK® Guide.

• Rejection of the “Waterfall Method”
• Rejection of formal change management and configuration management
• Rejection of the traditional project manager’s role and the team members’ roles

However, I would argue Agile methodologies do define a different framework and philosophical approach for managing projects that is currently not embraced in the PMBOK® Guide. The PMBOK® Guide currently defines a very formal, prescriptive – (or “Push approach”) – for managing projects. It requires, as PMPs, we should create a very detailed project management plan at the beginning of the project with its many subsidiary plans, and define accurately the three key baselines: Scope baseline, Schedule baseline and Cost baseline. We should use Earned Value Methodology on all projects.  

Agile, on the other hand, dictates using a far less formal approach – (or “Pull Approach.”) We will discover requirements in an iterative way, and let them emerge; we will let the team choose as they move through the project what documentation is needed, what type of subsidiary planning is needed, and what level of detail is needed in the plans. Some of it will be invented on the fly. APM defines basic guidelines, and provides tools and techniques and best practices for the team, but allows the team at great deal of freedom and flexibility for how to deal with the individual project they are working on.

In Agile, new concepts and terminology have been introduced to replace the older traditional terms: the WBS is replaced with an FBS – (Feature Breakdown Structure), the classic baselines are not mentioned, the project manager’s role is redefined, and new concepts such as “burn-down charts” are introduced to measure progress on a project – (within a Sprint). As a long-time PMP – (since 1995) – and supporter of PMI, I believe that for the PMP to remain as relevant in the next ten years as its past 25+ years, I think the PMBOK® Guide must be broadened to include this different approach of Agile Project Management.  

I have broken the rest of the paper into six sections:

1. APM’s (Agile Project Management’s) criticism of the Waterfall method
2. Defending the PMBOK® Guide against this criticism
3. Other Agile Misconceptions About the PMBOK® Guide
4. There Are Two Different Philosophical Approaches Being Defined
5. Version Five of the PMBOK® Guide – How Will It Address Agile?
6. Conclusion – What Approach Is Best In What Situation?

Lastly, I’ve created YouTube video clips created for the January 17^th PMTools presentation slides!  The first video clip is – http://www.youtube.com/watch?v=ptG1xopSEIM