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)

5 Steps to Application Portfolio Management [Webinar]

Ben Chamberlain will be presenting on one of the hottest topics we see in the IT portfolio management world these days…..Application Portfolio Management.

Ad-hoc, event-driven approaches to Application Portfolio Management (APM) simply aren’t delivering results. Important application data and metrics simply can’t be effectively maintained using spreadsheets and homegrown tools. This makes it a challenge to sustain a continuous APM process that supports annual IT planning and budgeting.

Tune into this webinar to see how APM can help you:

  1. Consolidate applications in one inventory
  2. Derive key assessment metrics (Value, Risk,
    Architectural Fit etc.)
  3. Calculate  Total Cost of Ownership
  4. Collaborate to record lifecycle decisions
  5. Build and execute multi-year transformation roadmaps

For more details, or to register…..

5 Steps to Application Portfolio Management [Webinar]

A Focus on Resource Management is Value Deferred

A PMO’s job is fundamentally to operate as an investment advisor to the business.  A PMO should recommend to the business how to best structure projects and the project portfolio to reduce risk and enhance value.  All too often however, while the PMO may be able to perform this function for projects that belong to other groups, it tends to have a blind spot when it comes to the PMO’s own improvement initiatives. (see Chris Argyris’ Overcoming Organizational Defences for more on why this may be the case.)

Nowhere is this more evident than in the resource management discussion.  The PMO is usually in a perfect place within the organization to provide resource analytics.  The PMO has visibility into all projects in execution.  The PMO has some control over each of the PMs managing these projects.  The PMO typically owns some form of a PM Information System (PMIS) that has functionality designed to capture all of this data and regurgitate it in the form of colorful, clickable reports.

Hence, once the PMO realizes that one of the fundamental issues impacting project execution is resource contention, it begins a review of enterprise project management systems designed to support data collection and presentation.  This endeavor is typically phrased in the context of mapping resource demand (the project pipeline) and resource capacity (the resource pool).   Somewhere in this discussion, the consultant (me) will invariably ask, “Why?  What’s the goal of collecting all of this data?”

The answer is almost always along the lines of, “We need to show the impact of adding new projects on our resource pool.  We need to provide the metrics to justify asking for additional head count to address the sheer number of projects in the pipeline.”

Let’s take a look at the implications of this statement.  The PMO is basically saying that the organization is allowing too many projects into the pipeline – or that we don’t have the resources to support this level of project execution, which is essentially the same thing.

The roadmap then for a “traditional” resource management deployment of an EPM system is to implement all sorts of metrics to capture the current resource load, to capture where resources are spending their time, and create all sorts of reporting functionality.  Fast forward 6-12 months down the road and assuming we didn’t fail in the all important user adoption, we have beautiful reports; we have resources all captured in a fantastic online database.  What do we do with the information?

We take it back to the business and present them with prioritization decisions.  This is the point where we might realize that the business is not willing to change how projects are selected – that the business is not willing to converge on a single prioritization scheme.  Remember, the entire resource management endeavor was predicated on the idea that eventually we would get to that point where all of the data could shape behavior.

There’s a lot of risk inherent in this approach:

  1. The risk that user adoption will not happen and resource data will be flawed.  This is pretty much guaranteed in the majority of implementations of a certain size.
  2. The risk that once we collect the data, the business will not be interested in coming together to find new ways to select projects.

Wouldn’t it have made sense to have overcome this hurdle first – then go through the effort of collecting all of the resource data?  Wouldn’t it have made sense to assess organizational willingness to even touch this issue – then focus on what the PMO could actually do to generate value?

An Alternate Approach

If we start the improvement process with project selection and attaching estimates to new projects, we mitigate these risks:

  1. By focusing only on the projects in the approval pipeline, we greatly reduce the number of moving parts associated with resource management in the enterprise.  We reduce the complexity and enhance the opportunity to drive user adoption within the constituency that counts.
  2. We cut to the chase.  We identify that the organization is willing to address the fundamental problem – not the availability of resources, but the inability to prioritize the projects.  We put the prioritization mechanism in place, then build the reports and data structures to support it.  This is important because it lends credibility to the resource management effort.  We’re not simply collecting data to collect data, a common gripe.  We’re collecting data to support a clear strategy.
  3. We begin generating value immediately – and don’t invest in 12 months of effort with an uncertain delayed return.

At the end of the day, resource management roadmaps always end up at the feet of the business and the prioritization process.  Why take on all of the risk and investment before realizing we’ll fail there?  Instead start with the single point of failure, address that, and then move on to the complicated stuff.  Fundamentally, that reduces the risk that the organization will invest heavily in a resource management process – only to kick it to the curb when it comes to the actual behavioral change that matters.

A Focus on Resource Management is Value Deferred

In Portfolio Management, the Best Defense is a Good Offense

People often ask me what I do in my role at UMT.  That’s a great question.  The answer is really quite simple:

  • I help organizations define what they want to accomplish through their project portfolio.
  • I help organizations align the projects they’re working on with what they hope to accomplish.

