The most frequently neglected phase of sourcing is the preparation of the enterprise's current IT service delivery. “Don't outsource your problems!” is a well known phrase in the IT industry, and one that is increasingly becoming a reality.

There are a number of key activities an organization must complete before considering the development and implementation of sourcing:

Service Level Agreements (SLA)/Service Level Requirements (SLRs)

Creating a Service Framework

Traditionally, organizations develop, implement and change IT services in a evolutionary process. Although change management may occur at a functional level (e.g. server infrastructure, software development or network management) to ensure service quality, few organizations have reached the level of having a complete service architecture that integrates all aspects of service delivery and service management. Even fewer are able to integrate this architecture with traditional technology architectures and data models. The result is a collection of processes, delivery teams and infrastructure that have dependancies that are not well documented or understood. In such an environment, the impact of changing to a sourced relationship for service delivery may have a severe negative impact on service quality and performance.

With a good understanding of the IT services being provided by the enterprise through the service catalog, the next fundamental step is to create an architecture for service delivery. The service delivery architecture, or service framework, is made from a collection of reusable modular components.

To identify these modular functional components and build a service framework, enterprises must first understand what processes, input/outputs, service levels, infrastructure and delivery teams are involved in delivering each service.

This information can help easily identify the functional components that are required to create the service framework. A hub must have the following attributes:

Financial: Understanding the cost of delivery and business value of IT services is critical in identifying the price a service provider needs to meet. This includes an audit of all the assets and the importance of the service to the organization.

People: Knowing the skills and knowledge required to deliver the service allows enterprises to develop a skills transfer strategy to the service provider.

The most difficult of these process is financial baselining. The ability to attach cost of delivery to specific services is impeded by the complicated way IT services have evolved. A lack of documentation of resources and processes limits the ability to do a formal service-based costing financial model. As mentioned in the previous section, creating a modular service framework with defined process, input/outputs and service levels is crucial to successful financial baselining. Using the definitions of the services frameworks and functional components, the amount of resources, including technology and people, can be calculated. If it exists, the business continuity plan is also a crucial source of information for assessing the business value of IT services. A business continuity plan should outline the costs of loss of service, including qualitative and quantitative values.

For a mature organization, service quality baselining should be a basic part of IT service management. Organizations should regularly measure and report the critical parameters that contribute to user satisfaction and business value. In addition to this, the input/outputs of the functional components that make up the service framework should also be measured and reported, if only to the internal IT organization. This is essential if the sourcing strategy includes sourcing a functional hub (e.g. network management) but not the entire service framework. These hub measurements will also feed into the Service Improvement Plan (SIP), as improving each hub will help improve the overall framework. In addition, a baselining process should be performed on VOC to understand user satisfaction and requirements.

An assessment of the current service delivery capability is a critical factor in determining the SIP. An audit of service management and delivery processes will identify areas of improvement. These improvements will need to be agreed upon with the provider as part of the sourcing process. An assessment should measure the service management and delivery processes against industry best practices. The Sun IT Management Framework is an example of this, as it combines a number of industry frameworks and proprietary solutions. The assessment should specifically identify areas which require immediate attention prior to, or immediately after, outsourcing occurs.

Finally, but not least important, is a skills assessment and audit. Included in this process is a definition of roles and responsibilities. This allows an organization to clearly define the skills and roles required from the service providers' delivery organization. This baselining process will also contribute to the development of the organizational transformation.

Baselining resolves big issues for both the enterprise and prospective partners. The collection of baseline data allows the enterprise to understand the state of what is being sourced. Accurate information on the current state of delivery reduces risk for both the organization and provider, helping lower risk margins built into pricing and resourcing of a sourcing solution.

Preparing for Change

The implementation of any sourcing strategy, big or small, can have a significant impact on the enterprise. It may threaten employees' views of job stability and lead to the creation of a new organizational culture. This type of change requires a specific focus on change acceptance.

At the heart of any change effort is the people who make commitments to move the change forward. The objective of change acceptance is to have that individual effort mobilized and committed. As outlined in Figure 4 below, all of the other activities touch it, are linked to it, and drive toward it.

From the previous work completed in preparation, enterprises should now have enough information to engage in a complete change acceptance program, which requires the following key features:

