ITIL v3 Blog : Jeroen Bronkhorst

Managing Cloud Services

jbronkho — Thu, 29 Oct 2009 19:32:00 GMT

This week I visited the annual itSMF Netherlands event where someone asked me the question: How does ITIL address Cloud Services? Without giving this much thought my first reaction was that ITIL provides generic guidance on any type of IT services, so...(read more)

ITIL core books to be updated...is ITILv4 coming?

jbronkho — Tue, 15 Sep 2009 13:06:00 GMT

And the short answer is: no . Just before the weekend the OGC announced their mandate for starting a project to: To update the publications in line with a number of issues raised in the Change Control Log. Not everything will be addressed - some technical...(read more)

Software Asset Management explained?

jbronkho — Thu, 27 Aug 2009 15:18:00 GMT

Last month the ITIL v3 guide to Software Asset Management was published. This guide is complementary to the core ITIL publications and is the result of a review and update of the original ITIL v2 Software Asset Management book. This is good news especially...(read more)

Cost Optimization requires IT Financial Management

jbronkho — Wed, 22 Jul 2009 21:02:00 GMT

Altough this sounds very logical, today many organizations do not have the financial transparency to enable solid strategic business decisions. Typically the financial data is scattered across multiple systems and organizations. And as ITIL indicates...(read more)

Leveraging ITIL to improve Business Continuity and Availability

jbronkho — Tue, 30 Jun 2009 18:21:00 GMT

Since time was very hard to find for me over the last couple of weeks, here's an extract from an article that I created together with John Bennett and still very much applicable today: Security, availability management, and business continuity management...(read more)

What's the latest ITIL news?

jbronkho — Fri, 29 May 2009 09:40:00 GMT

Do you know that: The first ITIL v3 core book (service operations) has been translated in French? Read more ITIL can help businesses survive (and thrive) in a recession? Read more There is a change control system for logging issues and changes on ITIL...(read more)

Rapidly designing detailed IT processes

jbronkho — Wed, 29 Apr 2009 20:55:00 GMT

This is the title of an article that I wrote with a few colleagues and that was published in the book ITSM global best practices, volume 1 and recently republished in the ITSM best practices Gold Edition which covers the best articles from a series of...(read more)

Managing Virtualization with ITIL

jbronkho — Tue, 31 Mar 2009 12:08:00 GMT

According to Wikipedia: Virtualization is a broad term that refers to the abstraction of computer resources. Virtualization nowadays has become an integral part of IT organizations to reduce cost and improve flexibility. Industry analysts position virtualization...(read more)

[Updated] Where to find ITILv3?

jbronkho — Fri, 27 Feb 2009 20:12:00 GMT

It has been more than 1,5 your ago that I created one of my first posts dedicated to ITIL V3 sources. Since then the world (and especially the Internet) has changed significantly, so I decided to update my post and add some more interesting pointers....(read more)

Will ITIL v3 help you through the financial crisis?

jbronkho — Thu, 29 Jan 2009 19:47:00 GMT

Over the last couple of days I have been counting the amount of times that I had a conversation with a colleague around the financial crisis and how to deal with that. The result was a stunning average of three times per day! So I decided for myself that this definitely a hot topic that I have to write a post about in my blog (and of course also to justify towards my boss the time I spent on these conversations...). And voila, here it is...

So what were these conversations about besides cost reduction, job cuts and travel restrictions? Right, the impact of all these decisions and actions on business outcomes. And guess what, from these conversations I learned that probably not many organizations have true control over their business outcomes (read: that service providers are able to manage their services) to the level that they can predict what the impact will be.

Another general consensus that I extracted from these talks, is that there will be a clear difference between A) organizations that make the right decision by having a well-organized management system and know exactly where to cut cost with low risk and predictable output from B) organizations that just take resources and capabilities out without knowing what the effect will be or even if they will survive on the long run...

Now this is probably good news for those of you who have already implemented a service management system leveraging e.g. ITIL v3 and/or other standards and practices. You still need to be careful in making decisions that do not break the system, however you have a bigger chance of surviving from the financial crisis stronger than before.

