fredag 7 november 2014

If you work with processes, here is an advice for you! Stop it!

Well i don't really mean stop it literally. I mean that it is not the best way to communicate what we do. I work with processes. My work is largely based on processes and process steps, process models and flow diagrams etc. I think and i breath processes and i really like it. One thing i do try to do though is to mention the word process, as little as I possible can, when i work, why? Because it is perceived as very boring, sometimes even not relevant and have in general an undeserved bad reputation. How many times haven't you heard someone mentioning a "process project" in a negative way? well i have heard that a lot. Just listen to the community. There are 9 to 1 negative references of processes compared to positive (not a scientific measurement). The interesting thing here is that once in a while you actually meet that 1 reference and here is the fascinating part. When asking about the project the word process rarely appears. 

The process itself is very important in the right context. Consider it as a tool. If you would hire a carpenter to build a porch for you, you would explain what you want to do on the porch. How many people you would like to fit when dining on the porch. If you want shade on a specific part of it etc. You might even have a sketch drawn of how you picture it. The carpenter would ask things like if you want parts of it painted, if you want a fence, stairs and handrails, overall size etc. 

What he would not do is to talk about what dimension of wood he is planning to use or name all the different tools he needs to build the porch. He would definitely not take them out of his car and start showing them to you. 

That is sadly the case to often when it comes to process work. When we try to show the beauty of a process. How we can establish measurability. how it enables us to assure that significant events occur in a planed and predicted way. how we can learn from the outcome and make sure we accomplish the expected benefits. What do we do? we show all the carpenters tools and the timber. 

The largest part of process work is people and culture. Never underestimate this. How to be relevant to people is key to create engagement and participation. How relevant are we when we start showing all the carpeting tools? we are not! 

If you are about to embark on a journey with a new or existing process, do not say process implementation. Don't even mention process and please not in the same sentence as implementation. What you are actually doing is:

- Establish a "current baseline". Yes you will have to do a process but please don't show it to anybody. The point here is to understand how things are run now.
- Define the expected outcome/value that is not to satisfaction. This means that you actually have to understand the expected outcome so please talk to a person who experience it first hand.
- Design a target state. Yes you will have to do another process but do not show it to anyone. This should accomplish the goals.
- Do a GAP analysis that clearly identifies the weaknesses in the baseline and the countermeasure for it, based on target state. 

And now to the single most important success criteria working with processes.

- Describe how these improvements can be achieved by involving the right people, stakeholders etc. and how to get their buy-in. If you don't manage and succeed with this there is no point. Use the ejector seat and get out of there. 

If people and culture is 80% of process work you end up with the following:

You succeed 100% with 80% of the work and only 50% of the last 20% of the work you still have a success rate of 90%. If people buy-in they tent to do an amazing job. 

If you focus on the wrong parts and succeed 100% with the 20% of work and then 50% of the last 80% of the work you have a success rate of 60%. Engaging the wrong people about the wrong stuff might seem as progress at the moment but you ability to succeed dramatically decreases. 

So please :) if you work with processes. Please stop!

onsdag 6 augusti 2014

Do we trust our processes so much that we miss the obvious?

Do we have an overconfidence in processes that prevent us from seeing the obvious? Could it be that our processes and routines hide the fact that there is a customer that needs help and attention.

Why do i ask this question? Well, during my vacation this year i had the unfortunate experience of loosing my credit card. How this happened is not relevant to this story but my experience with trying to get a replacement card delivered to me in another country while still on vacation made me think about how we sometimes have overconfidence in our processes and routines. 

The story:
I'm in another country than my home country. I have lost my credit card. I have no phone. I use an nearby Internet cafe to make phone calls over the internet and read e-mails. After a number of calls to block the lost card, finding contact information to the bank support i finally got through, remember, I'm doing this from an Internet cafe with borrowed equipment. While talking to the service desk at the bank that issued the credit card I was told that to get a replacement card would not be a problem. When i informed the support agent that i was in another country the reply was that i had to send them a written letter where the loss of the card was explained and a written request for the card to be delivered to an abroad address where i would be staying during delivery to personally sign of the delivery. It was very important that it was written in a letter due to that my signature was required! Come on, I'm in pain and i need help. Written letter?

