IT Services Development Rationalization

As promised, this blog will discuss dual level rationalization that is critical for successful design, implementation and operation of the Service Provider Model.
The first level is "service offerings to market rationalization".

1. Identify and validate market demand .
   Ideally this comes in the form of an IT Strategy document that was developed using the company's Business Strategy as the primary input. The Business Strategy should represent each of the organization's business units.
   Leveraging these three things - a.) the IT Strategy document; b.) operational experience supporting the organization's business units; and c.) industry trends - each IT functional manager should be accountable for extrapolating out their specific service offerings and capacity estimates.
   
2. Define v1.0 of the service offerings that are expected to deliver the range of results that align to the market demand
3. Validate the v1.0 service levels range of options with the market
4. Make modifications to the range of service offerings based on the output of step 3
   

If the steps above have been successfully completed then it is appropriate to dive into the second level of rationalization: "service delivery operations to service level rationalization" (quite a mouthful if I do say so myself).

1. Using the each service level as the design specification, architect/engineer the service delivery operations. My recommendation is to break this out into the critical processes and activities that are required to attain and sustain each specific service offering's service level targets, and then weave the appropriate roles and responsibilities and technology architectures into that framework. By doing this, you have positioned yourself to do activities based costing and budgeting which in my experience is the heart of high performance service delivery operations.
   Although this design process should have a service offering focus, it will be important to pull up to an aggregated view in order to take advantage of all possible economies of scale relative to technology, process and people throughout the range of service offerings.
   
2. With the above step completed for each service offering, you now have all the cost drivers and associated capacity estimates to calculate unit cost for each service. You should have a cost model that supports the allocation of cost and capacity to predefined allocation targets where the allocation targets represent each unique service offering.
3. With the unit price for each service offering now available, you have all the ingredients for a true menu just like you get at any restaurant (except for the lamination, coffee stains and germs of who knows how many people). The menu lists the service offerings each with brief description along with its unit price. In this step I recommend that you take that "menu" back to the market and do another level of validation. You should expect minor tweaks here and there but nothing significant. If you do completely miss the mark with the market at this validation point, then it is a good indication that you weren't thorough enough in the "service offerings to market rationalization" process.

When your "service delivery operations to service level rationalization" process becomes very mature, you can rationalize any future investments or proposed change through a "what if" modeling and analytics process. This level of decision support significantly accelerates efficiencies at every level of operations. But that is a post for another day.

What's the Scope of this SPM/ ITSM Blog Anyway?!!!

In the last posting, I laid out some of the primary drivers for ITSM adoption among IT organizations. That general articulation of the problem statement will continue to be the context for all content posted hereafter in which we discuss approach and methodology to the design, plan, deployment and continual improvement of the Service Provider Model.

In an effort to bring some focus to the broad ITSM topic, this blog will initially focus on the following ITSM sub-topics:

• Service Level Management
• IT Services Development
• Service Catalog Development, Deployment and Maintenance
• Service Performance Monitoring and Reporting
• Services Costing
• Service Level unit costing, capacity, run rate, cash flow
  
• Future state investment modeling (TCO, ROI, NPV)
• Activities based budgeting and costing
• IT Service Selection process engineering and deployment
• IT Service Demand Planning process engineering and deployment

To set expectations accurately, it should be noted that in order to cover these sub-topics with any degree of completeness, we will be referencing other ITIL processes such as capacity management, availability management, IT service continuity management, business relationship management, service portfolio management, configuration management, change management, incident management, problem management, and release management. After all, these processes play an important part in sustaining desired service level performance.

For those just beginning the journey into the practical implementations of the SPM/ ITSM you will likely find yourself overwhelmed by a plethora moving parts that require integration for success. To keep your sanity and clarity, I offer this bit of advice that I still observe on a frequent basis.
The sole purpose of every activity and investment of a service provider must exist for the sole purpose of meeting or exceeding the published service level targets of all active customers of that service provider. If that correlation does not exist, then that activity and/or investment should be eliminated.

However, my little filtering tip comes with the following key assumption:
The IT service provider's published service levels, which drive all activities and investments, had better address 80% or more of their customers' needs. In other words, before you start investing in technology, process or people, validate your standard service offerings with the market that you serve.

I will use my next post to describe this dual level rationalization process that is the prerequisite for successful implementation of the Service Provider Model.

What is Driving the Need for ITSM Today?

Due to the IT portion of business budgets growing exponentially, it has become critical for business executives to get control over their IT spend and the value for their IT dollar.

To address this critical need a model must be put in place to enable business units to work with an IT service provider who makes available a range of standard IT service options that reflect business demand, have predictable outcomes, and can be purchased “by the drink”. And like any mature service in the marketplace, that cost per “drink” (referred to as unit cost) should be proportional to the level of service selected. This desired model must also provide a simple yet effective service selection process for matching the requirements of unique business requests to the standard service options which best deliver balance between cost, risk and quality.

I continually refer to this desired state as the “Service Provider Model (SPM)”. Businesses today need their IT suppliers to deliver the Service Provider Model. As business units recognize this need, they are then faced with the million dollar question: “Is the Service Provider Model available through our internal IT organization; or do we have to look to outsourcing; or is there some combination of the two?” The answer to this question is driving strategic direction for a rapidly growing number of IT organizations across the globe.

So what are the specific pain points within an IT organization that has not yet attained the SPM?

• Inability to "quantifiably" rationalize IT investment to business demand
• Poorly defined services or no defined services at all
• Lack of visibility into the true cost of IT services being delivered
• Inefficient process for aligning application requirements to the appropriate infrastructure solutions
• Lack of service performance monitoring and reporting
• Ineffective or non-existent IT service demand planning
• A lack of predictability for IT service delivery results
• Lack of mature policy and process pertaining to IT service delivery and support

In one of my next postings I will get into addressing these pain points. Before I do that I should probably put some scope around the broad topic of ITSM and the SPM.

Till next time...