However if this is not the case, then you may find yourself in trouble now (or very soon) in making decisions on where to cut cost. A short term approach in this case might be to stop/delay investment that has to do with innovations/projects and focus on making sure that your (service) operations delivers as promised and expected. On the long term you might shoot yourself in the foot with this approach as it might undermine your competitive differentiation. This might also not be the best option when your customers need you to be (very) responsive to changing business needs. So perhaps you should keep only 1 or 2 projects running with an adjusted set of resources, deliverables and timelines...

Another option is to focus on automating standard changes in your data center which ultimately helps you to save personnel cost. This is done with small implementation projects focused on a particular data center resource to be automated (e.g. servers, storage, network, etc). The projects must have a short duration and provide a quick return on investement (let's say within a couple of months). Don't include complex integrations, worry about that later. If the budget is a problem, then finance it e.g. with a lease construction. Another advantage of this approach is that it not only solves a short term cost cutting need, but also provides a good set of ingredients for building an ITIL based service management system on the longer term.

Finally I also want to mention consolidation of resources and capabilities, such as e.g. organizational units, processes, applications and/or infrastructure as an option to reduce cost. Be aware that it also requires an investment (at least in effort and most likely in money as well) to make this happen.

Let me stop here as it is getting quite late in the evening and I want to see the latest TV news on the financial crisis....Any other suggestions?

Regards,
Jeroen Bronkhorst

Multisourcing Service Management

jbronkho — Sun, 28 Dec 2008 20:02:00 GMT

Under tough economic conditions many companies and organizations are (re-)evaluating their sourcing strategy in order to reduce cost and optimize overall business performance. Although outsourcing is considered to be an established business practice, more than 70 percent of the outsourcing deals fail to live up to their potential because of their ad hoc, compulsive way to solve current business problems. As a result IT organizations face issues in managing the increasing amount of external service providers and changing business needs which ultimately leads to suboptimized operations (read: redundancy, higher cost and service disruption).

Turning this around requires a more strategic, structured and disciplined approach called multisourcing. Let's first take a look at Gartner's definition of multisourcing: "the disciplined provisioning and blending of business and IT services from the optimal set of internal and external providers in the pursuit of business goals. Think of multisourcing as the overarching framework for optimizing sourcing strategies and actions".

The ITIL v3 glossary breaks down the term multivendor sourcing into three sourcing structures (as part of the Service Sourcing definition): "Multivendor Sourcing - Prime, Consortium or Selective Outsourcing using Type III Service Providers". These sourcing structures are further defined within Table 6.2 of the ITIL v3 Service Strategy book:

Prime - a single contract with a single service provider who manages service delivery but engages multiple providers to do so. The contract stipulates that the prime vendor will leverage the capabilities of other best-in-class service providers.
Consortium - a collection of service providers explicitely selected by the service recipient. All providers are required to come together and present a unified management interface.
Selective Outsourcing - a collection of service providers explicitely selected and managed by the service recipient. This is the most difficult structure to manage. The service recipient is the service integrator, responsible for gaps or cross provider disputes.

Although multisourcing is an emerging concept, industry analysts recommend it as the dominant model of the future. Compared with the ad-hoc tactical outsourcing indicated at the beginning of this post, multivendor sourcing provides significant benefits, such as best-in-class transaction costs, leveraging external expertise for continual service improvement, increased flexibility to adapt to customer demands, turnkey capability at reduced investment cost and ability to integrate M&A activity quickly.

The transformation however is not easy (to say the least) and organizations adopting a multisourcing strategy must be prepared to undergo a lot of change. There will be many challenges among the way such as technical complexity (e.g. level of customization / standardization, data and information flow, etc.), organizational interdependencies (e.g. aligned contracts, coordination across suppliers, etc.) and integration planning (e.g. end-to-end service reporting, Integrating processes and tools, etc.).

The ITILv3 service strategy book provides interesting generic guidance when it comes to topics to consider for a sourcing strategy. However when it comes to architecting and implementing, ITIL v3 only provides (descriptions of) ingredients that can be used for a multisourcing meal without the cookbook instructions for putting everything together. Do you know an approach that does?

Regards,
Jeroen Bronkhorst

How to implement ITILv3?

jbronkho — Sun, 30 Nov 2008 12:57:00 GMT

With which process do I start and what sequence should I follow? These are probably questions that are asked most often, especially in greenfield situations (mmm...does that still exist?) and by people that are relatively new to ITILv3. As a matter of fact I am regularly asked to provide input and feedback on project definitions and plans that are focused on "implementing ITILv3 processes".

Let me start by stating that implementing ITILv3 should never be the goal in and by itself, but is always a MEANS to control & manage the resources, capabilities and output (read: services) of an IT organization (read: service provider). In addition ITIL v3 is a best practice framework and not a cookbook. So it will tell you that you need an incident management process and describe some characteristics, however it will not provide you with all the details (such as e.g. training and tool settings) that are needed to have IT staff work with specific incident management applications (e.g. HP Service Manager) to resolve incidents on your specific IT services. In others words: ITILv3 is a piece of the puzzle for implementing a service management system and I have no clue how you can "implement ITILv3" without putting any details underneath (perhaps by putting the ITILv3 books on the shelf? ;-)).

