onsdag 30 december 2015

I don’t like IT "movements" or frameworks, but why I still use them all.

Sounds contradicting? It sure does but that’s actually true. There is a lot of information available about these IT frameworks and movements. There are ITIL, DevOps, Agile, Lean, Cobit, ISO2000, SIAM, IT4IT and so on. And trust me, there will be more, plenty more. It will never end. But there will never be the day where you have one to rule them all. People are sharing tons of material and their own experiences etc. about these movements and frameworks. There are plenty of books to read too. The good thing is that it is really easy to access this huge amount of information. The down side is that a lot of the practice out there is subject of interpretation and might even in some cases be applied and described in a wrong way.

 

Its not deliberate, no. The use of selections of a particular framework applied for a specific situation/challenge at a company is a common approach. It might even succeed and increase or decrease whatever the target was. Is this wrong? Of course not. Could you brag about it? Of course. Could you even say that framework used works? Yes you can.

 

So how come everybody that have a success story claim that the particular framework or movement they used works, when there is example of every framework succeeding in some specific case? There are horror stories as well of course but let’s focus on the ones that actually claim that their specific religion, ops sorry for that, I mean framework or movement works.

 

First of all, and here is my theory, all of the frameworks and movements address  IT service management (ITSM) in some way. More or less but they all do in some way. That means that there are fundamental parts of ITSM found in each and every one of these frameworks and movements. They might have different focus, but parts of the fundamentals are there in each and every one. In practice this would mean that if a framework or movement is used in a way that actually enables a company to reach their target or goals, you have a success story. BUT. That does not mean you would have failed if your reference had been another framework or movement. In practice again, the same approach applied and use in another situation and another company might not give the same results.

 

2 + 2 is not 4 every time in ITSM! Situations are not the same, targets are different, conditions and resources are different. There is not one single framework or movement that only has success stories. All the failures are blamed on wrong application or wrong use of the framework, if you are a believer. If you are not a believer the blame is that the wrong framework was used. 

 

So here we are. We are all looking at the same thing but from different views, with different knowledge, experiences and condition etc. There are no right or wrong as long as you apply parts from whatever framework or movement and succeed to deliver value. 

 

That was a short term perspective. So what happens when the years go by and this way of using and applying bits and pieces, simplified way of working, cutting corners etc. are continued? Hey come on, it has been working so no hard feelings here. 

 

In the long time perspective a new challenge emerge. Specific applications or situations with a specific focus with engaged people always seem to do well and deliver great results. But slowly things start breaking apart. Changes made to way of working do not seem to give any obvious positive affect. We run out of quick fixes and things start to get complicated. More and more seems nestled and optimization of a single process or procedure does not work anymore. Now it seems like there is a need for orchestration of multiple procedures or processes. The introduction of a new process or adaptions of and existing might give increased value in a completely different part of the process landscape. It all seems to be interlinked. The way we used to adapt with bits and pieces, simplified way of working, cutting corners etc. no longer works.

 

I guess you already know where this is heading. ITSM is not about one process, one procedure, one function, one role etc. ITSM is about the whole picture. There is not one thing that makes it all work. In the beginning one can get a lot of value by introducing small isolated parts which seem to have an immediate and positive effect. But along the road the effort and complexity increases while the benefits are decreasing, or in some cases, are absent. 

 

It’s now where the going gets tough. The sherry picking times are over. It’s not sufficient to address isolated parts any more. We need to look at the whole picture and understand how it all comes together and works as a system. Every adaption we intend to make must be design from a holistic perspective. It’s a complete machinery that needs to work where every single adaption is analyzed, design and changed based on improving the system as whole.

 

So where is that framework or movement that can accomplish this complete system? I'm sorry to say, but there is none that covers the width and depth of everything. This is why every framework and movement comes in to play. Every company has their challenges and obstacles, and depending on them, different strategies are relevant based on what they want to accomplish. It cannot be read in a book. It cannot be thought in a class. What you need are experienced professionals that are capable of doing the analysis required to understand how these frameworks can be used in a combined and valuable way to achieve the goals ahead. 

 

It is hard work and demands a lot of effort. The only way to achieve this kind of change is to treat it as a business change and admit the fact that it is people you deal with, not technology. Treat your change as a people change initiative with enabling business goals as your target. 

 