The traditional outsourcing method has had its celebrated failures. Regular reports are published about cost overruns, contract disputes, and poor customer satisfaction. Many of these failures have been due to inflexibility of the sourcing contract, which may not easily change to respond to market pressures and business requirements. It is commonly known in the service industry and outsourcing is cyclic, with companies moving from in to out source and back again. This is extremely and distracts the IT organization from core business.

Organizations need to be able to change the financial model, adjust the IT service portfolio and alter the technology landscape. The blame for this is not entirely in the hands of the service provider. While traditional outsourcing places responsibility on the provider, in reality, a sourcing method has demands on both the organization and the provider.

Poorly planned transition and implementation: Often the solution design and transition phases are performed by completely separate teams (e.g. organization senior management and provider sales vs. organization technical staff and provider delivery staff). Transition is often less that 20% of the solution design effort, but can make or break the success of the sourcing solution.

Smart Sourcing is an evolution of the outsourcing that mitigates the limitations of the traditional sourcing methodology to provide a win-win relationship for the business and the provider over the long term. There are six core principles that serve to guide the implementation and strategy for the sourcing relationship.

The three principles of implementation are:

This is a very quick article to highlight some ideas from a presentation I gave in 2005 at the itSMF conference in Singapore. With the release of ITIL v3 and its increased detail and breadth of coverage. More than ever the question has been asked, "How do you implement ITIL?". The most clear answer I got was at the same conference from the then CEO of itSMF, Aiden Lawes. "ITIL Cannot be implemented!" Never a truer word has been said.

ITIL is a collection of IP representing some guidance on the processes, people and technology to support IT Service Management. IT does not provide the instructive level of detail required to implement and that is a good thing. From my last 8 years working with customers around the world. The difference in the issues, drivers and priorities that exist in different economic markets, cultures and industries is significant. To delve into more detail would immediately cause ITIL to divert away from its current relevance.

So whats the alternative. If you company has had to execute any significant organizational change or big IT project (eg. an ERP implementation) then it probably already has a change adoption process.

So my favourite concept that underpins everything I do it "alignment". The industry press is full of quotes and the research organizations are full of data with info on what causes projects to fail. Big with non-quantifiable metrics would be two of the top 10. So I like the concept of the continuous improvement approach to adoption of ITIL. . Success is "all about" aligning your goals and requirements with the "customer" (however you choose to define that term) and unleashing the innovation within your staff. The critical concept of continuous improvement is to attack the problem one chewable chunk at a time. Process by process, service by service, what ever you urgency and goal requires.

Innovation is the key.. The missing piece of the puzzle which is lost for ever by companies that "outsource" this improvement process. There is alot of knowledge and creativity within the your current staff. They need some facilitation to let it out and a process to make there voice heard. Now BEWARE of the first big pot hole. DO NOT adopt continuous improvement methodologies religiously. They were mostly designed for the highly rigid environments of manufacturing. You need to follow the same approach you do with everything. Adopt, experiment and adapt.

One of my favourite methods for continuous improvement is based on SixSigma (I can hears the screams and uproar as I type). The adaption I have worked with which was also part of the GE culture is the use of facilitated workshops to execute smaller improvement projects. Its light, effective and mostly enjoyable. There are quite a few other key principles of Six Sigma that I like;

A key role of a configuration management database (CMDB) is to store and report information about configuration items. A configuration item can be something as macro or micro as you like. It can be "the street address of your datacenter" or "the dip switch setting on a NIC". It stores all sorts of useful information on each item, like versions, known errors, history of incidents/upgrades, you name it and that information "could" be stored in a CMDB.

The Kevin Bacon game is an old favorite based on concepts of the shrinking world mostly attributed to the author Frigyes Karinthy. The game version is simple: pick any 2 people (actor, director, grip, stuntman) in Hollywood (or the world depending on the version) and there are no more that six links required to relate those people together based on there link to Kevin Bacon.

The underlying concept of the Kevin Bacon game is the utopian vision of the Configuration Management DataBase (CMDB).

A CMDB stores relationship information between each configuration item and other important bits of information (e.g. incidents, service levels, etc..). The way in which this information could be used to improve IT services delivery are limitless. Software Licensing metering, patch analysis, maintenance impact analysis, TCO calculations, capacity management, root cause analysis, incident management to name just a few.

