Mar 052010

For many years,Tom Bugnitz and I have been recommending that IT organizations think of themselves as a service business, with five fundamental service portfolios.

  1. The Application Portfolio (e.g., providing the applications and support to business units)
  2. The Project Portfolio
  3. The Infrastructure Services Portfolio (e.g., e-mail, network attach, remote access)
  4. The User Services Portfolio (e.g., help desk, PC repair)
  5. The Management Services Portfolio (e.g., providing procurement, planning support to business units)

We also recommend that IT organizations do their budgeting in portfolio terms — that they should identify the service provided and the costs associated with them. (Over and over again we’ve written in Cutter Business-IT Strategies E-Mail Advisors, “If you don’t know cost, you don’t know anything.”) This approach to budgeting has proven very powerful in understanding IT’s value and contribution to the rest of the organization.

However … the notion of the “Application Portfolio” may be changing in companies and organizations. While we’ve always thought that the boundaries between them are well defined (projects versus applications, for example, or infrastructure services versus applications), it turns out that in evolving management practices, this isn’t nearly so clear. And it may even be wrong.

“Applications” and “projects” are merging. We have always considered an application as a service provided through operations and support (breakfix, etc.) to the business unit. Recently, though, IT organizations are beginning to treat all projects planned for an application simply as a part of the application service. The cost to the business for the application service includes these projects. From the business perspective, there’s no real boundary in their minds between using the application and the stream of projects — big or small — that continually adjust to how the application provides the needed support to the business. In effect, the project portfolio is subsumed into the application portfolio. (Of course, priorities still must be set and PMO oversight provided. This retains some of the portfolio aspect of projects, but is limited to these activities.)

“Applications” and “business process” are merging. We have typically defined the application portfolio as defined by IT — the various specific applications and ERP modules operated in the data centers. However, as applications become more integrated, and as Web access and SOA-like architecture has been applied to more applications, the boundary line between what previously has been thought of as separate applications becomes murky. It becomes less significant to consider each “application” separately from a service provision, or costing, or even from a SLA perspective. The business perspective, as with projects, is that the collection of IT services that provide support for a business function is all of a single thing. Costs, service level/quality, and risk cannot be easily separated into the piece-parts; it’s all part of the support of the business function. Hence, the application portfolio becomes, in effect, a business process portfolio.

“Applications” and “infrastructure services” are merging. This is probably more obvious. We’ve always included the cost of infrastructure as an important cost component of an application. But in this case 3 carrying forward the notion of application/business process merger— the same applies to the infrastructure services bundled in the business process support. This most clearly includes e-mail as the connecting fabric, but certainly includes such elements as portals, warehouses, and other aspects of what had previously been thought of as separate infrastructure services from applications.

So what? Well, we’re struggling a bit with this question ourselves. For our clients who do application portfolio management, we find that we have to provide for these merges. Projects, for example, become part of the cost and service structure for the respective applications to which they apply. Similarly, the inventory of applications becomes more of a business process inventory, though this development is less precise. And we’re considering how to deal with the infrastructure components — they at least are included in cost, but also the value/service-level/quality/risk assessments get somewhat more involved as this occurs.

At the moment, we’re thinking that the whole notion of “portfolio management” may be shifting and that we’ll have to be more direct in responding. At one level, this is very interesting and exciting. At another, this is a great example of how agile we all need to be in developing practices and instruments to help in better managing “value” and “service” aspects of IT.

But here’s the bottom line. We’ve always known that IT by itself is a relatively small item in the business arena — say 5% to 10% of company revenue. We’ve always worried that “IT doesn’t matter.” On the other hand, if these conceptual mergers we’ve described represent the evolving direction for IT management, then, in effect, we’re more directly connecting IT to business process management and — excitingly — increasing the stakes and consequences in improving IT management. That is, if “portfolio management” evolves into “business process portfolio management” or something similar, then we’re no longer dealing with 5% of company costs, it’s more like 40% or more — and that’s where the real money — and value — is.


Bob Benson