Start designing your ITSM puzzle and try not to be religious about a specific framework. See all the frameworks as collections of knowledge and try to see how they can benefit you in your specific needs to achieve your goals and targets. Don't try to do it all at once. Introduce small changes but never forget that "every small change you do, is designed to improve the system as whole". Small changes are good. They are not perceived as a threat. But be clear about the benefits, even if it is not visible where the change is made. Always explain why!

 

This is why I don't like frameworks and movements. They are too often described as a prescription or solution for everything but they are not. So I use them all. And I think you should too.

 

Happy New Year to everyone and I hope your 2016 will prosper.

tisdag 17 november 2015

Add value, stop protecting people from the truth

Today there is set of ITIL processes that are almost treated as commodity.  I’m talking about the Operation lifecycle processes. How they are used varies but they are often there one way or the other. Pretty much every service management tool vendor covers them and has been for years. Still the outcome of these processes in reality does not cut it in many situations and there is a struggle to keep up.

 

I’m going to go out on a limb here and say: I bet you it’s not due to people and it’s not due to tools. 

 

So what’s left? What to blame? Considering my bet, our last options are to blame processes or information. I blame both. The good thing here is that they are pretty easy to fix. So let’s fix them, or? What should we fix? What is it that is broken or lacking?

 

Let’s look at an example. When an incident occurs, the nature of incident management is to minimize the adverse impact on business and fix the incident as soon as possible. To accomplish this, there are more processes within operations than just incident management that interact to accomplish this. "Shift left" is a term and one way to illustrate this interaction between these processes. Event management, problem management and knowledge management (knowledge not part of operation lifecycle but still) are all processes that contribute to "shift left". “Shift left” is basically to shorten the incident timespan by applying an incident resolution or workaround as early on as possible. This is done by structuring knowledge in a way so it is available and applicable in the incident process. The information that is needed to accomplish this is usually stored and structured with the help of event-, problem- and knowledge- management but is created from knowledge throughout an organization.

 

This is healthy, effective and efficient. There is still nothing to fix! We have good people involved, a good tool to support our way of working, the "shift left" information is flowing and we have processes that describes each individual process and their interactions. 

 

With this in place, operations reporting consist of decreasing average resolution times, increasing first line fix rates, high utilization of workarounds, etc. Development reporting consists of shorter time to market, decreased average release cycles, decreased backlog etc. This reporting is usually done in silos due to lack of collaboration and information transparency. 

 

Each area is focusing on issues and performance that are close to their respective daily work, the things they see and do. So still, what is there to fix? Both operations and development are reporting positive progress, increasing productivity and decreasing lead times. The nature of this setup is that both departments will, over time, change the content of their reporting to address more and more specific subjects within their own area of expertise. This is of course to further improve but it is important to remember that operations reporting is not only for operations.

 

This is where the processes and information availability might start to wear down. There is a risk in "shift left" that can be very hard to detect when all things seem to improve. In this vast flow of information (shift left) and the very effective use of it (early resolutions) we become heroes. We tend to forget that there was still an unwanted interruption at the end of the day. It’s unwanted by all parties but we start treating it as a fact instead of a fault. 

 

If we treat an incident as a fact we tend to focus on damage control and we might even be very good at it for a very long time. Everyone becomes heroes. Heroes of Operations apply quick solutions and workarounds to incident. Heroes of Development provide knowledge to do so. 

 

If we instead treat an incident as a fault we have the possibility to focus on prevention, but only if we stop hiding the truth from whom it might concern. If an incident is the result of a fault, and the incident can be mitigated by a solution early on, there is still the question of why the incident happened in the first place. 

 

That incidents will occur is a fact. But why an incident occurred is still a subject that needs attention. Handling incidents effectively is not enough. The risk of "shift left", if not managed wisely, is that we build information walls between the truth (actual business impact) and the root cause of the fault (usually human error). These information walls are unintentionally born when support focus only on the closest thing at hand "minimize the adverse impact on business and fix the incident as soon as possible" when the guiding star should be that an incident never should happen at all, or at least not repeatedly. 

 

