Benefits are why we undertake projects. Projects are expensive to undertake and have a risk of failure. So, we need to get benefits from them, or at least think we will get benefits from them, to start projects in the first place. Often the benefits of a project are not fully realized until after the project is finished. This is why benefits management is usually the domain of program management. Sitting a level higher than individual projects and operating over longer timelines, programs are better positioned to identify, track and transition benefits from individual projects or groups of related projects.

Agile approaches place strong emphasis on delivering business value. Work is prioritized with the highest business value items done early and definitions of “done” that focus on acceptance rather than completion of work help ensure benefits are truly delivered. This aligns them well for benefits tracking and management, but there is more to understand to truly integrate agile projects with effective benefits management.

First let’s take a peek at the established world of benefits management. The PMI’s Standard for Program Management has three program phases: 

1.   . Program Definition
2.     Program Benefits Delivery
3.     Program Closure

 These are shown below along with a breakout of Benefits Delivery steps:

It is interesting to note that sub-steps 2 and 3, “Benefits Analysis and Planning” and “Benefits Delivery” are iterative. So we can see, program management is focused on the iterative delivery of benefits; which is what agile is all about so why do agile teams often face challenges from traditional project managers and PMOs? 

Thick Sandwiches

This is an aside, but a repeating pattern we often encounter is something I call the “Thick Sandwich”. It describes the situation where workers want to do the right thing and executives and senior managers want business benefits, but placed between them is a layer of middle management who, while well intentioned, tend to obstruct common sense and efficient delivery. So, engineers want to be useful, sponsors want products, but project management as a discipline aims to bring order, predictability, measurement and controls tend to gum up the whole process. 

Middle managers and their processes are created to optimize the process, add rigor and controls, but often just hinder the process. Lean processes (including agile) run up against this often. Agile is well aligned at CMMI levels 1 (Initial), 2 (Defined) and 3 (Managed), it also perfectly aligns with CMMI level 5 (Optimizing) that focuses on process improvement but runs afoul on the documentation and controls layer of CMMI level 4 (Quantitatively Managed). Here again the well-intentioned layer of rigor and control can act as a value delivery inhibitor if we are not careful.