The Impact of Agile and Lean Startup on Project Portfolio Management

With the large number of organizations now adopting agile methods, the existing body of literature has paid significant attention to the function of project management, business analysis, and more recently program management.  This is understandable as individuals filling these roles are ubiquitous and critical to the operation of their respective organizations.

Many organizations have an additional formalized function, project portfolio management (PPM), that is also critical to the organization but gets little attention — especially in light of the considerable desire being shown to scaling agile to the enterprise level.  The focus, objectives, and responsibilities of agile PPM must fundamentally shift when transitioning to an agile model, structure, and culture.  The reason for this is simple—the same agile principles that are being applied to individual projects can also be leveraged to manage the portfolio.

Below are two ways that agile PPM differs from traditional PPM:

Traditional PPM:  Optimize portfolio resources (individuals) by skill set
Agile PPM:  Maximize value delivery to customers by team capability

Traditional projects, while still delivered by teams, are much more focused on optimizing skill set across a portfolio.  One reason for this is because most traditional organizations are structured and organized by functional specialty.  That is, the organization’s structure is very hierarchical and often has individuals within a particular functional specialty (business analysis, quality assurance, project management, etc.) reporting to the same manager.

Another reason is that projects move through the process by passing through one of several phase gates such as requirements, design, test, etc.  When this is the case, project execution may be throttled by a particular skill set at each gate.  For example, if you have five business analysts, you will be limited to the number of projects that can be active.  However, most organizations ignore this fact and still have far too many projects active at any time; this only adds needless risk.  The sad truth is that most organizations really have no idea of their true project capacity.

In agile organizations, the team (not the individual) is the unit of capacity measure.  Therefore, if you have three teams that are capable of delivering an initiative or feature, you are limited by the number of teams.  So, how many projects of each type can you have active at any one time?  I don’t know; each situation will vary by organization, team, and context.  However, to get started, try setting the limit to be equal to the number of teams with the capability of delivering that type of solution.  If it doesn’t help, experiment.

For example, if you have five products that need mobile solutions, but only have three teams capable of doing the work, only start the three that will deliver the highest customer value.  Of course, that assumes that the teams are not already working on other items.

Traditional PPM:  Maximize Revenue and Evaluate Project Health
Agile PPM:  Govern Empirically through Validated Learning

One of the primary goals of traditional PPM is maximizing revenue… that is, how much money a particular project or product can add to the “bottom line” of a company’s balance sheet.  In today’s economy that is characterized by pervasive, disruptive technology and consumers that demand choice and flexibility focusing on revenue alone misses the point.

Revenue is the metric of wildly satisfied customers.

Stated another way, many would say that the sole objective of PPM is to maximize shareholder value.  This is done through increasing revenue, but it misses the point.  Because customers have flexibility and plentiful choices, the focus must be on maximizing customer value.  By focusing on customer value, if shareholder value doesn’t increase, it may be because you’re building the wrong thing.  Wouldn’t it be appealing to find that out sooner rather than later?

Further, traditional PPM typically measures the health of the agile portfolio by evaluating the health of its component projects.  This is great—in theory.  But one of the big problems with this approach is the way in which health is typically measured.  It’s most commonly done through subjective mechanisms like project status reports, achieved milestones, and progress stoplight indicators.  None of these approaches offer an objective mechanism of determining if the project is actually building the right thing.  Personally, I’ve managed projects that have delivered the wrong solution on time and within budget.  The kind of objectivity that’s required is customer validation.

A more agile PPM approach would be to introduce some mechanism of validated learning to help us make more sound and responsible decisions for our customers about what projects or products to continue funding.  Validated learning is a key aspect of the Lean Startup approach made popular by Eric Ries’ book of the same name.  Agile projects aim to build small increments of a product.  This means we are dealing with smaller return-on-investment (ROI) horizons.

Through agile PPM it’s possible to incrementally fund two projects to experiment with two different solutions to a (perceived) customer problem.  This is known as A/B testing, a.k.a., “split testing.”  Because agile methods allow us to get solutions into the hands of customers more quickly, we can evaluate the results of our experiments and shift funding to investments that are more promising and pertinent.  Because the funding is done incrementally, we need not fund an entire project for an extended period before finding out whether our assumptions were incorrect.

Summary

While these are only two of many considerations when adopting agile PPM, each has the potential to make an immediate and lasting impact on your organization and its customers, thereby, positively impacting your shareholders as well.  In my opinion, the sooner organizations can sow the seeds of customer satisfaction through validated learning, engagement, and collaboration, the sooner they will reap the rewards of increased shareholder value.

What are your thoughts?  How can you begin to apply these concepts within your own unique context?

This entry was posted in Agile Adoption, Agile Benefits, Agile Portfolio Management, Enterprise Agile, Lean, Lean Software Development, Scaling Agile. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>