Idwell on Service Management

Thoughts on how to design and implement IT Service Management

Author Archives: Paul Leenards

Principles of Service Management


by 1 Comment

Principles of Service Management

In the time of the ITIL update to version 3 I was involved with updating the ITIL training materials at Getronics PinkRoccade (former PinkElephant). One of the discussions we had was about the underlying principles of ITIL. These principles were not made very explicit in the books; their existence were mostly only mentioned in the introductions. I did a search through all the books and distilled some more implicit principles into a slide that we started using in the introduction in all the different ITIL courses at that time.

Recently, with all the discussions about the differences and similarities between ITIL, DevOps, SIAM, etc., I was wondering if these principles were still relevant. In his guest blog on the ITSM Review. ‘Why is this content at the end of the conference? This should be a Keynote topic!’ – CEO” Paul Wilkinson refers to his guiding principles on Service Management:

Guiding principles Service Management

These principles refer directly to Attitude and Behavior of the IT workers delivering services and value to the business. The principles we found so many years ago refer to the organization of IT delivering the services as well and I feel they complement Paul’s principles as well as adding another perspective.

  • Agency principle
    Service providers are made accountable to deliver services (value and business outcome) and are enabled to take responsibility for the costs and risks. A contract can be made to specify the value (price) against the costs and risks within the boundaries of laws and regulations.
    Often IT departments are not enabled to truly take the responsibility for the services they provide. They have no authority over their budget and their spending, they can not negotiate contracts with suppliers and they have no possibilities to hire the staff they need. The first step therefore to make IT departments (managers/directors) accountable is to enable them to take responsibility.
  • Balance Principle
    It is a common thread in IT service delivery that IT engineers tend to look at the product and the business look at its use. “How does it work?” against “What can you do with it?”. Sometimes the IT view tends to be too strong and the focus is on technology for technology’s sake. On other occasions the business view tend to ask for impossible and impractical technical solutions. In order to deliver the optimal services there should be a balance between the Internal IT view versus the external Business View
  • Service Measurement principle
    There is a strong emphasis on metrics and performance indicators in service management.  There is a need to show to the business that IT services deliver value as promised by the IT organization. This need leads to a continual monitoring and measuring of service delivery and the underlying processes. To make use of these data a service management system  should be in place.
  • System Principle
    There are many definitions for a system (unfortunately) and in this case a system is an holistic and integrated function to deliver services. A system contains people, processes (activities), tools and instruments, relations, contracts and other concepts (4P’s) to perform (5th P) and deliver value to the business.
  • IT Service Lifecycle Principle
    Service delivery is a continuous process of design, implement, operate and improve. Continual Service Improvement is not a separate process or activity but a core element of managing the service provider as a whole. This enables an iterative and incremental approach to service improvements in line with DevOps and Agile IT.
  • Knowledge Management Principle
    This is in practice on of the most fundamental and difficult principles of service management: to make sure that the right information and knowledge is provided to the right people on the right time. This asks for an organization that keeps on sharing and learning, It asks for feedback from the users and the business. For people that listen with empathy, reflection and patience. For systems that enable to share information as well as keep the amount of information manageable.

 

 

 

 

ITIL Graveyard


by 1 Comment

ITIL has been declared dead, again

Lately I have seen several blogs and articles declaring ITIL to be dead. ITIL is from different era and is deemed to be no longer relevant. Cloud services and more outsourcing are pushing the internal IT department out of the picture. And there are new frameworks ready to take over ITIL’s position. Have I not heard this before?

My first introduction to ITIL was the ITIL Essentials training I took in 1997. At that time it was ITIL v1, although that version number didn’t really matter until version 3 was introduced. In 2000 I joined PinkElephant in The Netherlands and took my ITIL service manager exam (ITIL v2). With my previous experience in several ITIL projects I was asked to join as a part-time trainer for the service manager course almost straight away. The economic crisis of 2001 meant that the board of PinkRoccade (as the next version of PinkElephant was then called) had to make some decisions on strategy and focus. ITIL was no longer a priority, considering the ITIL market in The Netherlands to be pretty much past its prime. ITIL was kind of declared dead.