After some more discussions i asked if it was possible to write a letter on a piece of paper and then take a photo of it and e-mail the photo where all the information and my signature was present. After verifying this with a number of different managers we agreed on that this was indeed possible if the email was sent to a specific e-mail address that was connected to their support tool. I did what i was told and felt really good that this was solvable even though it took me a while to take a photo, get it stored online so that i could include it in an e-mail.

two days later i had not received any confirmation of my issue or any indication that everything was going according the plan so i called them again to get a status update. The support agent informed med that yes, the e-mail was received two days ago but apparently attachments in this way was not supported (a long technical explanation was accounted for and i didn't understand half of it anyway) so the card had not been sent. I did not get any explanation for why an attempt to contact me had not been done. 

I asked if i could sent the e-mail again to a personal bank e-mail address instead to se if the attached photo would come through and was told that their policy did not allow them to handout personal e-mail addresses. Now what? After continuing this discussion with various managers and constantly being denied my request i was finally connected to a new support agent (the one i had talked to earlier had left for lunch). At this point i was tired, upset and sad. After briefly explained the situation for her, she (even though not allowed) gave me her personal e-mail address, requested me to sent the e-mail again, confirmed to me that it was received including the photo. She also made personally sure the support case was updated with all necessary information and e-mailed me a verification that DHL was on the task to deliver the card to me. What happened? Someone stepped outside the box and suddenly everything worked like it should have done in the first place!

This started me to think about processes, policies and routines. It took me several days, several phone calls, several support agents and managers to finally get to talk to someone who actually put me in focus. who listened to my needs, my situation and used all resources available to help me. Hey I'm a customer.

I finally received the replacement card as promised and everything continued as normal. My reflections though are that there is a BIG difference between following a process compared to making sure the correct outcome is achieved. 

I think it is common that overconfidence in tools, processes, policies and routines hide the fact that there is a human on the other end that is desperate for help. Do we need to start acting as if there is an abandoned baby in front of us? We sure would not leave it before we made sure it got proper care. 

Just saying!

tisdag 13 maj 2014

ITIL explained with coffee #ITILcoffee

After a short moment of inspiration i came up with the idea of creating a simple descriptions of ITIL processes based on a coffee scenario. After posting a few at Twitter (@howtoitil with hashtag #ITILcoffee) i got a number of requests asking if they are free to use. My reply, of course they are! So here they are, all of them.

måndag 7 april 2014

How to scope your IT service initiative. Do you need a Portfolio,catalog or requests?

To be able to discuss IT service and potential scope, ambition and effect of IT services we need to establish a few terms. I will use three different terms that is very related to each other.

Service Portfolio: The content of a Service Portfolio describes what capabilities and business processes that a customer have, value and prioritize as of today and the future. This is the basis (customer requirements) that IT need to support and develop with matching IT services. The IT services is completely driven by customer needs. The Service Portfolio can be documented in any already existing or arbitrary format.

Service Catalog: The content of a Service Catalog describes all the IT services that is available for the customer at the moment. Any IT service description clearly states the service content, commitment, limitations etc. The content must reflect the available IT services for a customer and is favorable described as a sales brochure in either electronic- or paper- form.

Request Catalog: The content of a Request Catalog describes all the ways a user can interact with available IT services. It is how a user requests ability to consume an IT service. To add, change, move or delete ability to consume it. The content is completely an effect of IT's ability to bundle requests. The Request Catalog is usually available for users as a web based request portal.  

Now when we have three terms defined on a basic level we can continue with a few examples that is categorized on focus, based on these terms. A desirable effect is related to what part is in focus and the basic conditions to achieve them. This is just a few examples to show how one can categorize desirable effects to enable a strategy and plan that is not to fragmented.

Depending on ambition, and effects you pursue, you can use this way of sorting to scope and focus your initiative to increase probability of a good outcome. Do not try to do more than you can handle. There is a very important relation between the three different terms. A Request Catalog get higher quality if the content is a result of a working Service Catalog where the requests are defined based on how a user is supposed to interact with the available IT services. A Service Catalog in its turn get higher quality if the content is a result of a working Service Portfolio where the Service Catalog content is based on business outcomes prioritized by the customer as important and the IT services necessary to manage the business. The Service Portfolio verifies that the development of the IT services is based completely by the customers needs and future challenges. 

tisdag 25 mars 2014

How categorization can help you decipher your IT services

The term IT service is commonly used in different IT contexts. It is frequently associated with IT delivery in an attempt to illustrate some form of packaging of benefit and value to the customer. What I often miss is the breakdown and categorization of the term IT service. To be able to apply it one need to be very clear with what it means due to the broad application of it. I simply call it navigation. The reason I think one needs to break it down is that the surrounding of an IT service is affected by what we mean when using term. Surrounding in this case is how we realize it, deliver it, measure it, describe it, what content to put in an SLA etc. All these things is affected by what we actually mean when using the term IT service. 

Category Transaction vs Subscription.
Lets start with the first categorization. Is the IT service used to illustrate something I actually use as part of my work or is it describing something I might need to order or request due to that I need it. Lets make an example. I need a printer available from my work computer due to high demand of printouts in my line of work. Lets assume that at the company I work, there is a request portal to place this kind of requests. I complete a request of a printer from the list of available printers I see fit for me and I receive a e-mail confirmation of what printer I have ordered. A few days later it gets delivered and installed, ready for my use. The IT departments commitment this far has a focus on delivering a working printer to me according to circumstances and prerequisites that the IT department have defined. Costs associated with this request is probably the purchase price of printer, paper and consumables like ink etc. for the printer.  

If we stop here I would categorize the above example as a Transaction IT service. The commitment from the IT department would basically be over and done. The request is measured in various ways, used in follow-up, is described, managed etc. as a IT service to achieve what described in the example above. From this point onward I have the possibility to make printouts from my work computer. If for some reason I need, I can call the IT department Helpdesk to get assistance if any problems might occur while using the printer. 

Now we get to the counterpart to transaction service. It is the Subscription service. If the IT service would have been described as a subscription IT service it would have to be structured differently. In a subscription I would probably not choose a printer from a list of available printers. I would probably choose what capacity of printout I need and how critical the printouts are at the time I print them (availability). We are potentially still talking about the same actual printer but there is a significant difference in the commitment from the IT department associated with the subscription IT service. Now the commitment is not only to deliver a printer, but the ability to print which includes the monitoring and planning of activities like change of ink cartridges, paper, plan service intervals, cleaning etc. The more printouts I do, the more the IT department need to act. Of course I still have the possibility to call helpdesk whenever I am in trouble with my printouts. Costs associated with this request should based on my printouts. e.g. I pay for each printout and this way I can change my behavior and that way influence my costs associated with my printouts.  

In the subscription example there is still a initial part that is corresponding to the transaction IT service. It is the actual delivery and installation of the printer. This needs to be measured and be managed as a transaction IT service but the significant part here is that the IT service is described as the ongoing commitment of printout ability from the IT department that is based on my printout needs. 

Category Generic vs. Specific
The reason to categorize if a IT service is generic or specific is due to that it often affects how the IT service is described and offered. Generic in this case is to offer the IT service to a broad base of customers with high level of flexibility. Preferably every available customer. If this is the case the IT service usually needs to be offered with different levels and scope. It can be levels based on volume, availability, response time, scalability etc. 

A specific IT service usually address a specific customers needs. The levels (options) that was characteristic for a generic IT service tends to define the actual service in much higher grade in a specific IT service. The specific service should cover a specific customer need and hence, there is less need of options and configurability. A specific service tend to need a high frequency of review and follow-up much closer to the customers goals and the value of the IT service. 

Category Process Oriented vs. Bundled
The third categorization is whether the IT service is process oriented or bundled. A process oriented IT service has a very strong connection to the customers business goals and output the customer is striving for. There is also a different foundation to show the IT service contribution to those business goals and outputs. The IT service content (service functions) is very closely related to the customers actual business flow and any activities and sequences that the business flow might consists of. The success of a process oriented IT service is completely dependent of the IT department ability to understand how the customers business process works, looks like and purpose. Any change in the customer business process might get a consequence in how the IT service is described or delivered and must be managed thereafter. 

A bundled IT service is more based on commonly occurring request behaviors, patterns or other practical reasons. An example could be a packaging of a mobile phone. If a user should have the possibility to request a mobile phone in the company request portal it would be rather inconvenient if the requestor received just a phone. It would probably lead to that every requestor would be forced to enter the portal again to request a working SIM card, and a phone cover, and cables, the changer and finally the correct rights for content synchronization. This would not be very efficient nor very practical for anybody. probably very frustrating. Here a bundled IT service would be very suitable. Put all parts in a bundle to be carried out in one request and let the requestor decide what is relevant in that particular case so that no further requests are necessary at a later stage. 

Category Customer Facing vs. Supporting
The last categorization is whether the IT service is used directly by a customer or is a supporting service to enable the former. Examples of customer facing IT services is all occasions when a user does not only order or change the delivery of a IT service but actually uses functionality provided by the IT service. It could be a "order management" IT service. The customer actually uses the functionality delivered by the IT service to perform the work concerning order management. 

A supporting IT service could be the operations of a database that the order management IT service is dependent on. It would be a hosting service that the IT department can purchase of a external hosting supplier or perform themselves internally. In the case of external hosting company there is parallel customer and supplier relationship. The hosting service have a supplier, a customer, is measured, managed etc. but the hosting service is still used as a supporting service to the order management IT service. 

Focus of transaction category
If your services are transaction services, focus on simplifying the request interface (portal) and standardize the fulfillment flow so it has high repeatability. Measure it to understand lead-times etc. and if you have a portal, be very clear with what the commitment covers e.g. the fulfillment of the request. 

Focus of subscription category
If the IT services are subscription services, focus on identify, define and describe the ongoing commitment that will be in place after that the request is completed. The commitment needs continually to be measured and verified by the customer.

Focus of generic category
If the services are generic services, focus on defining levels and scope that is actually used. There is no meaning of defining Gold, silver and bronze if nobody ever is going to by the Gold. Try to se it from the customers point of view instead of just copying something you seem fit. High flexibility and configurability is key, otherwise you will get a service with flavors that is to static to perfectly fit any customer

Focus of specific category
If the services are specific services, focus on the case the customer want supported. Understand the constraints the customer is dealing with and make sure your actually make life easier for the customer. 

Focus of process oriented category
If the services are process oriented services, focus on understanding the customer and their business process and the output the customer is trying to achieve. Make sure the service and the service content is named and described in business language according to the business process the service is supporting. There is major incentive to actively work with IT service Portfolio and IT service Catalog concepts. 

Focus of bundle category
If the services are bundled services, focus on making sure the bundle decreases the number of request the user needs to do to achieve their output. Bundled service commitments also needs to be described but tend more to be influenced by request patterns and other practical packaging. 

Focus of customer facing category
If the services are customer facing services, focus on defining relevance of services from customers point of view. When the customer enters the request portal the content shown should have high relevance for the customer. It should be obvious to the customer what the purpose of the content is and navigation should come naturally. The service should also be of high importance for operating the service with an accurate customer value defined to enable prioritization in the ongoing service delivery.  

Focus of supporting category
If the services are supporting services, focus on defining a delivery structure where the supporting services are put in relation to the services they are supporting. It is important to understand the impact and risks when planing changes or handling disturbances.