Frameworks can be very useful things. They allow folks like myself and my colleagues to walk into almost any organization and quickly size them up in terms of maturity, capabilities, and well, let’s face it, consulting opportunities. The risk of course is that we size up the organization incorrectly – or worse yet, we don’t bother to size up the organization and apply some sort of standard best practice drawn straight from the latest consulting memeplex. (That never happens.)
Many times, we don’t even realize that we’re applying a classification scheme – until we take a step back and realize that we’re taking a totally different approach to the current organization than we did to the last organization. When those sorts of epiphanies happen, I like to sit back and identify intellectually why I adapted the approach and see if I can turn that into a theoretical framework. This post is the result of such an exercise.
Portfolio Types
I tend to cross operational domains about once a year, typically bouncing back and forth between pipeline construction and IT portfolio management. Needless to say, these two domains seem to operate in entirely different worlds – with different priorities, operating goals, and differing concepts of velocity. When was the last time you heard an IT shop talk about dropping a developer into the project via helicopter to ensure you make your deadlines?
When you talk to pipeliners about missions and portfolio optimization, you tend to get a blank stare. That’s usually because project decisions are often made by the Marketing folks. They work with customers to identify whether or not a new pipeline would be profitable, conduct feasibility studies, and then after all of that, they issue the marching orders to go build the pipeline.
IT tends to struggle with its fundamental mission, often not able to articulate why, in fact, a project has been selected. That doesn’t mean though that all of IT operates significantly different than a pipeline company. For example, try going to an IT consulting shop one day and asking them how they select the projects they do. You’ll probably get the same answer as the pipeline company above: The salesperson made the sale. Delivery did a feasibility estimate. The consulting shop has chartered the project and expects to make a profit on it.
Tiered Portfolios
The difference in IT (support) having a tougher time articulating why it selects projects vs. IT (consulting) stems to one extent from the fact that IT is typically regarded as a cost center. In other terms, if I go back to my ITIL training days, the two portfolios represent different service tiers within an organization:
A tier 1 organization is responsible for providing services directly to the organization’s customers, the people who pay money to the organization for the services it provides. Tier 2 organizations provide services to the tier 1 group, i.e. tier 2 provides the tools to enable tier 1 to generate value for the customers.
I submit that a tier 1 portfolio, being directly responsible for the provision of profitable services to the external customers of the organization, has a much easier time of defining strategy. Essentially that’s whatever’s profitable and fits within the long term goals of the firm.
It’s the tier 2 portfolios that are a bit more challenged. The tier 2 portfolios are charged with supporting the mission of the organization, i.e. facilitating the job of the tier 1 service provider. Hence, tier 2 portfolio optimization tends to suffer when the organizational strategy is poorly articulated. When you look at a traditional project portfolio selection process such as AHP, you’ll see that it almost invariably is targeting the tier 2 portfolios. You almost never see portfolio selection guidance applied to tier 1 portfolios.
To Couple or Not to Couple…?
Now we have the concept of a tiered portfolio defined, let’s take a look at another concept: the coupled portfolio vs. the decoupled portfolio. Many IT portfolios are tightly coupled with the business (tier 1) portfolio. This means that IT projects are chartered to directly support a business project. If the business plans Project A as part of the annual planning, IT plans an IT Project A. If business plans Project B, IT plans an IT Project B.
I’m almost certainly oversimplifying here, but the idea is that IT has a poorly defined strategy, and is simply following the tier 1 lead. That’s not necessarily a bad thing, but it does have a couple of implications:
- IT is always reacting to the business needs and not proactively driving to meet forecasted needs.
- IT tends to not be able to invest in options analysis, i.e. it’s more difficult to set aside money to identify alternatives to achieve a specific goal, as the business is often not interested in investing in these optimization exercises.
- IT programs are poorly defined and often fragmented. There is often only a transitory acknowledgement that projects belong to programs, and those programs are the ones defined by the business.
- There is minimal investment in shared platforms to support business projects. Coordinated investment is replaced with piecemeal investment where the shared platform is only upgraded when the business is willing to attach the funding to a specific project.
That’s what a coupled portfolio looks like. In my next post, I’ll talk about the implications of a decoupled portfolio.
Project Epistemology 