Agile Benefits Management
November 25, 2015
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:
- . Program Definition
- Program Benefits Delivery
- 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?
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.
Output vs Outcome
Removing or lessening this layer of management interference is critical to ensuring benefits are delivered. In many large organizations too much emphasis is given to “are you following process?” rather than “are you creating value?” This is largely because it is easier to measure if a project is following process than if they are adding value. However, the benefits are the reason we undertake projects. A perfectly executed project that completed every document and passed every gate review but failed to deliver benefits is a colossal waste of time and resources. “The operation was a success, but the patient died” does not deliver any benefits.
So it is the outcome – the benefits and not the outputs – the project deliverables that we should be focused upon. Gate reviews, retrospectives and PMO’s have to be careful to focus on these outcomes and not the outputs to keep returning focus to benefits.
Some benefits only come about when multiple projects are completed in a coordinated way. We can have projects to build transport infrastructure, create attractions and hire employees, but the benefits of opening a theme park only come about when all are accomplished at the appropriate times. This is another reason benefits management is often reserved for program management. By definition, a program is – “A group of related projects, subprograms, and program activities that are managed in a coordinated way to obtain benefits not available from managing them separately”.
Agile projects have a potential for scope morphing. They engage the business frequently and work iteratively towards what the business wants which may be different from what was first asked for. Usually, this is a good thing, however for larger programs of work, we need to ensure these local optimizations do not compromise the integration and global optimization of benefits.
Not all programs and projects run their entire course. The longer and larger an endeavor, the more likely it is that business, the market and sponsors will change. That’s just a function of having an extended horizon of risk i.e. running long time frame projects. Organizations often find themselves trying to harvest what they can (if anything) from long-running initiatives that need to change. Obviously they do not call this “salvaging”, “rescuing” or “trying to get something useful from all that money we spent” since there are reputations and facades of leadership at stake. So, “restructuring”, “re-focus”, “pivots”, and “re-organizations” occur but the idea is the same: “How can we extract some benefits for the investment to date?”
An Agile approach to running projects helps in these circumstances. Rather than slicing a project horizontally into activities and doing all the requirement gathering, then all the analysis, and then all the design; agile projects slice vertically developing and delivering small increments of functionality. Terminating a waterfall project 50% of the way through might yield lots of documentation but no usable solution. Terminating an agile project 50% of the way through should give you 50% of the features, and since the work was prioritized in business value order, highest priority first, that might be more than 50% of the total benefits.
Of course it is never that simple, 50% of a product might still yield no benefits if it is not complete enough to market, but in terms of salvageable assets, these components are typically more beneficial than complete requirement specifications and designs.
Not all benefits are financial. Non-financial benefits include:
- Skills and learning
While numerical approaches do exist for trying to convert these benefits into financial measures (For instance: “Negative press around the Product X launch may deflate share price by 5%”) by definition these measures are harder to quantify.
We have to be careful when using agile for projects targeting Reputation and Safety benefits. I firmly believe the iterative nature of agile that delivers candidate solutions early, bakes the most significant elements in up front and employs far more review and feedback cycles leads to higher quality solutions. Critical elements have more review, testing and usage within the project environment than waterfall developed components. However, where we need to be careful, is the stakeholder management of how the approach is explained and positioned.
The team may push rapidly ahead on new components and even on trying new approaches to development, but these are not the final solutions. They go fast to uncover gaps in understanding sooner to build a better product in the long run. They should not go fast to get the first version of something out the door asap. Solutions with safety and reputation implications still need lots of rigor and multiple layers of verification, agile approaches just help prune unsuitable solutions early.
Projects undertaken primarily for Goodwill and Learning benefits are great candidates for agile approaches. The frequent lookbacks at the benefits and process being used themselves foster goodwill and learning opportunities. They are human-centered, adaptive, collaborative endeavors and work well on humanitarian and process improvement initiatives that naturally follow progressive rollout and adaptation.
Benefits management focusses on the bigger picture view of why we undertake projects and programs. Often project managers, who are rightly close to their projects, cannot see the bigger picture of what success looks like. I have written before about failures that are successes (Sydney Opera House – 15 times the budget and 12 years late) and successes that are failures (Original Iridium satellite phones – On time and budget, but the consortium goes bankrupt), you can read about them here.
Benefits Management takes the longer term, not just scope, schedule and budget criteria view to track the Why’s of projects to delivered benefits. Agile projects take a business value driven approach that usually aligns with benefits but still needs higher level coordination.
(I first wrote this article for ProjectManagment.com and it appeared on their web site here)