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. 

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.   

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?

 

2. 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?

 

3. 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!

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!

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!

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.

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.