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.

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.

On  twitter I’ve started a discussion on the MOF Team Model.  One of the responses came from Steve Chambers, he questions my article in the Global Best Practices book and specific  he dislikes  the Team Model.

In the discussion Steve askes three questions I will try to answer here:

“Question: who, in the “Problem Management” team, finds a work-around for #vSphere problem?”

The Team Model supposes that the Support team is accountable for solving incidents and preventing them from happening again. This team will be responsible for finding a work-around for any problem defined. If the team needs additional expertise to do so, it will hire an expert. This expert can be internal or external. The decision to hire will have to be taken by the manager of the Support Team. The manager is accountable for finding solutions and to do this within reasonable costs and time. If an vSphere expert is member of another department than he will be assigned to the Support Team for the time needed. He can not do other work in the time he is assigned to the problem. That will require good planning skills by management.

The advantage of the Team Model is that responsibilities are assigned based on the results the IT department needs to deliver instead of the disciplines within the IT department. It doesn’t matter what you know, but what is accomplished.

Question 2: can you show me an organization that is following the #TeamModel today? I’d like to talk to them about #ucs

Yes, if you want to come to Holland. The cases in the article are all based in the Netherlands. Not all of them are still following the Team Model. Due to mergers and reorganizations IT organizations have faced outsourcing or other changes. Elements of the Team Model can be found in several companies in the Netherlands, including our own (Getronics) Operations Management services.

Since the Team Model is created by Microsoft, they might be of some help as well to find you organizations that have implemented the Team Model.

the thing I dislike about your article is all the copyright, licensing etc – I don’t think it’s a good business model for you

The copyright and licensing referred to in the article is because the article is a chapter in the Global Best Practices book published by Jan van Bon. He wants you to buy the book of course. Using the information in the book is free of copyright or licensing. As a consultant I would like to help and be paid for it. It is up to you to use the information and to assess if you need additional consulting.
I’m open for more questions on the MOF Team Model. I like the model since it helps IT organizations to look at the way they are organized from a more business perspective.  There are flaws in any model. When applying models to real life blindly you will run into trouble for sure.

The MOF team model is based on the basic idea that the responsibility for the results of a process should not be divided over multiple departments or teams. For instance Incident Management is spread out in a lot of organizations over several disciplines and this results in a lot of meetings and discussions between the disciplines to solve incidents. If the end-to-end responsiblity of Incident Management is brought into one team under one manager, than there is no need for all the meetings and discussions. The manager of the team will be accountable for solving incidents quickly and to prevent incidents from happening again. When looking to the IT organization in this light 7 accountabilities can be defined: Support, Operations, Solutions, Services, Architecture, Compliance and Management.
IT staff can be assigned to these accountabilities when their expertise is needed for the specific activities and results. When assigned to one team the expert can not be assigned to another team at the same time. This will prevent that certain activities will not be performed since they do not draw much attention, think maintenance activities for instance.
Most important draw back of the team model is that incompetent managers will be shown that they are incompetent. Managers need to make decisions and take responsibility.




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

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?

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

Based on the core books I’ve tried to distill some basic principles for ITIL3. Principles that you can apply to your IT service Organization and that will help you to make this organization more in line with ITIL3 (and therefor hopefully more useful to the business). These are the principles:

  • Agency principle: service providers work for the business on a contract and provide services that are useful (utility) and usable (warranty) to the business within the boundaries of laws and regulations
  • Balance Principle: there should be a balance between the Internal IT view versus the external Business View
  • Service Measurement principle: all aspects of service delivery should be continual measured and reported
  • System Principle: all aspects of service delivery should be encapsulated in the design of service provision (holistic Design).
  • IT Service Lifecycle Principle: service delivery is a continuous process of design, implement, operate and improve.
  • Knowledge Management Principle: ensure that the right information and knowledge is provided to the right people on the right time
  • I’m pretty sure this is not a complete list. I’ve tried to keep it short and to the point. Any suggestion for improvement is welcome. As long as it is a principle that will help an IT organization improve it services and is in line with the ITIL3 Framework.

    Business IT Maturity Model (Paul Leenards, 2008)

    Business IT Maturity Model (Paul Leenards, 2008)

    The Business IT Integration Maturity Model is first introduced in the summer of 2006. It was created to use in a discussion with an IT department to define the level of organizational maturity needed (based on Nolan’s Maturity Model). The BITI Maturity Model defines the needed organizational maturity of the IT department in relation to the view of the Business on the strategic importance of IT. The view of the Business can be seen as a level of maturity for the business itself.
    The basic assumption is that the maturity of the IT department should not be greater than the view of the Business on the need for IT. If the Business is looking towards IT as a commodity, then the IT department should have a customer focus (maturity level).
    More explanation later.

    I like analogies. They are useful to explain a complex thought in a different way and help to gain understanding. This morning I’ve started to write the text for a factsheet we want to publish on ITIL3 in relation to ITIL2. And I was considering an analogy. Since maturity is a concept we like to work with (hence www.itmaturity.com) I toyed with that idea. I realized that ITIL3 is like a teenager. It has grown up since the previous versions (1, the baby, and 2, the child), but it isn’t mature yet. Although it likes to think otherwise. It has found it can now use new possibilities and functions that were already there in potential. And it hasn’t yet used the full potential.

    As a teenager ITIL3 has pimpels and is a little too corpulent. That might have been caused by the hamburgers it is eating lately. It is very concerned with pocket money to buy the latest gadgets and fashionable loud music. ITIL3 is both attractive and repelling. Pretty to look at, but the nonsense it is uttering…. oh, please! The rebellious side is well developed and irritating. Its enthusiastic approach to life(cycles) is contagious. It lacks social skills and experience. It thinks that structures are the way forward.

    You can tell that I both have a like and a dislike of ITIL3. Looking at the framework from one perspective, it offers a lot for the IT organization. From the other perspective there is still a lot to improve. I’m curious if there are other analogies to be made. Or this analogy to be improved.

    Last week I had an interesting discussion during the ITSMF e-Symposium on Service Automation. In the America Session the question was asked if the IT industry is not too young to have a best practice framework like ITIL. You could argue that there hasn’t been enough experience within the IT community to have best (or good) practices defined as such. Although I can understand the perspective, in comparison to for instance Finance the IT industry is quite young, I do not agree with the conclusion: As long as there is a constant study on the best practices in IT there is a place for IT Industry Standards. After a while these Standards will stabilize and become more common knowledge. The recent addition to the ITIL set of Continual Service Improvement is exactly what you need to establish these Industry Standards.

    What is needed is an Academic forum for the studies of IT Service Management where the IT Industry Standards can be further developed. At the moment there is this ongoing discussion on all kind of platforms between Vendors and Users on what is the best standard. And with this discussion acquisitions of bias are always close: vendors want to sell their products and services and users want simple and cheap solutions in a box. A more independent platform is needed and Universities can play an important role here. There are already some Universities that are getting involved, hopefully the number will increase.

    Next Page »

    Follow

    Get every new post delivered to your Inbox.