Needless to say, there’s a lot of work to be done on each of those bullet items – whether it be identifying operational constraints or eliminating waste and mitigating risk in the project delivery process.  In this role, I work with organizations at various levels of portfolio management maturity.  Some organizations are just focusing on getting an idea of what projects they’re working on and what constraints apply to those projects.  Other organizations are grappling with the pressing issue of trying to figure out how to prioritize those projects.  Still other organizations are grappling with the issue of whether or not the list of potential projects is even the right list to be considering.

When companies first begin to tackle portfolio management, they often start from the perspective of aligning their current planning processes.  Every year, projects are proposed by specific individuals within the organization.  These projects are added to a central repository of project work, and then rated on how well they align with specific strategic imperatives of the organization.

Sounds good right?  There’s nothing inherently wrong with this approach – but it invariably leads to questions such as “How does this project actually align with strategy?” or “How do we track benefits for this project?”  When each project is proposed as a stand alone entity – and treated as such, it becomes difficult to answer these questions.  This collection of projects doesn’t comprise a comprehensive strategic approach – but instead simply a collection of individual answers as to what is most important to the organization from the individual’s perspective.

It reminds me of the Mongol term for rice – buda.  It’s used to describe something as irreparably broken, that is now a collection of parts that cannot work together.  If a truck engine is buda, then it is like a handful of dry, white rice.  No matter how much you squeeze it, you’ll always have a collection of separate grains.  It doesn’t matter how many hours that truck will spend in the garage, those engine parts will never cohere to form a functioning engine again.  A project portfolio built from the bottom up is no different.

The issue is that the organization is playing defense and being reactive by fielding the project requests.  The trick to successful portfolio management is to go to the offense.  Instead of starting with the projects, and attempting to align them to the strategy – start with the architecture of the organization, and then forecast your projects to support that.

Start with the business plan for the next 18 months – or whatever time frame makes sense given the volatility of your industry.  Decompose that into business capabilities, services, and the assets that support those services.  This gives you a framework to understand what the organization needs to be doing at a tactical level.  As the organization changes, use this framework to identify the projects that we should be working on.

The white space around the strategic changes is filled with the BAU work that must be done.  This, too, can be proactive.  Each asset added to the enterprise environment requires constant updates, upgrades and maintenance.  Budget for that.  Understand that in the case of an IT application or a production facility, each year we will be making updates and modifications.  In a couple years, it will be retired and replaced.

There’s still room in this framework for the pop up individual requests.  After all, those capture the oversights – the gaps between the strategic plan and reality.  However, once the portfolio planning becomes more proactive, there will be a lot less of these unplanned requests – as chances are they were just manifesting as examples where individuals had perceived a gap between the current and the desired future organizational state.

When you start from this architectural framework, you end up with a proactive, forward looking portfolio of projects queued up for the foreseeable future.  You’re not playing defense and fielding individual requests.  You’re providing a benefits measurement and strategic context for each of those individual initiatives.

At the end, the success of a portfolio management lies not with a defensive mechanism of saying no to the low value projects, but with an offensive mechanism that relies on the quality of what I call the sensing mechanism – that piece of the puzzle that contains the processes that comprehensively defines the gaps between the current and desired future state.

In Portfolio Management, the Best Defense is a Good Offense

Programs as Benefit Measurement Frameworks

There’s this myth pervading the portfolio management space that there’s a single benefit measurement model to rule them all.  Whether it be NPV, ROI, IRR, user satisfaction surveys or any other measure of tangible benefits, the reality is that any project may be measured according to any number of benefit measurement models stretching in a spectrum from the tracking of objective data to subjective data.


The trick is to identify the project type, and map that project type to an appropriate benefit measurement model.  For example, an IT project to support a specific application may be designed to reduce down time, to enhance user satisfaction, or to increase the speed of operations.  Each of those benefits are measurable, insofar as they can be assessed through service metrics or satisfaction surveys.

The challenge, however, is that oftentimes we have never implemented the monitoring systems to track these metrics – despite the fact that they’re in the gospel of ITIL as part of Service Design.  Hence, if we want to track against these metrics, we need to incorporate the creation of the baseline and tracking system into the budget of the project.

A PMO can slip that monitoring into the budget of one project, but sooner or later, sheer inertia negates this, as the stakeholders begin to rebel against repeatedly approving extra budget for monitoring project success.  Due to simple budgeting constraints, we can’t incorporate a metrics monitoring system on the front end of every project.  From a logistical standpoint, this won’t work as well, as it typically takes a fair amount of time to build up meaningful performance baseline data, and by the time we put everything on pause to collect this data, the project would have slipped far past the most forgiving stakeholder deadline.

The solution is not to incorporate metrics tracking into every project that passes through the approval process, but as the front end design of every program that passes through our portfolio.  If we treat an application as a program, we can set a threshold, i.e. any application with X number of users or that we will use for longer than Y years will need a metrics tracking system incorporated into the program design.  The metrics tracking system will generate performance data to assess if we are hitting our service performance goals, and our financial goals.

Those metrics then become the performance metrics for every project that is incorporated into the program.  This gives us another answer to the question of how we define programs within our portfolio.  A program is a framework for benefits measurement that may applied to the projects that reside within the program.