One word of caution. The only thing more mind boggling than the limitless uses of this information, is the technical challenge of making it happen (Demystifying The CMDB, Andrew Conry-Murray). A detailed CMDB would need to store a relationship diagram that would quickly look like a three dimensional bowl of spaghetti. The ability to manage this data in an automated fashion (hence the need for a tool) becomes critical. You must recognize that collecting and managing this information needs a range of processes, including discovery, reconciliation, federation, synchronization, access control, auditing and reporting.

"ITIL cannot be implemented"

I was sitting at a conference in Asia a couple of years ago and a senior member of itSMF got up and made this statement. I can here the ITIL community screaming from here :), but it really resonated with me. Don't get me wrong, I am an ITIL supporter, ITIL Management Certified and active supporter. I had been presenting a continuous improvement approach to ITIL adoption in the conference, so the concept was completely aligned.

My simplistic view of ITIL is it is a collection of good ideas connected together as best practice reference framework. You would be hard pressed to find someone who has executed all of the processes in the framework, and even difficult to find someone who has completely implemented one. A true single CMDB does not exist (you can look here for some products that claim to do some of it), how could anyone have implemented it? Anyway, the rule of ITIL adoption is to work out what benefit (business, operational, etc..) you want to get and then adopt the parts of ITIL that help make that happen.

The classic case study for the failure to have this focus on benefit is best described by efforts of the 2007 F1 GP Factory team. Over the winter break, they went away to develop the FY07 car. The project goal was to improve every aspect of the previous years car. The best practice framework for air flow, engine power mapping, suspension are pretty well known, and these guys strived for the very best execution they could achieve. When they got to the track, they had spent $3 million USD on a car that was 1.5 seconds slower than the previous years car. As a race commentator said; "They spent greater than 3 million dollars on something they could have achieved with a 10 buck lump of lead".

Lesson learned: Always focus on the desired result !!!

The the critical point of adopting Configuration Management is identifying the right detail of information (configuration items) that will achieve the value you are trying to achieve. Don't start trying to catalog every line of a configuration file or field in a database, if your goals are achieved by basic asset management.

In my previous post in "Delivering IT Services" I discussed the pressures that impact the average IT Department in the way the delivery IT Services. These pressures come from the Users and the industry. Success is defined by how the It department gets alignment between these two opposing forces.

I would propose an essential tool for doing this is understanding the "IT Value Chain". The "Value Chain" provides a simple framework for translating the "Users" needs in the form of "Business Objectives" to the "Impacts on IT" which is the definition of requirements from IT to meet these objectives. The value change continues to develop more detail by defining the "IT Initiatives" required to deliver to these requirements.

The next important step is to measure these initiatives against a IT Departments capability to deliver these initiatives. This analysis allows you to understand strengths, weakness in developing an implementation plan.

So, the response to this concept is; "Duh, its obvious!!!" Well my only response is I very rarely see organizations practicing this discipline. It is common sense, but it is not easy. Under the pressures of day-to-day service delivery, this practice is a difficult thing to maintain. It can be considered a management overhead to delivering result. The whole area of ITSM and ITIL is designing around building process and practices that operationalize this practice.

Another reason for this not happening is inability of an organization to clearly state its business objectives. Particularly this gap occurs between executive management and middle management. Business objectives often has many layers, goals, strategy and tactics, often there is not linkage between these layers of objectives. As IT Professionals, this is a problem we cannot necessarily solve. We contribute to the solution, but it requires all the management to have discipline to create this linkage. I have seen people succeed in building this linkage through IT projects that build this linkage (eg. ITIL adoption or Business Continuity), and I have seen a similar number fail dismally.

So whats the "net-net"? Its really about "Do you know how what you are doing contributes to the business objectives to the company ?"

Whenever you start to talk with companies about IT Service Delivery improvement or IT Optimization, the conversation inevitably turns to business alignment (if it doesn't then you are in even bigger trouble). This alignment is due to the ongoing challenge of the IT Department to provide the link between the "IT Industry" and the "IT Users". In the middle of this tug-o-war of activity is the IT Department, a mediator between the two, trying to facilitate a steady equilibrium.

In the inserted image, the external pressures of "IT Users" are shown at the top and the "IT Industry" pressures at the bottom. By no means a comprehensive list, but you get the point.

"IT Industry" is strongly dominated by vendors, but influence definitely comes from professional groups, IT media, investors and and other parties who try and influence the IT industry.

So to deal with this IT Service Delivery executives, management and technical staff have a large range of strategies to consider. Through this category I will explore some of my ideas on what strategies are worth considering and some approaches on how to tackle.