A common support setup is 1:st, 2:nd and 3:d level support within incident management. Each level of support is eager to use available knowledge to minimize incident impact, and as soon as that is achieved, the incident is closed and statistics are reported. If not achieved, the incident will be escalated to the next level of support where the procedure is repeated. If we are good at "Shift left", the incidents will be solved early on and the truth might not be visible at the source of the fault. The weakness here is that if the "why" is not addressed, the source will be blind of the truth. If the source is crappy developer code or bad infrastructure design, this will continue to generate faults. 

 

The effective handling of incidents is an operation concern. Why an incident occurred is a design concern and should be address as such. This painful truth must be available at the source of the fault in a valuable and actionable way. This does not mean that all incidents should be subject for problem management, oh no. But the incident reporting and statistics are equally important for both operations and development. How the incident statistics should be used differ though. Operations use it to improve handling; Development should use it to improve quality and prevention of incidents. A working feedback loop is the key to enable people to be aware of this truth.

 

Done right, there is nothing wrong with 1:st, 2:nd and 3:d level support within incident management. There is nothing wrong with "shift left" either. The missing piece here is to assure that we accomplish information transparency of the truth all the way to the source. And of course, at the source it needs to be treated as valuable knowledge to improve.

 

We need processes that are designed to provide this valuable feedback and we need the information (truth) made available in a transparent way all the way at the source. Basically, stop protecting people from the truth, or you could say stop hiding it.

tisdag 15 september 2015

How come ITSM seems so hard?

The general perception of the IT industry and ITSM community seem to be that it is very hard to succeed with good ITSM. Nevertheless what framework is used as reference, it still seem to be an overwhelming opinion of unproved value. For every success case there is a dozen questionable.

 

If you do a quick and un-scientific research reading polls, votes from seminars, following discussions online etc. you quickly come to the conclusion that many are struggling. I do not mean struggling in a way that e.g. incident management is failing, but more in the sense that we are good at incident management but the customer is still unhappy. When I'm referring to Incident Management and, therefore pointing towards ITIL as framework it is due to that it is widely used and mentioned a lot. So is ITIL to blame? Well I do not think so!

 

Another finding, considering ITIL here,  is that of the five life cycles in ITIL, Service Operations is dominating in presence and maturity with a decreasing order of Service transition, Service Design, Service Strategy and finally Continual Service improvement (CSI). This strikes me as a very logical also taking into account that there is still an overwhelming opinion of unproved value.

 

Coming back to the "we are good at incident management but the customer is still unhappy". How can it be this way? If we perceive our self as succeeding, how come our business or customers experience us as failing?

 

I do not have the "silver bullet", that is for sure, but I have a gut feeling we had something to do with it :) Looking back on more than a decade trying to find different type of approaches it does not take long to see that again there are scopes and approaches that address Service operations processes e.g. Incident, problem, request but also knowledge, config and change (even if those are Service Transition processes).

 

No wonder we think we are good at it. We have been doing it for ages. If our business and customers where as interested in technology as us we would score jackpot in customer experience ratings. But they are not! They don’t give a crap. They don’t do IT. We do IT and that is the problem. We shouldn’t do IT. We should do business, with the help of, and use of, IT.

 

So the logic here is "to do business", with the help of IT. We need to understand what to facilitate. What is the use of IT meant for? Have we been doing it wrong? Probably if we consider the "we are good at incident management but the customer is still unhappy". Do we need to redo it all over again? I do not think so. What we need to do is to shift our focus and change our scope.

 

Instead of scoping processes solely  from Operations and maybe Transition, reconsider scoping processes to facilitate the complete IT commitment. How a scope could look like is:

 

Strategy and Portfolio Management

Catalog and Service Level Management

Change and Release & deployment Management

Event and Incident Management

 

Now this looks like a scope that would scare any practitioner in both complexity and magnitude. But here comes the strategy. Don't initiate a massive design phase to define all these processes. On the contrary. Skip the design phase and start collaborating with your business to establish a "as is" status description. Define how it is done today, all the way from business idea to run and correct in operation. These processes exist today, I promise you, they exist. Maybe not in writing, maybe not in a complete manner etc. It does not matter. What matters is that you get a description of the actual situation and that it is agreed upon. Skip the ITIL books and start talking to people.

 

Now you know where you are. Its time to use the fifth and most unused lifecycle from ITIL, CSI. If you can agree on a model for HOW business improvement should be identified, decided and prioritized, then you have a tool that will identify the most valuable changes that IT could do to facilitate these plans and ability to follow it up. Now ITIL works as a very good reference for how all processes interact with each other but you will still not find your answer in the books. Use the books as reference in your analysis but never use them as recipe book.

 