Around that time I got involved with an implementation of the Microsoft Operations Framework at a financial services company in the Netherlands. When I had to explain MOF to the IT managers I told them it was based on ITIL. They then opened a cupboard with rows and rows of binders. Each row a different ITIL implementation by another ITIL consultancy group. It was pretty horrendous.

That is clear example of some of the problems that keeps showing up with ITIL. Often it is badly implemented by consultants that have little hands-on experience in managing and running an IT department. They take ITIL at face-value and cannot translate the underlying principles into realistic and practical advice. This has given ITIL a bad reputation. Add to this already dangerous situation tool providers who have created complex and ineffective systems to support ITIL. This has led to ITIL implementations effectively turning IT departments into bureaucratic and sluggish technocrats who say No. No wonder that business users turn to the cloud and bypass their internal IT department.

And no wonder that every couple of years a new method or framework shows up that might promise to undo what ITIL has created. Sometimes these frameworks are trying to distill the essence of ITIL into a new cocktail of processes and practices. Often this is done by providers to give ITIL their own unique touch. Sometimes these frameworks come from a slightly different angle and look at the IT organization from a different perspective. Like COBIT is the view from the auditor or the accountant. Sometimes it tries to solve a specific issue that has grown in IT departments over the years, like the great gap between IT development and IT operations. There is a real need to set themselves apart from ITIL and to declare ITIL to be history.

ITIL is a bit like Rasputin, you have to try real hard to kill it. Like Rasputin there is a ugly side and an attractive side to ITIL. At its core ITIL still has something to offer to IT organizations today. It is true that ITIL has its roots based in the Mainframe world and that the main perspective is that of an internal IT service provider. And it is true that books and frameworks written by committee often contain unsolved (often heated) discussions. Which means that ITIL is not useful as a manual that tells you step-by-step how to approach a problem in your IT department. The underlying principles still apply and it gives you still a basic understanding of what an IT service organization needs to do. And, the reason it so hard to kill, it has been used now by several generations of IT people as a common phrasebook of IT service management.

If you want to kill of a common practice because it is based on ideas from a different era, than you might want to start with killing of half the business school curriculum. We are still using ideas and principles from times long gone:  “the Art of War” or “The Prince” to name some examples. And, yes, the ITIL books are no highlight of literature. Maybe we could take ITIL for what it is to me in the first place: a selection of practices in managing IT services than can be useful as inspiration and guidance to any situation where IT services are to be delivered. That is how I approached ITIL back in 1997 and how I approach DevOps, SIAM, COBIT and many other frameworks now.

 
Paul Leenards


by Leave a comment

Continual Service Improvement is a management role

One of the core elements in ITIL is Continual Service Improvement. There is a whole book devoted to it. What I find interesting is that this core element is set apart, next to the other processes and functions of ITIL. When ITIL 2007 was introduced, then known as ITIL v3, I was portfoliomanager Service Management for Getronics PinkRoccade (formely Pink Elephant). To incoperate the ideas of the update into our own materials and concepts we studied ITIL v3 well. We wrote a summary and published this as ‘De Kleine ITIL v3’ (The little ITIL v3). And besides this publication we’ve created a poster showing the connection between version 3 and the past version 2. We struggled with Continual Service Improvement. In a way it was the most important addition to ITIL v2. Continual Service Improvement was kind of missing in the previous versions. It was not as explicit as it became in the current versions of ITIL. And at the same time it was kind of strange to see Continual Service Improvment so disconnected from the rest. In the presentations of ITIL v3 the order of the books was Strategy in the heart, surrounded by Design, Transition and Operations in order and with CSI at the outside. Almost as if CSI is an afterthought. In the poster we’ve changed this to make CSI more prominent as a management layer over the other processes.

Then and now it makes more sense to have CSI integrated as a management layer into the other processes and functions. Improving services and improving service design and delivery is a management task. That seems to me what managers ought to do. To me implementing a service management framework as ITIL or when you start using ideas from the DevOps approach should start with the introduction of some kind of management system. And this management system should be based on the ideas of continual improvement or CSI. When the management system is in place, you can start improving the way the processes are working and how services are delivered. When improving processes and services, using best practices from ITIL, DevOps, IAM or ISAM or even COBIT will make more sense.
Paul Leenards