This also makes our investment decisions easier as we can budget to the program, and then allow the metrics within the program to dictate the actual composition of projects within the program.  How to assess the value of the program?  By identifying how it ties into the overall operations of the company – which is far easier than doing so at the project level.

Taking this concept one more level, a properly designed program should be tied to ongoing business conditions.  A periodic assessment should be conducted of the business environment to confirm that the program itself remains viable based on certain predefined measures of program success.  When the business conditions change, the program funding spigot can be turned off, effectively killing all projects within that program.  Alternately, additional funding can be added to the program, which in turn is directed to the proposed projects that meet the programmatic success measures.

Programs as Benefit Measurement Frameworks

The Road to Portfolio Analytics

I’m gradually working my way through Charles Betz’s excellent book, Architecture and Patterns for IT Service Management, and parts of it are resonating to me.  I’ve only gotten to the section on Demand Management, but it’s definitely starting to correlate to what I’m observing in our clients.  Let me see if I can put my own spin on it….

The basic gist is that demand comes in many different forms.  In IT, demand shows up as formal project requests, service requests (i.e. minor changes that don’t rise to the level of projects), and the output of various systems monitoring services.  The latter category in an IT setting would include all of the outputs of availability and capacity monitoring.  In a non-IT setting such as capital equipment, I would extend that to include the output of our maintenance scheduling systems, which spit out tickets for required maintenance.  As ITIL is really the extension of capital equipment management best practices to the relatively immature field of IT, that logic seems to make sense.

So that’s the work intake process, or if you want the sensing mechanism that determines what work the organization could do.  Let’s go to the other side of the intake process, the work queuing mechanism.  This is the viewpoint from the technician in the field, the person who must actually perform the work that’s coming through the intake funnel.  In a perfect world, this is all funneled into the same assignment queue.  That way, I can see my queue, and see all of the work assigned to me, whether it originated as a project task, a service request, or the output of a maintenance system.

In a perfect world, all of that work is prioritized – either by the work, or through some sort of prearranged prioritization mechanism, and every time I finish a task, I can go back into my queue and determine what the next task in order of priority is.  I might also throw other characteristics into the task selection, such as how long it would take to perform the task.  If I only have an hour, I’ll pick the next task that can be completed within a single hour.

The reality is that this rarely happens.  In the organizations we see, there are fragmented intake and queuing mechanisms.  As a result, we have different work streams that end up in different queues tracked with different metrics but assigned to the same individual.  As a member of IT, I will have tasks assigned in the ticketing queue, the release queue, and the project task queue.  Each of those tasks are competing for my bandwidth.

This takes us to the holy grail of enterprise work management.  In essence, the goal of an organization, IT or otherwise, whether they realize it or not, is to centralize all of that demand into a central location, prioritize it, and then spit it out the other end into an appropriate work management system.  I won’t say a consolidated work management system, as that may not make sense – especially when I have resources that are dedicated to performing preventive maintenance and can easily live within a single queue.  However, when I have resources that are pulled across multiple queues, then that requires a more rationally designed work management system.  (More on that in another post.)


Which leads us to the logical fallacy that has shaped the world of portfolio management for years.  There’s been this underlying assumption that we can take all of the work that comes through the demand intake and prioritize it against other work.  That’s the fundamental premise of many PPM systems, i.e. that I can throw all of my projects into a single bucket, define their priorities, and then map the priorities against the cost to optimize my portfolio.  As long as I am prioritizing similar work streams, this more or less works.

The problem comes when I try to compare apples and oranges, when I try to compare a project to support Application A to a ticket to support Application B.  At that point, the portfolio optimization breaks down.  The inevitable result is either a logjam of work that kills the adoption of the PPM system, or a regression to the multiple siloed work intake and management systems with their own on board prioritization and fragmented queuing systems.

Enter the world of portfolio analytics.  In portfolio analytics, we’re not looking to prioritize individual work, but instead, we’re looking to tie that work to a specific organizational asset.  In IT, each project, ticket, or release supports an application, which in turn, supports a service.  In a non-IT scenario in Oil and Gas, for instance, each project or ticket or release supports an asset such as a rig or well, which then can be quantified in terms of production and profit.  If I can identify the business criticality of the service, then I can assess the priority of each element of work in supporting the service, and therefore derive a cohesive, comprehensive framework for work prioritization.  I don’t look at the individual work items, but instead at the work in aggregate in terms of the assets it supports.

The first step in performing this analysis is to map the costs of the work to the assets.  While that sounds simple, it gets complicated when you throw in the fact that we have to model shared services, work that supports multiple assets, outsourced and insourced models, etc.  By mapping the relationship between our logical work entities and our logical assets, we can identify the total cost of ownership of the asset.  That’s the first step in portfolio analysis.

The next step would be in defining the value of the asset, whether it be in quantitative profitability terms, or in qualitative benefits.  Once the benefit cost ratio can be determined, that prioritization can be fed back into our demand intake structure – provided each of the demand entities can be coded appropriately back to a prioritized asset – either in financial or material terms.  This gets us that much closer to being able to prioritize all work that comes into the system….prioritization through association.

The Road to Portfolio Analytics