I’ve spent some blogging cycles this week talking about the evolution of IT portfolio selection processes – specifically that there is a natural maturity curve from what I am calling a tightly coupled model of fragmented IT delivery and a decoupled model of consolidated IT delivery. I’ve also pointed out that there’s almost a chicken-egg relationship between IT portfolio optimization and the IT funding model.
Illustrating the Coupled Model
Let’s take a look, shall we? To illustrate this point, let’s say that our software vendor, in this case Microsoft, follows a tightly coupled funding model. In this model, the customer may have a need, say, to manage agile projects in Microsoft Project Professional. The customer goes to his Microsoft account representative and says, “Can you create an agile function, specifically tailored to our requirements?”
The Microsoft account representative goes back to Redmond and chats with the Product Team. She goes back to our customer and with pinky firmly planted next to her lips does her best Dr. Evil impression by telling the customer that this can be done, “for 1 million dollars!” Chortle, chortle.
Now, our customer is no dummy. He knows that while he needs this agile functionality, he doesn’t “need need” it. He can wait. He knows some other customer will step up and pay to develop the functionality he needs, and until then he’ll just make do. In fact, he’s read books on Game Theory, and knows that if he just waits long enough, he can reap the benefits of someone else’s investment. In the meantime, maybe he goes and buys something off the shelf that sort of meets his needs and doesn’t need to hit the IT radar.
What’s the moral of this story?
- New features won’t get implemented until long after they’re actually desired.
- Business units play games to try to push the costs off on other units.
- The net result is that IT is playing catch up to the business.
…And the Alternative
What about the alternative? In this case, and this is purely hypothetical, Microsoft has a large customer base for the product and bills by the user, say in some sort of arcane licensing scheme that only the high priests of the Temple of LAR understand. Microsoft can relatively accurately predict licensing revenue for the next year, and strategically decide to set aside a percentage of that revenue for further investments in the product. That sets the stage for the investment portfolio.
Our customer again needs agile functionality, and again approaches the Microsoft account rep. This time, when she goes back to Redmond, the team agrees to throw the request into the feature backlog. When the annual planning cycle rolls around, they perform a survey of their top clients and prioritize the feature according to the results. The priority dictates where the feature falls in terms of absorbing a portion of the available investment portfolio. Assuming the feature is ranked high enough, the team develops it, and makes it available through the SA ritual practiced by the priests of LAR.
This latter example is what I am calling a decoupled model. Features are developed and prioritized within the constraints of an investment portfolio, and not individually as requested by the business.
Here’re a couple characteristics of a decoupled IT portfolio selection model:
- Projects are bundled into logical programs that leverage economies of scale to deliver capabilities across multiple business units.
- The program bundling supports consolidated investment in the platforms upon which processes are enabled.
- IT is proactively identifying what the business will need in the future, and incorporating that in all ongoing service design activities
To the Cloud
…which means that to accommodate this economy of scale, we need to find a more mature IT funding model. Slicing and dicing our portfolio at the project level and funding at that level from our business units doesn’t enable us to get the consolidated benefits that a decoupled portfolio can deliver.
Perhaps a user based revenue model doesn’t apply as many users end up not using the solution, or end up using the solution less than more advanced power users. In this world, to make things more equitable, we may need to find a different funding model, something like transactional costing. In transactional costing, the cost of developing and delivering the service is recovered using metering. The respective business units pay per use, and in return get a solid service and don’t have to worry about more complex cost models.
Sound familiar? The logical conclusion of that decoupled model is the cloud based model. IT portfolio optimization maturity inevitably leads to the cloud or at least a cloud-like decoupled service model.