by Leave a comment

When As-a-Service doesn’t makes sense

Following a link on LinkedIn I’ve come across this challenge: to explain Software-as-a-Service to a five year old. It is an interesting and an uncomfortable  read. You can wonder about the challenge itself: why do you want to explain SAAS to a five-year old? And at the same time it shows insiders explaining a radical change in thinking to an outsider that doesn’t know what the fuss is all about. From an outsider (non-IT) perspective and specific for somebody growing up in this current era not having IT-services, pay-per-use, doesn’t make sense at all. Of course you pay per use and of course you expect the supplier of the service to keep the service maintained and up-to-date. Why wouldn’t you?

The age of PC and distributed-computing is coming to an end. In that age owning a computer or data center, building and maintaining your own applications and spending a lot of money on migrating to a new platform or connecting up different applications made sense. There was no alternative really, even though there were so-called Application Service Providers since the end of the ’90s. In this time of connected systems, mobile solutions and cheap devices ownership of the underlying systems is not sensible. Unless you are a service provider of some sort and these systems contain your livelihood. As-a-Service therefor does make sense from the perspective of the buyer of these services. You do not want to deal with the ownership and the maintenance hassle it involves.

Explaining As-a-Service  to the owners  as if it is a better alternative to ownership might be a sensible idea. But if you are not owning only using the services than you will take As-A-Service for granted. It is the norm. Of course you want As-a-Service, so why convince the user? In the examples of the 5 years old it is the parent that will benefit from a shop that has toys for rent, since they have to invest in toys that kids play with for only a few times. So, you can give these arguments to the kid, but why would he care? The toys are provided for anyway and the financing is not a 5 years old concern. If the toy is damaged it will be repaired by the parents, it will be cleaned by the parents (as if a 5 years old kid will care anyway) and after a while the grandparents will provide new toys. So, he already has Toys-as-a-Service (TAAS) and there is no need to convince him otherwise.

Anyway, in my opinion the explaining of As-a-Service is something that is needed mostly within the IT community itself. Why would an IT department give up ownership and direct control over their own IT systems to a service provider? When is a generic and standardized service where you pay-per-use to be preferred over your own specific and propriety application set that you have to invest in every year? There is a business case for As-a-Service that in most cases is better that ownership. Every 5 year old would understand that access to unlimited amount of toys is to be preferred over having a limited set of your own. Even though owning your own teddy bear is still the best.

 

Paul Leenards


by Leave a comment

Is managing IT so much different from managing anything else?

The last couple of days I am pondering on this thought. What is the difference between managing a department and managing an IT department? And I do think than on most accounts there is not much difference at all. Managing IT is not that different from managing anything else. So, as far as laws of management do exist, they apply to IT as well. The added advantage of IT in general is that the main working is dominated by machines. And managing those are pretty straight forward. That is, if you can keep the IT engineers away from them.

So, why bother with ITIL, COBIT or any other propriety IT management framework? Good old Drucker should be sufficient enough. Unfortunate that is not really the case. Because first of all running IT has more to do with managing expectations than actually running systems itself, it is not that straightforward. And second of all the people responsible for the systems keep on confusing the technical specifications for the the actual business value of ICT. It is not in the technology itself but in its application. So, there are multiple levels of depth to managing ICT services and people.

Many consultants trained in business management seem to be lost when talking to the IT staff, they do not compute the local lingo of the engineers. And many engineers are lost in the mist when trying to explain what they do to business management. Managing IT has thus elements of management theories in general, but with a unique local flavor. That is something worth investigating and expanding upon. And that is what I am planning to do in the coming period.

Paul Leenards


by Leave a comment

The 5 P’s

