Peter's Power Play

Artistic or scientific processes?

plijnse — Thu, 19 Mar 2009 07:05:48 +0000

Every time I look at a process and how it is executed in an organization, I ask myself: Why is this process successful? What is the value of this process for the customers? Of course the people that execute the process are the main reason for the process to be successful and provide value to the customers. But there is more to it than that.

I have always believed that process development for IT organizations is more of an art than a science. That is one of the reasons I called my company Service Management Art. I have seen many different discussions around processes – Lean IT Service Management, Guerrilla Service Management Process as a language and all different other ideas.

The interesting thing is: They all come back to the same thing: Process development and management seems to have the need to be more fluid and influenced by creativity than actually being able to define it as a scientific and strict process.

I read the Harvard Business Review on a regular basis, and often read articles in HBR that are directly applicable to IT Service Management. In the HBR March 2009 there is a good article that supports my position that process management should be more artistic.

When Should a Process Be Art, Not Science?
by Joseph M. Hall and M. Eric Johnson

Some of the key messages in this article are:

Process standardization can undermine the very performance it’s meant to optimize. Many processes work best when they are treated like artistic work rather than rigidly controlled.
To decide if a process should be more artistic than scientific look for these conditions: inputs to the process are variable and customers value variations in the process output.
If a process is artistic, invest in giving employees the skills, judgment, and cultural appreciation to excel in variable conditions.

I think this is a great way of looking at processes in IT as well. Make sure the process is customer-focused and that the staff that executes the process, have the correct behavior. An artistic process has to rely on external measures of success, like customer feedback.

So how would that work in IT Service Management? We can define some scientific processes in ITIL, but if you really look at it most of the processes are artistic.

For instance a “standard change” procedure (process) can be seen as a scientific process. Often, there is limited variability and rigid control. Another example would be a password procedure. I see the scientific side of the processes more in specific procedures.

An Incident Management or Change Management process would be in general more an artistic process.

A bit of warning though: If the customer values standardization, i.e. clear and defined changes to the infrastructure, you have to make your process more standard (and you can use scientific methods).It is all about what the customer wants and ensuring that staff has the correct behavior.

Change is an art! (and most IT processes are as well)

Demand and Supply in Real Life…

plijnse — Mon, 16 Mar 2009 18:11:36 +0000

Recently one of my sons was diagnosed with Diabetes. This is a life changing event for him and the rest of the family. It all boils down to aligning food intake (mainly carbohydrates) with insulin. But of course there are other influences like stress, exercise, illness, etc. Getting the blood sugar in a safe range is the key objective.

So how does that work? It is a process. Recording what you eat and how much insulin you take. Planning for what you are going to eat, how much exercise you are going to do, and other potential influences. If you do not stay within the predefined ranges of blood sugar levels there might be potential dangerous situations. So the blood sugar can be too low (Hypoglycemia), or too high (Hyperglycemia). Action will need to be taken. Some of the symptoms for these highs or lows are anxiety, confusion, blurred vision, increased appetite (or the reverse), etc.

You might wonder where this all going and what this has to do with IT Service Management. Well, when we started I found the similarities between Diabetes Management and the ITIL v3 process Demand Management very interesting. In Demand Management we look at the patterns of business activities. This means that we look at when the customer is using the services, how much they are using the services and what they expect from the service provisioning. So if we see the customer as our diabetes patient we see the same thing: when are they eating, how much are they eating, and what additional exercise are they planning. It becomes the same thing.

Now the role of the insulin is to provide the “customer” with sufficient capability (insulin) to process carbohydrates (food) in such a way that we neither get a low blood sugar or a high blood sugar.

We should do this with our IT customers as well. Depending on their requirements and their activities we need to align the demand to the supply. So the right amount of capacity at the right time. So let’s see the capacity as our blood sugar. If the capacity gets low we will see anxiety and confusion with our customers: we are getting in a state of HypoCapacity. Systems will stop working; the chance of a customer in coma is very real.

If the capacity gets high, we will see a state of HyperCapacity. This means we will have a blurred vision and the customers will keep asking for more. The customers will fill the available capacity, but it will have to end soon. This state is often not recognized by customer and supplier until it’s too late. In IT this can mean costs too high, too much data etc.