With this shift in focus and change of scope your stance is quite different. Your ability to identify and apply improvements that is perceived as valuable by the business should be considerably increased. Now you can, based on business priorities, include additional processes if needed, or increase content of existing processes if needed. Key here is that the expected outcome has to be identified and valuable for the business.

 

Another dimension in this is who does what? I strongly believe that when it comes to "Strategy and Portfolio Management" it should NOT be done by IT. Strategy and portfolio should be done by business. Should IT be involved? Of course! Should IT be participating? Of course! Nevertheless, the ownership should be business. All this is of course supported, interpret and analyzed by IT.

 

Well there you have it. My conclusion that approaches that has a operation and transition focus will end up detached from business comes from the fact that business priorities and value is identified earlier in the complete IT commitment and is a fundamental part of good ITSM.

fredag 7 augusti 2015

People, Process and Technology, what does that mean?

When talking to people who have been involved in a larger process design or establishment projects, there seem to be a widely spread understanding about the term people, process and technology. Nevertheless, when asking the question

 

"what was the projects top priority the last 4 to 8 weeks of the project?" 

 

the answer tends to be very technology related. Acceptance tests, transitions from dev and test environments to production. IT activities for handover to operations etc. etc. 

 

Another question I usually ask is 

 

"If you would use people, process and technology as different focus areas for the project, where were the focus highest during the project?" 

 

The answer tends to be process in the beginning, people in the middle and technology at the end. As if these disciplines were stackable on top of each other or three different areas that did not bring any synergies. Yet, everybody knows about people, process and technology. 

 

If you want a solid foundation you need concrete. Think of people, process and technology as water, sand and cement. If you want to mix concrete to build a foundation you can not use more sand in the beginning, water in the middle and cement in the end. You need to mix them with the same proportions in the beginning, middle as in the end. This applies to processes as well. 

 

A process describes a series of events in a particular order which are considered critical, or highly contribute, to an expected result or output. Technology can facilitate a user interface (or automate) for an specific event in the process and show any necessary information required to accomplish the task. People are the ones that know how things should be done, what order, what information that is required, what information is generated, how to perform the work, any applicable logic etc.

 

A balanced mix of them all throughout any project, establishment, continual improvement etc. scenario is important. They are not three dials where you can increase and decrease them as you see fit. If one of them are delayed for any reason, it affects all three in the same way. 

 

It is not like the classical quality, speed, cost. You can pick only two! They are all equally important just as in concrete. This is not only true during a project. This is just as applicable after any project for process maintenance as well. 

 

People, process and technology might be three different terms but combined the right way and you might be on you way to greatness. 

torsdag 23 april 2015

Should i go for services or processes?

What are service orientation and process orientation? Is it s choice between the two, or should they coexist? I get the sense that all "ITIL implementation" projects out there have a tendency to be tool and process oriented and even worse. The "Lets take one process at a time" approach is a long and hard way to learn how to do it right, if that ever happens. If that sounds appealing and firefighting mode is what you came for? Please google for "how to implement ITIL".

 

Process Orientation:

When everyone at IT works there are different workflows that come into play depending on what IT is trying to accomplish. Each workflow has a set of objectives and the combination of workflows is common to enable IT to accomplish certain tasks or results in an effective way. Any new or changed demand from the business IT serves, triggers these workflows to facilitate the new or changed demand. 

 

Process orientation means that these workflows within IT are defined as processes where each process has an expected output and results. Many of the processes are interacting and dependent on each other where results from one process is used and further enhanced in another process to finally deliver what is expected. 

 

Each process is describe by identifying necessary activities, the order of them and the work that should be done. The results from each process are evaluated to assure the right level of quality. The combination of processes and evaluation of the expected end-result is assessed to assure the delivery of what is expected. Any deviations, unwanted characteristics and anomalies are analyzed from a process perspective to identify and improve the process flow, activities, result and output. This does not constitute that work is defined in every detail in every process, far from. 

  

Service Orientation:

Service orientation implies that there is a defined service that is agreed upon between two parties. The service is used by a customer and delivered by a supplier. The secret ingredient of a service is to understand the value it contributes to. The service does not deliver the value. The value is created by the customer when using the service. Without going into any collaboration models for making this partnership work optimally, lets just for the point sake say that there is a service and the service is delivered (by IT) and used (by the business).

 

Service orientation means that from that point on, the service is considered in everything IT does. When the business wants to change way of working (change their business process), any new business demands need to reflect how the service needs to change to support new business objectives and way of work. This is a constant dialog and evaluation that needs to be done together by both parties for the services.

 

This also means that IT needs to understand how the service is used by the business to create value. Again: The value is not delivered by the service, it is created when the business uses the service to achieve its objectives. It is key for IT to understand and learn this.

 

Any new business demand that affects the service will be managed by IT and realized as a new release at some point for the business to use and enjoy. At this point we can use the service for a lot of useful things within IT. We can use the service to allocate costs to show Total Cost of Ownership, measure time to market, evaluate the actual value it contributes to etc. This can be the focus for IT and everything that IT does. Everybody, both business and IT, knows what the service is used for, why the service is delivered and the importance of it at any time. 

 

Process orientation analogy - The business is a group of carpenters that build custom houses, IT is the supplier of tools and the infrastructure to run the tools e.g. electricity, heat, water and fences and gates etc.

 

For IT to support the business, it organizes in different departments. For simplicity lets say there are two departments, one focusing on the availability of electricity on the worksite during the full construction of a house. The other department is focusing on availability of machines and carpenter tools on the worksite during the same full period. Each carpenter (business area) at the business has its own requirement for tools depending on what they work with and when the tool is needed during the construction period. 

 

IT defines the processes required to accommodate the business from these two perspectives and the results from each process are evaluated to assure the right delivery and level of quality, but still as two departments in two different perspectives, tools and electricity. Most of the defined IT processes are shared between to two departments but the work that is performed within an department  is mainly to facilitate their own perspective. Both departments claim to deliver what is expected with high availability but there still seems to be a constant argument between the business and IT of shortcomings and delays.  

 

When talking to the tool supplying IT department they can show that all new and changed requirements from each carpenter has been fulfilled and when talking to the electricity supplying IT department they claim the same. When closely examining tools they seem to live up all requirement and when doing the same with electricity it is available and on time. IT has still no insight nor knowledge in how the business actually builds a house and what constraints the carpenters needs to manage when doing that.

 

The argument of shortcomings and delays continues with a firefighting mentality from IT emerges to try to serve the business better.


Service orientation analogy - The business is a group of carpenters that build custom houses, IT is the supplier of tools and the infrastructure to run the tools e.g. electricity, heat, water and fences and gates etc.

 

For IT to support the business, it needs to understand how the business builds a house. Each carpenter specializes in a separate part of the build and the tools and infrastructure required differs over time and between the carpenters. There are also variations in number of tools needed at a particular time and based on the build phase.

 

For each carpenter (business area), a selection of services are defined. When defining these services there is a focus of explaining and understanding of how the value is created. How should the tools and infrastructure be used by the carpenter in the most effective way to achieve the best value? The service definition emerges. Now IT understands how the packaging and combination of tools and electricity (and anything else included) should be delivered and used in an optimal way by the carpenters.

 

A new way of structuring IT is developed. IT is still organized in two departments based on tools and electricity. The difference is that with a clear understanding of business needs the deliveries from IT is combined  and packaged based on optimizing the carpenters ability to work effectively. This is now the primary focus and collaboration between the departments is managed accordingly.

  

Analogies combined:

With both service and process orientation in place it was obvious that there where a lot of requirements and workflows that never was managed properly.


- A new bigger machine occasionally blew the fuses causing everything to stop.

- At specific times the number of machines used simultaneously caused fuses to blow causing everything to stop.

- It is far more efficient to install electricity in multiple locations throughout the construction site and inside the house so that the carpenters could use the tools where the material was located or being used, eliminating the need of unnecessary carrying of materials around the site and inside the house. 

- Some of the tools used by the carpenters could be shared due to that they where used during different periods instead of suppling a complete set of tools individually.

- New specialized tools and equipment where developed to further facilitate the carpenter needs

- Workflows where improved with services in i focus

- collaboration and dialog where improved considerably when the service and value was common ground for both parties.

 

Processes orientation and services orientation combined:

Service orientation does not in any way replace the need of process orientation. Even when IT is service oriented, process orientation is still necessary and relevant. The addition of service orientation gives IT a better ability to understand business needs and what combinations of IT and improvements that constitutes. Service orientation is all about delivering a service that effectively can be used by the business to create value for the business. Process orientation is how we optimize our work when identifying and managing and deliver those improvements. 


Summary:

You can focus on process orientation which have a high probability to lead to a IT orientation with low business context. Processes orientation is a good way of optimizing how something should be done whilst service orientation is why, what it is and how it is used to create value. This might be the difference of IT being perceived as cost effective technology broker vs. high valued business driver.  

 

Neither of the two orientations needs to be rigorously documented with all details and definitions. The contrary. Make the simplest design and focus on validation, evaluation and collaboration when improving your design.   


tisdag 31 mars 2015

The secret with exceptional process design

  1. When is a process perceived as good?
  2. When is a process perceived as bad?
  3. What is process design?

 

These are questions that everybody that works with process should ask oneself. I use these questions frequently just to remind myself of the secret with exceptional process design. So what do I mean with process design? I guess you could include quite a lot in the term "process design". I have heard people say its about drawing activities and their relations and I have heard people say it is about a customer - supplier relationship and I have heard that it is anything in between. I will come back to what I think process design is but lets start with the questions in the right order.

 

  1. When is a process perceived as good?

Can you recall any occasion when a process has been the subject for praises? No? Well any occasion when a process has been the subject for positive attention? No? A big thank you? A tap on the shoulder? A friendly word? A look? Any thing?

 

That something work fine is usually not expressed in gratitude of a process. Gratification is not that uncommon but it seldom correlates to a particular process. Customer experience can be good and when it is, thing just work. Why is that? How come things just work? Is it because they have the sharpest minds? Is it because they have the best process design? Is it because they have the best tools?

 

  1. When is a process perceived as bad?

I guess that you can recall a few occasions where a process has been the subject for blame. I know I can. Why is that? Is it due to a bad process design? Bad tools? Lack of best people?

 

Whenever expectations are not met there will be a sense of dissatisfaction. Whenever expectations are met there will be a sense of satisfaction. Both of these cases will affect the trust and this trust is the basis for the overall experience and satisfaction. How do we create trust? How do we increase trust? How do we even influence trust?

 

  1. What is process design?

There is a fundamental element with any process and that is the expected process output. But it does not stop there. There has to be a profound understanding of what that output is to be used for and what the expected result of that should be. This is commonly referred to as the value. The process has an output and that output is used to create value. This is the guiding star in all process design.

 

So lets go back to trust and experience. How do we influence trust and experience? What are the basics in trust? Trust is earned. It can not be demanded, asked for, taken for granted etc. It is earned. Earned by constantly proving commitment of a common goal over time. What are the basics for experience? Experience has a more short term relevance. We could have a bad experience and still have a solid trust. But over time if the bad experiences are frequent our trust will gradually decrease. The opposite also apply, if good experiences are frequent over time out trust will increase. 

 

The secret with exceptional process design!

It does not require the sharpest minds. It does not require the best tools. It does not require the best of anything. It does however require two things.

  1. The fundamental element of process design.
  2. Relentless effort to improve.

 

The fundamental element of process design.

Remember the guiding star? The expected process output and the understanding of what that output is to be used for to create value. This has to be the primary objective in all process related work.

 

Relentless effort to improve.

Any effort to improve process output and value could be a process related issue. It might not. It could be anything. Nevertheless, our ability to improve is dictated by our ability to identify and apply improvements. It does not matter how we identify the improvements as long as we do. Use anything at hand. Process -measurements, -operators, -stakeholders, -feedback etc. and never forget the primary objective, output to create value.

 

Summary

My conclusion is that nevertheless if there is trust or not. If there is inexhaustible effort to identify and apply value oriented improvements there will be an increase of trust over time and things will just work eventually. And what did we say about things that just work? That it is a sign of good processes. The key to exceptional process design is to never loose sight of you guiding star, value. And never get tired of digging down in the dirt to find gold nuggets in the shape of improvements. The improvements can be related to education, available information, routines and procedures, tools etc. It does not matter. If it increases value, put it on the list. That is the secret of exceptional process design!