In the ITIL book Service Design there is a model called the 4 P’s: People, Process, Product and Partner. Product is also known as Technology, but that doesn’t sound as good. I personally like to talk about the 5 P’s and add Performance to the model. Actually, for me performance is the pivoting point or central axis of the model. It all revolves around the Performance the IT organization has to deliver to add value to their customer. In order to improve the performance their are 4 main domains or areas you can intervene in: People, Process, Product/Technology and Partner. Of course there are people who say that there are more domains you can intervene with like organization, culture, politics, knowledge, etc. For me, organization is a combination of people and process and culture is a people aspect. Culture is defined by the behavior of people and by changing the behavior of people the culture will change as well. And knowledge is part of people which can made available first through processes and supported through technology.

The most effective way to improve performance is to address the people aspect first. When staff adopts the performance goals they will start improving the process or renegotiate the contracts with partners. And this will probably lead to the deployment of new technology. Of course, that is all in theory. But in practice it turned out that people are the true engine of change. It is people who want to get the results and people who will make change to the processes. It is a pity that most implementations of IT Service Management of ITIL do not sufficiently address the people domain and concentrate too much on technology or process handbooks. Unfortunate, this is also in the ITIL books itself. They talk a lot about people being important but do not address HR or any other best practice concerning people.

Paul Leenards


by Leave a comment

The Starbucks View on the Service Catalog

I recently read an interesting book on economics (that is possible) called The Undercover Economist by Tim Harford. In this book he describes how Starbucks manipulates (by lack of a better word) their customers. They offer regular coffee for a nearly justifiable price and a whole range of products for a premium price. These whole range of products are mostly regular coffee with a little add-on, like cream, chocolate-powder or vanilla-syrup. Sometimes they are also treated in a slightly different matter, like blending regular coffee with ice-cubes. Of course, these premium products are marketed in such a way that it justifies the much higher prices. A strategy that is called price-targeting. It only works when there are people willing to pay the price: the followers of fashion and the people who do not care about their money.

In a way this principle can work in IT as well. As long as the IT department is willing to take a risk. A regular standard desktop will costs a reasonable price covering the costs of maintaining the desktop by the IT department. And there is also so much more choice. For instance, the IT department can market the IPhone for double the cost as a device only for marketing executives. Or the Extra Wide double LCD Monitors for the controllers, for which they have to pay three times as much. It is all about marketing. How the IT deparment sells the specials the Starbucks way.

The great thing is, that the IT department doesn’t have to do a lot extra in work, it is all about the feel of the product. Supporting an Iphone or extra wide LCD Monitors are not more difficult and do not take more time than supporting the standard desktop. But the customer will gladly pay more, financing product and service innovation. No doubt.

Paul Leenards


by Leave a comment

Sustainability Management

While working on our Green IT Maturity Scan I was considering how to integrate Green IT into something like ITIL. I don’t think that will be very difficult. In a way sustainability is similar to availability or security. So, besides availability and capacity management, you can have the process (or function) sustainability management. You can have a sustainability manager responsible for making the IT infrastructure more sustainable and thus more green. He can report on a regular basis on the level of sustainability (we have a Green IT Maturity Scan that can help) and come up with a plan to improve energy efficiency and to save on paper. From an architecture perspective it will not be very difficult to come up with acceptance criteria for new releases or services based on sustainability.

There is good business sense in creating a sustainability process within the ITIL framework: it will save on cost. Choosing wisely on which hardware to use for instance will save on electricity bills. Applying Green IT principles will also mean that the overall costs of IT will go down. And IT is not only a polluting factor, it can also bring solutions to the business to improve the overall level of sustainability. This enabling role ois in a way the promise IT made years ago when it turned from Automation into Information Management. Unfortunate, most IT organizations are no yet mature enough to be taken serious as a partner for the business. Therefore, sustainability management should first focus on IT itself, keeping the business in mind of course, before it will be allowed to address sustainability issues within the business.

Interesting enough, we’ve been transforming IT organizations using frameworks like ITIL over the past 15 years and we’ve learned that mature IT organizations will be more in control and therefore will become more sustainable. By being more aware of waste in infrastructure and processes, and being in control of addressing these issues, IT organizations have become more sustainable.

Conclusion:

a. Make someone responsible for the process/function Sustainability Management in the sam way as Capacity Management

b. Transforming IT organizations using ITIL will make the infrastructure more Green

Paul Leenards


by 1 Comment

At least 5 reasons why ITIL implementations fail

