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.
- The Application Portfolio (e.g., providing the applications and support to business units)
- The Project Portfolio
- The Infrastructure Services Portfolio (e.g., e-mail, network attach, remote access)
- The User Services Portfolio (e.g., help desk, PC repair)
- 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.