service strategy Archives - Deep Creek Center

Portfolio of What?

Many organizations struggle to understand and differentiate project portfolio management from service portfolio management. This is an important distinction, because project portfolio managers understandably focus on the project portfolio. This is useful, but ultimately misses the point of looking at the investment of service assets across the service lifecycle.

The basic idea behind service portfolio management is simple but profound. We only have a finite number of service assets available to us, and the goal is simple in concept though tremendously difficult in practice: optimize the value you create for your customers, and the value you capture as a service provider.

Strategy is fundamentally about dealing with constraints. If we didn’t have constraints, we wouldn’t really need a strategy, just a plan to execute. Because we are not omniscient, we need to establish strategies to help us best assess cost, risk, and value of delivering different types of services.

One of the fundamental objectives of most service management initiatives is optimizing investment, especially in areas of the organization such as service operation. By using service portfolio management, the focus is not only on optimizing the performance of projects, but ultimately the shifting of resources from reactive activities to proactive activities that drive better value for the organization.

Many organizations focus on the service operation and transition process areas of ITIL, but much of the better value proposition is actually higher up in the service lifecycle. Take the time to explore some of the value of the service strategy and service design books.

Build out the higher end processes. It’s well worth your time and investment.

Putting the Service in IT Service Management

Many people understandably think about ITIL as a process framework. When you describe good practices for 25+ processes and capabilities it seems a no brainer. Yet when you look at the books, their names, and their objectives, it becomes clear that processes are an important means (COBIT calls them one of seven enablers), but that the desired end is delivering services.The entire concept of service in ITIL is embedded in thinking end-to-end; how service teams facilitate outcomes for customers and manage costs and risks on their behalf.

When I teach ITIL courses, I emphasize the idea that services describe not in fact what we do in IT, but what the customer gets. How do our hardware, software, people, processes, etc. produce valuable results for customers and enable them to perform better, faster, or more cost-effectively? The entire construct of information technology is predicated on the CSI model, or how the technology enables the use and processing of information to automate and otherwise facilitate business processes.

If the goal is services (and therefore outcomes for customers), the how-to is the Service Lifecycle. WAAAAAAYYYY too many people consider ITSM consistent with the operational and support process around Incident, Problem, Change, and Configuration Management. In order to set the table for success in those operational processes, we have to be able to manage the service first. Here is a brief summary of how the Service Lifecycle notion really supports the cultural transformation from technology provision to service and outcome enablement.

Service Strategy – there are many things we’d like to do, but simply cannot. Why? Not enough money, time, people, etc. In short, we are always facing some type of constraints. Therefore, given all of the things we could do, what things will we commit to do, and who decides? Service Strategy outlines a transparent way to make strategic decisions in the face of uncertainty and limitations.

Service Design – how do we understand customer requirements for a service (utility and warrant you), and how do we in turn build/buy/integrate a service to meet the requirements. The Service Design processes enable us to essentially take a piece of paper (a Service Charter, and Approved Change Request, etc.) and transform it into a new or updated service.

Service Transition – my usual flip statement about Service Transition is how to take a new or changed service from development successfully into production without “blowing stuff up.” Sadly, the industry data continues to finger transition practices as a primary reason for production incidents. In the highly dynamic and Agile world we are working in today, change is normal and a fundamental source of competitive advantage in business. Our ability to streamline transition practices and build compelling and highly reliable models is critical to supporting highly iterative business needs.

Service Operation serves essentially as a party host. Deliver services to customers according to our agreed levels and support them as needed. In order to actually be able to operate services, we have to be able to visualize them (typically through a CMS), monitor them, and be able to coordinate support for them across a number of technical/functional teams. The service lifecycle emphasizes early engagement with operations teams during design, transition ( and even strategy) to ensure we don’t get over our skis when establishing service targets that will be incorporated into SLAs.