Like with organizational design, the perfect sequence for implementing ITIL v3 processes and functions does not exist. Let me give you a sample: A couple of years ago I got involved in an ITIL based Service Management project with a relatively small IT organization of around 100 people all working in the same location. The IT organization had a very low attrition rate (people stayed until they retired and firing people was "not done") and their main issues were customer (dis-)satifaction and absolutely no control over their suppliers. When we wer discussing the order of processes, we basically concluded that there was no need to start with configuration management because each member of the IT staff was a walking CMDB. So we focused on incident- and problem management to begin with. So when planning the implementation of a service management system you need to take into account the problems that need to be resolved / goal that must be achieved as well as the resources and capabilities already in place.

In general I am seeing two strategies for implementing service management systems: 1) an inside-out approach (also referred to as bottom-up) and 2) an outside-in approach (let's call this top-down). The first approach is geared to first getting control over the individual resources through processes such as operations management, service asset and configuration management and change management. The service oriented processes follow later. The thinking behind this strategy is to make sure that any promises (read: agreed services) can actually be delivered. Downside here is that it might take a long time before the customers of the IT organization actually see any results / get any value from the internal restructuring.

In the second approach the focus is on first understanding the customer needs while definining the services that need to be provided and the value that they bring. Breaking down the services into resources and capabilities (read: service assets) follows later. This strategy is very customer-centric and helps to make sure that the value of IT is better visible. Downside here is that there is a significant risk that at will take a while before the results / value actually get delivered.

Which strategy do you use / prefer?

Regards,
Jeroen Bronkhorst

RACI matrices - how difficult can it be?

jbronkho — Mon, 27 Oct 2008 09:13:00 GMT

Well....very difficult! Several weeks ago I spent an entire afternoon in a meeting room with several colleagues discussing the ground rules for constructing RACI matrices and how to extrapolate them from workflow diagrams. The trigger for this discussion was the need for a coherent set of RACI matrices extracted from workflow diagrams in a consistent way and regardless of the person that does this. And although I found this a rather painful session, the outcome was very good and needs sharing (ITIL woud say: "as a good practice") with a larger audience.

Let's start - as usual - by defining what RACI is. The ITIL glossary says: "A model used to help define roles and responsibilities. RACI standards for Responsible, Accountable, Consulted and Informed" and also "Authority Matrix is synonym for RACI". In addition chapter 6 of the ITIL v3 Service Design book indicates:

Responsible – the person or people responsible for getting the job done

Accountable – only one person can be accountable for each task

Consulted – the people who are consulted and whose opinions are sought

Informed – the people who are kept up-to-date on progress.

The book also indicates a number of variations (read: expansions) of RACI, which we choose to ignore in order to keep things simple :-)

One of the first discussion points that we encountered is the difference bewteen R and A. As a conclusion we refined the definition by saying: Accountable is the role that is liable for the end-result of a task while Responsible is the role that contributes to the execution of a task.

So far, so good. Then we moved to a long discussion around the rules on how to construct a RACI. Combined with some rules from chapter 6 of the ITIL v3 Service Design book, here's what we came up with:

For each task only one role can be accountable (read: each row has one A)
For each task accountability is assigned/delegated to the lowest possible role in the hierarchy.
For each task at least one role must be responsible (read: each row has one or more Rs)
The role that is accountable can also be responsible (read: a cell can have both an A and an R)
For each task only the roles that always must be consulted and/or informed are indicated (read: a cell has a C and/or an I in case this is always applied). Be aware: this only shows the "must haves" and does not prevent additional (occasional) communication from happening