Bob Benson is a Fellow with Cutter Consortium's Business Technology & Digital Transformation Strategies practice. His consulting features business value, effective IT application development, consulting methodology development, IT infrastructure planning, and facilitated planning.


  8 Responses to “A Shift in the Notion of “Portfolio Management” Opens Oppty for IT”

  1. Bob

    Really insightful post. Enterprise 2.0 (as least the way that I think about it) is all about breaking down the barriers from 90s-type IT projects. As IT and the LOBs converge, “business technology” professions using Agile methods should make things go so much smoother.

    I agree that the traditional categories that you mentioned might no longer apply, as least as separate parts in a portfolio.


  2. Bob, I’ve been looking at this as well and am basing my work on four major lifecycles: application, infrastructure, asset, and technology. This is grounded in turn in entity lifecycle analysis which I think is amenable to Lean value stream mapping. See Curious what you think.

  3. Bob,

    I agree with the blurring of the lines between the IT activities, but I do have a problem with the application of the Service-Consumer model of providing IT services for software development.

    I’ve blogged about this at

    Dave Rooney
    Cutter Consortium Senior Consultant
    Westboro Systems

  4. avatar

    Dave – We’re talking past each other. In looking at your blog and writings, I can completely agree with you that the act of business process software development is a joint effort.

    But I haven’t been clear about this. Our use of Service Portfolios is about budgeting, alignment, service level / quality, and risk. It’s about cost for value delivered.

    It’s not about the doing per se.

    For example: if I buy house renovation services, I most certainly do not expect the contractor to perform the job like a fast food service – I expect sound engineering, good design, attention to detail, control of costs, selection of materials, etc.

    I expect the contractor to bring all of these capabilities and skills. I am buy a service but I expect sound construction. And, of course, sound methods for working with me throughout the project to determine goals / design / trade-offs. etc. It’s personalized to me, and I’m fully committed and engaged (at least my wife is.)

    What’s my point? From a budgeting, cost/value, alignment, service-level/quality, risk perspective, IT is in fact in the service business. But from a project execution perspective, IT absolutely brings skills, capabilities, methods, standards, etc. and a collaborative joint effort perspective. Making the collaborative effort possible, and facilitating its activities, and building the result, it is not a service, it’s a project.

    So I think we’re both right.


  5. Bob:

    Your points are compelling and timely in regards to understanding the app/service/portfolio facets of Cost and Service Levels. This is especially important as enterprises also weigh the business case for Cloud Computing across SaaS, PaaS, and IaaS realizations in the coming decade.

    Mitchell Ummel, Cutter Senior Consultant

  6. Bob – I do agree that we agree on many points! :)

    However with the house renovation analogy, you still have a distinct separation between contractor and customer, which is what we want to avoid in software development. While the contractor does have a vested interest in success in terms of reputation, etc., he’s still at arm’s length.

    To fit the analogy, imagine that you would be actually doing the renovation for your wife. Your interest in success is much more aligned with your wife’s, and you will bust your rear end to be successful.

    Service Portfolios 3 to 5 in your initial post fit the Service-Consumer model just fine, although we have acknowledged that even that is changing. I’m saying that applying the Service-Consumer model to Portfolios 1 and 2 has historically not worked very well, and should be replaced with the “go native” model where possible or a product development model when work crosses business unit boundaries.

    I guess I’m not seeing the difference between project execution and budgeting, cost/value, alignment, service-level/quality & risk. I believe that they’re intertwined, or at least should be.

    Dave Rooney, Cutter Sr. Consultant

  7. Terrific post which I will share widely.

    Because I work mostly in the business process arena, it might seem a bit self-serving that I’m enthusiastic about disparate portfolios integrating as “business process portfolio management.” However, it just makes sense. For most of us, it’s been 15 or 20 years since we did any significant applications work that didn’t involve business process change, and significant business process change virtually always involves applications work. What was really interesting and new for me in your post was the idea of projects being seen as one more element in the services provided by an application, leading to project portfolios being subsumed into application portfolios.

    Nice work!


  8. avatar

    Any shifts in the “notion of Portfolio Management” occur because I believe Portfolio Management is widely misunderstood and still incredibly immature as a governance process.

    Portfolio Management is Portfolio Management is Portfolio Management. Any class, type, or characterization of a given portfolio should be driven by the strategic goals of the Enterprise and the investment decisions required to achieve them.

    I have always had a problem with ANY form of IT Portfolio Management because, by definition, it separates IT from the business. This is always a mistake unless the articulation of said IT portfolio is done as an extension of Enterprise Portfolio Management – for the express purpose of facilitating IT-service decision-making in support of enabling business process investment decisions.

    The “shifts” I see look more like floundering and flailing. And I don’t fault IT. The fact that the majority of Portfolio Management practices are initiated and driven by IT is an Enterprise problem. IT advocates Portfolio Management as a means of surviving the onslaught of work and the resulting bottom-up approach has never worked well. If anything, the shift I see is Enterprises FINALLY realizing Portfolio Management is the only way they can meet their strategic goals and direction.

    I believe this realization must occur before any organization can take advantage of the sage ideas for IT Service-decision-making you articulate in your post.

    Steve Romero, IT Governance Evangelist

 Leave a Reply

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=""> <s> <strike> <strong>