Defining an IT Service Portfolio

From the The Business Driven PMO Blog
Stories from the trenches and practical advice on how PMOs can more effectively support, prioritize and fund strategic business initiatives.

About this Blog


Recent Posts

What’s So Bad About Spreadsheets?

Top Five PPM Trends to Watch Out For in 2014

Insights and Trends: Current Project Portfolio Management Adoption Practices

Life after project completion: Is a project complete without benefits realization?

How Important is Adoption for a PMO?

Back in my CIO days I received a call from the VP of Sales who was travelling in Helsinki at the time. That I had a 24x7 global support team was not relevant – he was a VP and felt entitled to call me at 2 AM in California with his urgent problem – to wit: “Dave – email is down and I’m working on a critical RFP! DO SOMETHING”. Of course my next call went to my support team, which promptly informed me that no, the Exchange server was up and running. After a few moments of groggy contemplation, I shot back:

“Bob in Helsinki doesn’t care if the problem is the Exchange server, the router, his Internet connection, the Outlook client, or any other piece of the puzzle – all he wants is his email – and it’s your job to figure out why he’s not getting it”.

This leads to two major lessons. First, don’t roust a CIO at 2AM – we can be a bit testy. Second, users care about the business services we deliver, not the technology behind them.

This story is a classic example of a business service provided by IT. For the most part, we should build IT around business capabilities required by the enterprise. This means they should be labeled with business terms. While email may also be a technology, it is today a universally understood business term as well – as demonstrated by my friend Bob. Other services commonly provided by IT would include Inventory Management, Sales Force Support, Customer Account Management, Lead Distribution, Supply Chain Management, etc. etc.

This story also illustrates one of the core difficulties of IT. While the enterprise needs business capabilities, what we deliver is the underlying technology to enable those capabilities. We need to somehow translate those business needs into technology delivery components.

To achieve this, it helps to start from the top down in the world of strategic enterprise architecture. Done right, EA consists of a stack that starts at the top with business needs, drills down into the applications needed to support those needs, then further down into the infrastructure components (servers, networks, etc) needed to support those apps. The idea is to design from the top down and build from the bottom up.

To get at that top layer of business needs it helps to divide them into like groups. Organizational groupings are a great start – starting with Enterprise needs (think email, telephony, productivity, etc) then into individual departmental needs, like financial automation, sales support, and manufacturing processes. Inside each of these groups is a set of capabilities. Let’s take financial automation as an example. We could break that down into the automation of the major finance processes – quote to cash, procure to pay, and record to report. We can then look at the applications needed to automate those processes – the first technology layer. For quote to cash, this would typically include the quoting module of an SFA system like Salesforce, the Order Management, Invoicing, Accounts Receivable and GL modules of an ERP system (like SAP) and perhaps a Business Intelligence tool like Cognos.

Finally, to support those systems we need the Infrastructure components – servers for SAP and BI, network and internet components for those and Salesforce, and client components for the desktops/laptops.

So, a completed EA stack allows IT to understand all the components needed to support the delivery of a business service. And this information provides the basis for building our service portfolios. While the business needs are services, those like groupings of business capabilities are the service portfolios.

When building service portfolios, I recommend sticking to a couple of basic rules:

  1. Make sure your portfolios group like business services – like all the financial services or selling services.
  2. Make sure your underlying services are stated in business terms – not technology terms.
  3. Make sure these services provide business value and can be measured (eg: % of email delivered, orders processes per month, inventory turns)
  4. Review the completed portfolio and services list to make sure it is comprehensive and makes logical business sense

ITIL V3 talks at length about Services and Service Portfolios, and I think a true understanding of how to build those services and portfolios comes from this enterprise architecture view. Without it, you could end up with service portfolios that look like “Application Services” and “Communication Services”. These still talk about technology and won’t make sense to the average business user.

Just imagine Bob’s response if I tell him we’re having a “Communication Services” issue. He’d say something like “you’re darn right we’re not communicating! Now how do I get my email?!?” 

Posted on: August 12, 2011 01:29 PM | Permalink

Comments (0)

Please login or join to subscribe to this item

Please Login/Register to leave a comment.


"The secret to creativity is knowing how to hide your sources."

- Albert Einstein