There are many reasons why ITIL implementations fail and I want to mention some here:

1. Trying to IMPLEMENT ITIL. ITIL is not an Implementation Framework, it is a reference framework for IT Service Organizations. It is a bit silly to try to implement a reference framework. You do not implement the encyclopedia or the phone book either. You can use ITIL as a reference framework when you transform your IT department to a mature IT service organization. Leaving you to choose which of the best practices to use and how to use it. If you want to use ITIL as a standard for implementation, please don’t. Use something like ISO20000 instead. Because everyone is talking about Implementing ITIL, I’ve grown used to the concept of ITIL implementations. It should be ITIL Transformations.

2. Starting with the CMDB: It has been argued before by several Service Management Guru’s that trying to set up a CMDB is very difficult. To do it well is almost impossible. It is a daunting task to start with and it will not bring any additional benefits to an ITIL transformation. When you’ll try to set up a CMDB together with some of the staff involved, you’ll end up with more specifications than was needed to design the Apollo program (allright, that is a but too much, but it will be very close). CMDB’s are useful when applied lightly. Otherwise it will mainly distract from reaching the desired results.

3. Designing the processes with the staff involved: I’ve used to think that it is wise to have the people responsible for doing the processes help to design the processes. Now I know I’m wrong. I’m not against involvement of the ITIL Transformation victims at all. But, at the right time and with the correct starting point. Now I’m a firm believer of Design Top-Down and transform Bottom-Up. Involving staff in process design has several negative aspects: 1. it demonstrates that process design is not difficult at all and anyone can do it, certainly the system operator with limited education. 2. It is an easy way to obstruct any possible improvement of IT by taking forever to come to an fully agreed design. 3. When there are no guidelines on the results the processes are suppose to deliver than all this design work is futile to begin with. In the end you’ll have wasted time of the IT staff and in the meantime the number of incidents have gone up since the incident solvers were in a workshop. Well done!

4. ITIL (or ISO20000 for that matter) are a goal in itself. And when that is the case you’ll have a couple of meters of paperwork to show for a successful project (specific when it was run in a Prince2 way) and the RFI for the next ITIL project on your desk. I’ve been in organizations where they had evidence (ic. handbooks) of 6 ITIL implementations. And still they were no where near to delivering services to the business satisfaction and against reasonable costs. If there is no clear goal, in terms of business value and strategy, then almost all ITIL transformations will certainly fail.

5. Thinking that ITIL is only for the operational IT management part of IT. In Holland they call IT management ‘Beheer’ and this is the least sexy part of any IT organizations. If ITIL is for ‘Beheer’ then anyone else do not want to be involved. It makes for very interesting situations where the developers, project managers, architects and others are doing their upmost best to stay out of Incident- or Change management. Which means that only a small part of the IT Service Organization is trying to transform to become more service- and process-oriented. Which is not found to be a successful solution.

What to do when you want to Implement ITIL, sorry – transform your IT department according to the guidance offered by ITIL?

1. Create a Change Program for your IT Department using ITIL and other frameworks for guidance

2. Define clear results in term of Busines Value that the IT department has to achieve

3. Based on these results design the processes on reaching these

4. Train, develop, coach, train your IT staff in all aspects to be able to execute these processes and to achieve the desired results.

5. Start using the processes as soon as you can, and discover in using them how to improve these processes and what tools you need. And get these tools.

I wonder what more reasons we can find for all the failing ITIL implementations and what would we advise to prevent more failures from happening?

Paul Leenards


by Leave a comment

MOF 4.0 Pocket Guide Available

Since this week the MOF 4.0 Pocket Guide is available to purchase. I’ve had a small part in writing this guide, mainly in writing the chapter on the Team SMF (Team Model). It is still an achievement and has put my name on the cover. The main body of work has been done by Dave Pultorak and his team and Clare Henry (Microsoft) and her team. It is a readable book with give a good insight in the main features of the framework. I’ve could written much more on the Team SMF, but a pocket guide has restrictions. Maybe in the next book can I spend more words on the main USP of MOF (in my vision).

You can order the book at the publisher: Van Haren
or throught the IT Governance site