And finally some ground rules for extracting RACI matrices from Workflow diagrams:

Each swimming lane in a workflow diagram indicates the role that is accountable for each of the activities within that swimming lane
A hierarchy of workflow diagrams (also called "nested workflows") also implies a hierarchy in roles (read: delegated accountability). E.g. at a top level workflow model the accountability for an activity can be assigned to the incident manager, while for a sub-activity within a lower level workflow model accountability is assigned to the first level support role.
The swimming lanes at the lowest level workflow diagrams also indicate that the role is responsible for each of the activities within that swimming lane (read: for that role these activities show as A, R in the RACI). Please note that there might be more roles responsible for these activities, which is then only shown in the RACI and not in the workflow diagrams.

To close this off, I would like to invite you to add any other good practices you might have in constructing RACI matrices. Thanks in advance!

Regards,
Jeroen Bronkhorst

Is enforcing the right behaviour a pre-requisite for implementing Service Management?

jbronkho — Fri, 26 Sep 2008 08:22:00 GMT

Over the last couple of weeks I have been looking for samples that describe how to "behave" in a service management environment. The trigger for this was a request from my customer that wanted to define the 2 to 3 most important behavior guidelines to work successfully in the new situation where they are implementing several ITIL processes and supporting tooling (HP software of course ;-). In collecting information to address this request, I got some interesting discussions with several colleagues several of which I want to share with you through this post.

One of the discussions centered around the question whether steering the right behaviour should be a pre-requisite or an after-thought? In most of the service management projects that I have seen, the initial focus is on changing roles, metrics and activities. Of course the role descriptions include topics like skills, training and experience. However behaviour is typically "managed" later, based on actual execution of the service management system (incl. processes). BTW some organizations don't even manage behaviour at all....

So In my opinion behaviour should be addressed after implementation during execution and continual improvement. The main reason being that people are already being confronted with many changes when they are "forced" to become service- and process-oriented. This is typically pereceived as "limiting your freedom" and by including behaviour guidelines to the pile of changes the freedom becomes even more limited (read: the individual resistance get's higher).

Another point that came up is the statement that focusing on behaviour only is too narrow and should be looked at in the broader context of competency management. This includes topics like character, behavior, experience, training and knowledge. A strong point made here was that there is no way you can ensure behavior if a person doesn't' have the right character, talent, ability and motivation to do what you have asked him to do. So you really need to look at behavior from more angles.

So one of my ultimate conclusions was that focusing on behavior only is a too fragmented approach for ensuring an fully integrated service management system in the end. Would you (dis-)agree? Why?

Regards,
Jeroen Bronkhorst

ITIL is the only Service Management standard

jbronkho — Fri, 29 Aug 2008 12:03:00 GMT

Got ya...of course this statement is not true, but I thought to start with something controversial to get your attention on some other developments in the world of service management.

First there is of course the new guidance from the IT Governance Institute that has mapped COBIT 4.1 with ITILv3. And although this is a great document to help you link COBIT 4.1 with ITILv3, you should also be aware that mapping is created from a COBIT perspective. This means that the mapping shows where COBIT 4.1 and ITILv3 are related and which parts from COBIT 4.1 are complementary to ITILv3. In the last version of this mapping that I reviewed before publication, it didn't show however which parts from ITILv3 are complementary to COBIT4.1. The Mapping of ITIL v 3 With COBIT 4.1 is available as a PDF download at www.isaca.org/cobitmappings. The publication is free to ISACA members and is US $25 for nonmembers.

Another interesting development is the creation of CMMI for Services (CMMI-SVC) by Carnegie Mellon's Software Engeneering Institute (SEI). Where ITIL is mainly focused on services provided by IT organizations, CMMI-SVC is targeted at any type of service provider and covers practices to manage, establish and deliver services while re-using 77% of the process areas from CMMI for Development (CMMI-DEV). As CMMI-DEV can be downloaded free-of-charge, I expect this will be the case with CMMI-SVC as well. For more information see: https://bscw.sei.cmu.edu/pub/bscw.cgi/0/424939.

Please add your comments to this post around any other interesting developments in service management...thank you in advance!

Warm regards,
Jeroen Bronkhorst