Like with Diabetes Management it is important in Demand Management to see the big picture. You will need to manage the capacity over a longer period of time. Reacting to sudden peaks or valleys is not going to help the management. They will happen, being prepared for them is the key. You will need to look over a longer period and see if you have good management of the demand. Sometimes you will have to influence the customer (different way of using the systems). Aligning the demand from the customer to the supply of the IT Service Provider is an art.

Change is an art!

Top reasons why IT Service Management projects fail.

plijnse — Thu, 12 Mar 2009 18:32:10 +0000

Everyone has a horror story about a project that failed. (to be honest… I love those stories!) In my work as a consultant I often encounter the question: What do we need to do to make our IT Service Management improvement program successful?

Here is my top 3:

3. Too much focused on the tool.
We adore our tools and we all think that the tool will be the solution. It is not! It is actually a major reason why projects tend to fail. We put too much faith in our tools. Every time someone says: – Let’s scan the infrastructure with a discovery tool, we can then put this info in a CMDB and we are done – I cringe. Have you ever thought about what to do with exception reports (and don’t tell me you just accept them), what data is necessary and what not? Will it provide value to the service provisioning? So despite what your vendor says: ‘The Tool’ is not a perfect solution, but a path to disaster if not managed well.

2. An IT Service Management improvement program should be managed as a continual improvement program.
Comments we hear in the market: – we stopped our ITIL program, or we did ITIL last year – do not make sense at all. First of all: you do not implement ITIL, you use the best practice of ITIL to improve your organization. The activities as described in ITIL are executed right now in your organization, not at the most efficient and effective state they could be in, but you are doing it. So see the program as an way to improve. How does that become successful? By handing it over as soon as possible to the organization. The organization needs to learn how to do this themselves. So after two years of running this ITSM improvement program, the IT organization knows what to do themselves. They can walk the path of continual improvement. The program is there to make the organization successful.

1. ITSM improvement programs are 80% management of change.
If you do not understand that, please stop now. You are doomed to fail. It is not difficult to design a process, or implement a tool (just a lot of work). It is difficult to get people to change their behavior. Communication, Training, Awareness, Management Commitment, Involvement. Some simple words, but they pack a punch. Not enough focus on those items and the program will fail. You are transforming the organization to a service oriented organization (including culture).

If you are serious with your improvements: Hire a consultant with management of change experience. And listen to their advice.
If you just want to implement a tool and hope that things will change, good luck you will need it.

Change is an art!

Go Hybrid!

plijnse — Wed, 11 Mar 2009 18:01:44 +0000

(this article was originally published in our SMArtITSM magazine)

Four years ago we moved from Toronto to Calgary. Of course I wanted to fit in and decided to buy a big SUV with a V8 engine. The mileage was not bad: around 14 liters per 100 km. For all those people that did not grow up with the metric system, unfortunately I cannot find a definitive answer on how many miles per gallon that is (it is dependent on if you use US or UK gallons). From a marketing perspective: approximately 25 mpg. The car would provide me with this simple measure of fuel consumption. To be honest, I did not really look at it. I did of course look at the cost of gas. (Don’t we all?).

We have always been looking at the environment: recycling as much as possible, taking care not to disturb nature too much and ensuring that we did not let the car idle unnecessarily. Of course the rise in gas prices started to influence us as well. So after some careful consideration we decided to look at a hybrid car. Because I have been driving Toyota cars for years, we decided to buy the Camry hybrid. A full size sedan that would meet our needs for now. The marketing brochure explained that the average fuel consumption would be 5.7L/100km (=50mpg). No difference between highway or city driving means that we would be able to cut our fuel consumption in half. A promising future.

So, the concept of the Toyota Hybrid engines is simple:

The electric engine and gas engine are in parallel. Both can work at the same time (or independent of each other). Unfortunately there is always a catch with something new. You have to change your behavior, because it is not possible to achieve these fuel savings if you do not make optimum use of the electric and gas engine. This is where the car provides a great option: It has different reporting capabilities that can really help you as a driver, to ensure your driving is focused on optimizing the amount of fuel you use.

