Baseline Benefits as Well as Costs

Not to keep harping on the ongoing depression in oil prices – which let’s face it, is probably a good thing for folks outside of the energy industry – but it affects many of the discussions we have with our clients these days.  In this case, it points out yet another deficit in the traditional project management mindset, i.e. that I need to baseline scope, schedule and cost – and then measure how well my project delivers on all of those.

Well, if my project was chartered when oil was above $85 a barrel, I might have made certain assumptions about the benefits and potential profit of the project.  In the days of $60 oil, those assumptions may no longer be valid.  Hence, this is a useful reminder that we should be baselining and tracking benefits as well as simply tracking scope, schedule and cost.


Baseline Benefits as Well as Costs

Would You Wear a Winter Coat on a Hot Day?

As the Houston summer heats up and the mosquitoes launch their annual siege, the concept of summer safety comes up.  We lecture the kids on what they should wear, and how they should slather themselves with repellent and sun screen.  One thing we don’t do however, is break out their winter coats and warm mittens.

Why?  Because it’s just not appropriate.  (And I guess it could potentially kill them).

The trick is to dress appropriately to the environment you’re in.  The same is true of the PMOs that we regularly talk to.  In this time of plummeting oil prices, cost cutting, and workforce layoffs, how receptive will executive management be to the tired old trope of “We either need to get more resources to meet your requests…..or you have to stop asking us for so much stuff.”

The traditional resource management discussion will fall on deaf ears in this downturn.  In this environment, the discussion is not how to do less – but how to do more with the same or less resources.  How do we strategically cut resources but ensure the important stuff still gets done?

That’s the business case for an PMO when times are tough….and in reality, when times are doing well.

Would You Wear a Winter Coat on a Hot Day?

10 Things I Learned at PMI Houston’s 2015 Annual Conference

We came.  We saw.  We learned.  The 2015 annual conference has come and gone, and with it, we’ve compiled our list of the top ten takeaways.  See how the oil price downturn has affected project and portfolio management in the country’s energy capital.

(Posted on the UMT blog)

10 Things I Learned at PMI Houston’s 2015 Annual Conference

Balancing Speed and Efficiency: Effectively Segmenting the Portfolio (Part 2)

In the portfolio management space, we seem to live on a continuum.  On one side, we segment the portfolio and treat the different portfolios as separate entities.  On the other side, we combine all of our work and prioritize against the overall organizational goals.


In the last post, I presented a framework for creating at least three different work portfolios within an organization:

  1. Mandatory – work required to keep our executives out of prison…generally considered a solid reason for any project.
  2. Discretionary – work that someone thought would be a good idea that may / may not be evaluated within a specific silo and/or against the needs of the overall organization.
  3. Baseline – work that may be rationalized against assets to ensure it supports multiple silos within the organization.  In this case, the asset is prioritized, and the work inherits the prioritization at the direction of the asset management team.  (Note that I know of at least one organization where “baseline” work is referred to as “mandatory,” which may add to some confusion.)

In this post, I’d like to present a framework for understanding when we want to simply lump everything into a single portfolio – or break it out into multiple silos.  One of the concepts from the Gartner IT PPM Summit a couple of weeks ago comes to mind, i.e. the concept of the bimodal IT department (or, as we jokingly have been referring to it, “bipolar IT”).  Per Gartner, in the next several years, up to 50% of IT spend will be directly controlled by the business.  In short, IT will be split between two operating models:

  1. Mode 1 – the “traditional” approach of planned, risk averse projects.  Projects are planned and approved, and executed to support the needs of the business, as interpreted by IT.
  2. Mode 2 – the accelerated approach of shrinking the request to fulfillment lifecycle and getting projects done in the fastest way possible to directly respond to the needs of the business.

The reason I bring this up is because it’s absolutely applicable to the portfolio discussion.  The reality is that segmenting our portfolio allows us to do two things:

  1. Accelerate the project approval lifecycle.  I no longer have to review the benefits of the project against all of the other projects – which in turn allows us to avoid an inevitable formal cadence where projects are suggested each year or quarter and then approved as part of structured review process.  (Try enforcing something like that in an Exploration & Production company and you’ll see how quickly the business will revolt).  When the portfolio is segmented, we don’t need all of the approvals and formal review schedules.
  2. Implement a learning strategy.  As  Henry Mintzberg writes in his many books on the topic, strategy is a learning process, a series of continuous experiments where ideas are tried out, feedback is gained, and that is fed back into the strategy of the organization.  In this case, segmenting the portfolio allows us to build that feedback loop into the project sensing and prioritization mechanism.  If all projects within an organization are prioritized against all other projects, that may impair the learning process – as each step towards understanding the strategy is hampered by an interdependence on projects approving all other strategies.

Hence, my initial stab at capturing this thought process in a visual model yields something like this (which I am sure will evolve over time).


