Alignment of the Agile Practice Guide and the PMI Standards

 

This post discusses the development of the new Agile Practice Guide and it’s fit, alignment and potential conflicts with other PMI standards documents including the upcoming PMBOK® Guide – Sixth Edition.

Why Care About Alignment?

Alignment between PMI practice guides and standards is important. People look to these documents not only for guidance on how to undertake work, but also as definitions of terms and often the basis for their own corporate standards. So, it is not a good situation when one PMI document defines a term, like “a Sprint”, as one thing and then a later guide defines it slightly differently. Likewise, recommended approaches should be aligned too. We don’t want one guide recommending the goal of setting a vision to be “X” and another guide saying it is “Y”.  To help avoid these situations, the PMI maintains three sets of standards and a unifying lexicon document.

How PMI Standards Fit Together

First there are “Foundational Standards”, like the well know PMBOK® Guide, but also including standards for program and portfolio management. Since the PMI is an ANSI accredited standards developer, the development process for these documents is very rigorous, for a description of the steps involved see this description for the PMI website. 

One step down in terms of development rigor are “Practice Standards”. These describe the use of a tool, technique or process identified in the PMBOK® Guide or other foundational standards. Examples include the “Practice Standard for Scheduling” and the “Practice Standard for Project Estimating”. When developing recommendations and guidance for agile approaches we need to explain where they deviate from these established Practice Standards.

Lastly, there are “Practice Guides” that provide supporting information and instruction. Practice guides may become potential standards and if so, would undergo the process for development of full consensus standards. Terms used in all three levels of documents are defined in a single, unifying “Lexicon of Terms”. Definitions in the Lexicon were developed by volunteer experts, and PMI standards committees are chartered to use the Lexicon terms without modification.

Where the Agile Practice Guide Fits In

The Agile Practice Guide currently under development fits into the third category of “practice guide”. It was generally agreed that any kind of “standard for agile” would simply not make sense. Any formal document on agile methods should be descriptive, not prescriptive. Nevertheless, it is still peer reviewed and must define and use terms in accordance with the PMI Lexicon.

A challenge in creating the guide was to describe the application of the agile mindset and values in a project setting that has terms and definitions sometimes different from those already defined in the existing PMI standards and lexicon. Often the principles and practices used in agile approaches differ from those recommended in a classical plan-driven approach. So, when the PMI wanted to create an Agile Practice Guide it was aware there was the potential for issues with its existing standards offerings.

A Benefit of Planning for a Living

The PMI knew their newly commissioned Agile Practice Guide would likely to clash terms and definitions with existing standards like the “Business Analysis Practice Guide” and the PMBOK® Guide., Therefore, to minimize that conflict, they engaged participants from the Agile Practice Guide team to first write introductions to each of the Knowledge Areas for the upcoming PMBOK® Guide – Sixth Edition. These introductions describe adaptation and tailoring considerations for agile, iterative, and adaptive environments. They help align PMBOK® Guide – Sixth Edition – due out in Q3 2017 with the Agile Practice Guide, also synchronized with the same release date.

In addition to new Knowledge Area introductions, the PMBOK® Guide – Sixth Edition has a new appendix for agile, iterative, adaptive and hybrid project environments. Written by the same subset of Agile Practice Guide authors, the appendix explores the nuances of how the project management process groups described in The Standard for Project Management are performed with respect to a variety of project environments and life cycles.

So, by first getting this subset of the Agile Practice Guide authors to write the agile related components of the next edition of the PMBOK® Guide they hopefully reduced the potential for conflict and misalignment. Using the same people to develop both documents reduces interpretation differences, but there are still some unavoidable industry conflicts.

Planning Helps but Reality Does Not Care

Agile approaches were developed as a deliberate response to the issues associated with using plan-driven approaches in highly volatile environments. As such plan-driven definition and terms were not generally consulted or adhered to. In some instances, agile protagonists wanted to purposely distance themselves from the established status quo.

For example, “earned value“ is in the eye of the beholder. In the PMI Lexicon it is defined as “The measure of work performed expressed in terms of the budget authorized for that work.” Yet, in the agile community it is more usually known as “the value of the benefits delivered” - quite separate from the budget authorized for that work.

Another challenge is explaining when and why the recommended approaches between plan-driven guidance and agile approaches seem to differ. Take defining scope and developing specifications for example. Plan driven approaches work from the perspective that the most efficient approach is defined as much as possible upfront, get agreement this is what is required and then start executing towards this agreement of scope.

Agile approaches work from the perspective that unsurfaced complexities and uncertainties will prevent a near complete specification of work being discovered near the start of the project. So, instead of attempting to prematurely define a specification that will then frequently change, it is more time and cost efficient to build some small increments of product and iterate to the final required design from there.

These are very different approaches to scoping and execution. Each makes sense in its own context and, as always, there is potential for combining elements of each into a hybrid, third alternative. The Agile Practice Guide needs to respect both approaches and offer actionable guidance to practitioners faced with these circumstances so they can make informed decisions.

Next Steps

Our work in developing the Agile Practice Guide so far has raised some great topics for discussion. Hopefully, this post has introduced some of the issues associated with alignment with existing PMI standards. Future blog posts will cover planning-and-process mindsets vs uncertainty-and-people based mindsets and other topics of alignment.