It has a dial that provides you a direct insight in how the fuel consumption is in liters per 100 km. You also know continuously which engine you are utilizing (gas, electric or both) and it has a history report on your fuel consumption in 5 min intervals. These three reports provide you with the possibility to change your behavior, because now you can drive in the most fuel efficient way. On a road trip of around 600 km through the mountains we managed to get to 6.1 L per 100 km, not bad for a first try. Other interesting revelations were a cold engine really gives you bad fuel consumption, so bad weather also means more gas.

Warning: when driving on the electric engine in the parking lot, there is no sound, so most pedestrians do not hear you coming! After you shut off the engine the car will give you an ‘EXCELLENT!’ if you did some efficient driving: Like the gold star from the teacher. You want to see that every single time!

Of course this relates to IT: If IT would get the right reports for efficiency (or effectiveness), they would be able to see where they needs to change their behavior. We could give gold stars to our IT department as well. But of course if you don’t read the reports, you will not change your behavior.

Change is an art!

Change a Routine Task?!

plijnse — Tue, 10 Mar 2009 16:56:09 +0000

Recently we started doing all the ITIL v3 Intermediate exam. As trainers we have to do all the exams to enable ourselves to teach the courses. Not a bad idea, but after doing 10 exams you start to have enough of it. This of course forced me to revisit the ITIL v3 books. During that preparation I found some interesting statements that I would like to share: (Service Transition book – section of Service Transition common operation activities)

‘The Service Transition team will soon become familiar with the need to change attitudes and the operation of converting culture. For them it is a routine task, holding no threat. OGC, Service Transition, page 157.’

I had to read this multiple times to see if I read this correctly. Lets analyze this:
Service Transition staff is normally very technical focused and more concerned about how to transition the new technology into the production environment than about understanding what customers and users want. If you ever find a technology focused person that has an affinity with management of change, please make sure you keep them! Those people are worth every single penny. I am not convinced that we will see these type of Service Transition staff often in organizations.
But if we can get over the fact that we have IT techies, we now can look at the next sentence: “for them it is a routine task, holding no threat”. Yeah right – that is the whole problem! Anytime someone says: “I thrive on change”, they are lying. Why? Because they do not have to change themselves! Service Transition staff of course does not see any threat. They are not the ones that have to change. It is the customer or even operations staff that will have to change. Any consultant that ever tried to implement change management and release management knows, service transition staff does not like to change themselves… New policies and procedures are often not really accepted.
So although there is a lot of good stuff in the ITIL books, please do not believe everything in there. (It might get you into trouble.)

Change is an art! (not a routine task!)

More external or internal staff on your improvement program?

plijnse — Mon, 09 Mar 2009 18:32:10 +0000

IT Improvement programs often suffer from unclear (human) resourcing strategy. This is often an underestimated activity that is based on availability of internal and external resources, NOT on the strategy to build a high performing team. As an example: we had projects where external consultants were hired to staff the project. Although the external consultants delivered the promised results, due to lack of internal input the project did not deliver according to requirements for the organization. On the other hand we also have seen several examples where the whole project was executed by internal staff that did not have the right skills to develop new processes that would add value to the organization. The result? High costs and no real results.

So what do you need to do?
Start defining what kind of activities you are going to execute, for instance:
·         Process design
·         Template development
·         Technology selection and implementation
·         Communication planning
·         Etc.

The internal project staff (resources) you have currently assigned to the project – what capabilities do they have?

Do they have the skills and experience to fulfill any of the activities in the project?
Do they need training or education?
Is it part of their career path?
How much time can they spend on this project?(Remember: 9 women pregnant for 1 month will not get you a baby, you will need continuity and the right amount of effort.)

After you have established the internal capabilities and competencies it is time to see how external consultants can enhance the capabilities to meet the strategy of the project. You could hire a coach for your staff that keeps them focused and makes them successful in the delivery of deliverables. Or you could hire a consultant that is focused on providing your staff with the knowledge they need to be successful. External consultants are not there to stay. You need to get the most benefit out of them in a short term and provide your staff with the knowledge they need. If they do not transfer their knowledge your project is doomed after they leave.

It is not easy, but creating a resource and capability strategy for your ITSM program is going to help you in creating value to your customers.

Remember: less involvement from external experienced staff can slow down your project. The acceptance by staff, benefits and value creation to your customers might be better, but it might take more time. Can you afford that? Or do you need results now? What is your strategy going to be: More internal staff or more external staff?

Change is an art!