CSI emphasizes the need for accountable owners and the intentional and ongoing use of metrics and measures to drive ongoing, consistent improvement in the performance of processes and services. CSI supports process and service owners (and managers) in the proactive seeking of improvements in all practices across the lifecycle, and drives the execution of the 7 step improvement process to execute improvement projects and drive iterative improvement in practices.

While each service lifecycle stage clearly uses processes to carry out many of their activities, the bigger value proposition is how the service lifecycle itself visualizes how we manage constrained resources to optimize service value delivered for customers. In this blog we will explore many processes, but you will see me tend to tie these back to bigger picture questions that hopefully answer the “so what” question for you. If we follow these practices, so what? Stay tuned!

What you need to know about ITIL

Was just reading a white paper that a co-worker of mine was using to help explain the basic objectives of ITIL, and it was reflective of its publishing time, mid-2007, when many of us were struggling to figure out exactly how the alignment of V2 processes and the V3 lifecycle would work. There are many good summaries (the ITIL Pocket Guide is great…if you already know it anyway), but you might use this approach to explain it.

While many people think ITIL is about processes, that is at best an incomplete point of view. ITIL is about changing people’s perspectives about the tasks at hand we perform in IT. It’s not about the technologies, or even the whole end-to-end IT services, but how (or whether) these services effectively underpin our customer’s business processes and enable the business’s outcomes; revenue, profit, market share, or simply meeting the organization’s mission and vision.

IT Service Management then is about how we produce, maintain, and sustain services to deliver VALUE to our customers (in the form of services that enable them to perform better, faster, or more cost effectively than they might otherwise). The Service Lifecycle that underpins ITIL describes 5 key aspects or stages of this effort. While there are much more authoritative conversations about the following, if you get the following big ideas, you’re on your way to really understanding ITIL.

1) Service Strategy – In life, we don’t get everything we’d like. This is usually because of constraints; time, money, a jealous spouse, you get the idea. The goal, therefore, is to maximize the value we can create (and that we get!) given the limitations we have. IT Service Strategy works the same way. There may be many things we would like to do, but given our time, money, and other resources at our disposal, which ones will we commit to do, and how do we decide? The concepts of Service Portfolio Management, underpinned by Financial and Demand Management, populates good Business Cases for how we can choose wisely.

2) Service Design – Once we’ve decided that to provide a particular capability would be a good idea, we need to align our customer’s requirements and desired outcomes with our service targets. This includes decisions about the service’s utility (what it does) and its warranty (how well it does it, how well it’s protected, how much of it there is, etc.). Service Design takes theoretical models of what a service MIGHT be and transforms it into actual working services, with transition, operational, management, and measurement supports.

3) Service Transition – Regardless of whether we’re looking to add a new service, change an existing one, or retire (or transfer) one altogether, transitions create risk. In particular, risks of causing business impact and disruptions when we deploy changes. Transition is about managing those risks and delivering the intended value that drove the business objectives and goals in the first place, and ensuring that we effectively move services out of development and into production…without blowing stuff up.

4) Service Operation – Once services are live, customers have one basic wish…keep them up and running so they can work. Service Operation describes proactive and reactive ways to manage, maintain, and support live services to keep them available and keep the business processes flowing.

5) Continual Service Improvement – The magic word here is continual…not occasional (or never, except when the boss is really mad). All services and all processes can improve; we learn, and the magic trick is to be culturally agile enough to make many, many small iterative improvements to your services and processes as you learn them. This can be as easy as building a knowledge base of known incident resolutions and Known Errors, or can involve detailed trending analysis in the search for performance enhancements. If CSI becomes “normal” in your culture, you’ll learn what many other types of organizations have learned over the last 60 years; that while managers the world over seek “quantum leaps” in improved IT performance, most of the time real organization maturity requires time and a consistent willingness to “hit singles”, or make small improvements that consistently build up lots of small, incremental benefits.

I don’t pretend that this is ALL you need to know about ITIL, but many people who hold ITIL certifications miss the bigger picture. Yes, there are processes, functions, roles, etc. They are a means to a bigger end; customer outcomes that help that customer meet its mission and compete and win in its market space.