Surprising thoughts on IT portfolio management

I was in Phoenix this Thursday to lead a conference session at the EFM IT Symposium on managing information for litigation, audit, and regulation. I got there at 8:30 for breakfast and, with two cups of decaf on the table in front of me, was ready to sit through a pleasant (but more than likely underwhelming) keynote address. What I got, however, was refreshingly more than I had expected.

Russ Bostick, CIO at Conseco (which is rebranding to CNO Financial Group), was the speaker, and the topic was IT Portfolio Management—which doesn’t exactly jump off the page as compelling for an 8:30 am slot running on decaf…but before we even got through the first slide, it was clear that we all were in for a valuable 45 minutes.

A bit of disclosure before I begin: my firm has a strong relationship with CNO Financial Group, and we’ve done a range of different ECM projects for them over the years… many of them during Russ’ tenure there and many of which I’ve personally been a part of.

With that out of the way, I want to go over some of the key points Russ hit on, because to me they got to the essence of running a world class IT shop…and therefore of a world class organization in general.

Let me begin by saying that he covered a lot of ground in this presentation, much of it informed by a deep understanding of best practices (especially the COBIT portfolio management framework), but that the lion’s share was informed by his actual success in transforming Conseco IT during the challenging years of restructuring immediately following its bankruptcy.

For me, the “aha” moments in the talk came from two points:

1. When done properly, IT portfolio management is about risk management NOT program management
2. When done properly, IT portfolio management is akin to managing financial portfolios rather than a collection of technology applications

Let’s talk a little about what resonated for me in both of these.

IT Portfolio management as risk management

From the perspective of the larger enterprise, everything a for-profit company does should either be about making money or reducing risk. Full stop. And as hard as it might be for technologists to believe, this also includes IT.

Now I’m a technologist, so I consider myself part of this group and guilty as charged…with good reason. In IT, most of the time we have a laser focus on designing, building, deploying, and maintaining very complex systems, the successful operation of which is the lifeblood of our organizations. After all, this is precisely what we’ve been hired to do—and what we get fired for not doing.

But it’s important to step back frequently and remind ourselves that everything we do in IT is a means to an end, not an end in and of itself. Our work only has value if it delivers value to the organization; if it doesn’t—no matter how well designed, executed, operated, cutting edge, interesting, or well intentioned—it is irrelevant. As my colleague and mentor Chris Cotteleer often says, “Nobody wants a drill, they want a hole in the wall.” We might reframe this in this context as, “Nobody wants IT solutions, they want business-relevant results (i.e. value).”

IT portfolio management, as Russ laid it out in Phoenix, is a structured, ongoing process to help IT “step back” and consider the value it provides to the organization (today and in the future) and to think of ways to maintain (and hopefully increase) that value over time.

Here are some of the key high-level questions Russ presented as critical to the IT portfolio management process:

• How old is each asset?
• How long is the expected life of each asset?
• How comprehensive and accurate is the documentation about each asset?
• What is the platform and specifications of each asset?
• How easy/difficult is it to support each asset?
• How easy/difficult would it be to migrate each asset to newer and/or standard platforms (if available)?
• What is the age of the staff that supports each asset?

The upshot of this line of questioning is two-fold: first, it encourages IT to understand its applications as well as it understands (or should understand) its desktop hardware; second, it encourages IT to view applications in terms of the risks they pose to the organization, e.g., of aging beyond their useful life, of not being understood well enough to operate and maintain, of being resistant to migration/replacement, and of being without experienced staff to operate and support them.

However, there’s more to organizational value than managing risk—there’s also making money—which is precisely what financial portfolio management can teach IT portfolio managers.

IT portfolio management as financial portfolio management

So I had a few takeaways from Russ’ parallels between IT and financial portfolio management.

The first is that it encourages and enables an asset management orientation rather than a project/program management one.

Now, before all the project managers out there start sending Russ angry emails for disparaging the noble and storied guild of Project Management (of which I am a proud and PMP-certified practitioner), it’s important to understand what I think he does and doesn’t mean by this.

What I don’t think he means is that project and program management are not an important part of the overall IT portfolio management process. Russ pointed out from the start that it’s absolutely critical to make sure that all in-flight IT projects and programs run smoothly, don’t step on each other’s toes, get done on time and on budget, and all the other good stuff project/program management does for an organization. But he bracketed this particular aspect of IT portfolio management as something related to, and very distinct from, the aspect he took as his subject matter: risk management and value analysis.

Given that, what I think Russ does mean by introducing the distinction between an asset management approach to IT portfolio management versus a project/program management one comes down to this: asset management is concerned with describing and managing the value an asset has for the organization, whereas project/program management is about executing work, the value of which has already been determined by the organization before the project/program even starts, rather than considering the value of that work itself.

The second takeaway I had was that viewing IT portfolio management as akin to financial portfolio management encourages long term thinking—or at least longer term thinking than a project/program management approach does. Just as in a financial portfolio, where you might have assets that live for many decades (think bond maturity), IT assets have a surprisingly long life with critical value and risk implications for the organization that are often difficult to predict or express.

The example Russ gave from the insurance sector is an apt one: when a company creates a life insurance product to sell, part of the product development process is to estimate the total cost of servicing that product, which, if the product gets sold to a 25-year-old, could include over 50 years of customer support (and even longer if the policy provides for a structured annuity to beneficiaries over their lifetime). The complexity and uncertainty in this equation, just for a single dimension like customer service, is staggering: for a policy sold in 1975, phone and paper mail were the two customer service options; round about the year 2000, these expanded to include email and internet customer portals; in 2010, options include secure chat and text messages; in 2020? Anybody’s guess. Now expand this equation to consider some of the other relevant dimensions, like payment processing, customer communication management, and regulatory compliance, and then multiply it by the total number of insurance products the company offers—short term thinking can’t possibly frame the issues the way an insurance company needs to in order to remain successful over the long-haul.

Russ’ point in all this was that if IT portfolio management is done with a project/program management focus, the total cost of ownership (TCO) around customer service for the relevant assets (the applications that support the policy) would only include the costs known at the time the assets were developed—in this case, 1975. But over the expected life of the assets, the context of the TCO around customer service changes dramatically, which results in equally dramatic increases to the cost for customer service and therefore to the TCO of the assets.

Now, can IT portfolio management prevent these escalating costs? No. But it can do the next best thing: make them visible to the organization and give it some of the tools it needs to do something about them.

The last takeaway I had was that treating the assets in an IT portfolio as similar to assets in a financial portfolio can change the perspective of key decision makers (i.e., the CFO) about the work IT does. Russ’ feeling was that the more IT thinks about and discusses its applications like financial assets, the less likely the CFO is to see them as representing cost to the organization and the more likely she is to see them as ways to reduce risk or increase value or both—a good place to be from a funding perspective.

The final word

One more disclosure is needed here: all of the preceding analysis is the product of my memory of Russ’ talk and my furiously scribbled notes (and I’m a lefty to boot), so I want to give Russ credit for the all the  solid thinking people might find in here and blame my memory (or handwriting) for anything that seems off-kilter or confusing. Feel free to let me know about either, as well as about your own thoughts and experiences on portfolio management, IT or otherwise—always glad to have a conversation!