A quick definition of terms:

  1. Learning Strategy –the ability to work on a strategy and prioritization mechanism that has not been perfectly articulated, i.e. to build an accelerated feedback loop into the strategy to assess how well we’re hitting our goals – and in fact whether or not we’re working towards the right goals.  (Note that I considered swapping this out for market volatility, i.e. how quickly the organization needs to adapt to changing market conditions – but figured that was essentially saying the same thing.  Think the stability of large utility IT vs. the short term timelines of exploration IT – and then throw in a sprinkling of how utilities are attempting to accommodate new technologies such as smart grids and solar generation.)
  2. Defined Strategy – a strategy that is well articulated and measured.  For example, this year, our goal may be cost cutting overall.  Hence, we will charter projects targeting established mechanisms of cutting costs (consolidation, rationalization, divestment, etc.)
  3. Speed – the need to shorten the request to fulfillment value chain and generate value in the form of deliverables in the absolute shortest time possible.  Often, this results in inefficiencies as the organizations sprints to keep up with market demand – but those efficiencies are tolerated.  The alternative, after all, would be losing out to the competition.  Segmenting the portfolio enhances speed as it essentially pre-authorizes the funding decision….as long as the project falls within the purview of the specific portfolio segment, the portfolio owners can make their own decisions.
  4. Efficiency – the need to make the best use of a limited set of enterprise constraints.  When efficiency reigns supreme, it’s important to slow down the approval cycle and validate all projects in the context of all other projects.

Hence, when I try to plot the conversations we’re having in the energy sector this year (depressed prices) against the conversations last year (higher prices), I end up with something like this picture.


The conclusion then is that while there is an appropriate portfolio structure for each market condition – that structure needs to shift when the market does.  If we lock ourselves into a specific portfolio model and ignore external change, we won’t be able to perform our roles as effective investment advisor to the organization.

Balancing Speed and Efficiency: Effectively Segmenting the Portfolio (Part 2)

Balancing Speed and Efficiency: Effectively Segmenting the Portfolio (Part 1)

(Catching up on some thoughts after getting through a couple of recent client interactions, conferences, and books.)  In the portfolio management space, we seem to live on a continuum.


On one side of the continuum, we have this vision of the perfectly optimized portfolio.  In this vision, every project has a business case and can be prioritized against every other project – perhaps in the form of an evolving backlog that gets released into execution on a quarterly basis.

On the other side of the continuum, each stakeholder group is allowed to manage its own funding, i.e. the siloed funding approach.  Prioritization occurs within the silo, and little if any lip service is paid to how the project for one group should align with the project in another group.

So the question comes up….when does it make sense to segment and when does it make sense to share?  What are the hybrid scenarios where it makes sense to have both models?  This blog post is my initial attempt to answer that question.

Before we get too far into that discussion, however, let’s take a look at this diagram we came up with recently for an IT PMO.  Essentially, we analyzed the work in a “standard” IT department and segmented it out into three proposed portfolios.  Note that this schematic probably applies outside of IT as well, i.e. oilfield management, facility management, etc.


Per our analysis, we had three main portfolios.  In this case, we use the word portfolio to indicate a specific governance process, i.e. a process to capture the request, approve it, pass it into execution, and then manage the benefits realization – the request to fulfillment value chain.

Portfolio #1: Mandatory – these projects are required due to regulatory reasons.  Hence they must be performed.  I am still working through the funding model for regulatory projects, but let’s simply assume these projects are approved from the initial definition stage – and then funded either from a shared funding pool, from a specific business unit, or in some sort of cost allocation against each of the relevant BUs.  (Note that in our experience, the definition of “mandatory” varies significantly from organization to organization.)

Portfolio #2: Discretionary – these projects are what typically fall into the model of shared prioritization.  These are projects that don’t necessarily have to be performed, but do have a valid business case that ties back to the goals of the organization.  This is the portfolio I will primarily be focusing on in the next post, i.e. when and how to break this into separate funding streams.

Portfolio #3: Baseline – Baseline work in this sense is defined as the work required to maintain the asset portfolio.  In IT, we would define the asset portfolio as a series of capabilities or applications.  In energy, we might define an asset portfolio as a series of pipelines, wells and facilities.  Essentially, the concept is that for every asset, I will have performance metrics, and a set of projects required for maintenance and enhancements.  For an application, I will have a project to build it, enhance it every year, and then upgrade or retire it.

The importance of classifying something within the baseline portfolio is that this portfolio typically plays the part of utility services, i.e. providing shared services to support multiple business units.  In this case, we don’t want to have to perform a detailed strategic business case on every project that comes through the pipeline – as typically the projects are too small and too focused on a specific asset to justify spending the time of tying it back to the overall organizational goals.  Instead, we rationalize the portfolio, and identify the capabilities that are shared across multiple business units.  Then we identify the assets that support the capabilities, prioritize the assets, and defer the project approval process to the asset management teams – what in ITIL parlance would be the Application Owner and Manager.

So that’s the overall framework we are going to start with.  The next question (and the next post) is how do we determine when to treat a portfolio as a single entity across the enterprise and when do we decide to break it out and make prioritization (and funding) decisions by the BU?

Balancing Speed and Efficiency: Effectively Segmenting the Portfolio (Part 1)