What is process design (my way) post 1(5).

This is a series of 5 posts. All posts are available. 

Process design! All ITSM professionals talk about it. It is mentioned in every project addressing ITSM, ITIL or IT processes in general in any context. But what is it? I mean in detail? How do you do it? And when you do, what are you actually doing? 

I have never written an ITIL book or published any commercial literature and I do not have any plans to do so either. What I have done though, are design, re-design and improve-design of processes for more than a decade successfully. And I will give you a peek into my world, my practitioner world, my reality, my success. 

I don't claim that I have a universal method. I don't claim that this is fully reusable in any situation. What I do claim, is more than a decade of successful design. 

Now you might think that if I have been designing processes successfully for more than a decade, what on earth have I been doing for all these years? How many processes have I designed? Well let me break it to you. It is not about quantity, it is about quality. The lifecycle of an effective process demands nurturing and care. Just like the parenting of a child. A child is not considered a failure for not being able to read or to know math at the age of three. It is considered a success for the ability to walk. It is the same with a process. In the early stages there will be results that the process cannot achieve but still be a success. It needs to evolve and mature. That takes time, effort and a lot of collaboration.

Process design is not a one time job! It is a continuous parenting based on input from a whole lot of sources, mostly human but there is a lot to pick from. Well, back to the topic. What is process design?

First of all, the most brilliant process design will still be utterly useless if it does not improve and help people to achieve the expected outcome. If this is the case, all design work is waste! So a critical factor to claim success is the ability to achieve change and to measure that output. Read more about how to improve your change ability in post 5(5)

Now there will be ITSM pundits out there that will protest and say, if the output is not consumed by a customer there is no value and still useless. I don't disagree but let's keep it simple. If we can't generate the expected output, we won't have a customer in the first place so I will address the output and then we can have the value discussion at another time. 

Next post in this series: What is process design (my way) post 2(5). The two major parts.

What is process design (my way) post 5(5). Summary.

So now you have read my example (simplified yes, but still not fiction) of the results expected from the initial process design from part one and two. As I said, this is not a "cut and paste" material. The key here is to get a solid acceptance from the participants from both parts that this is the truth and nothing but the truth. There can be no discrepancies and this requires multiple iterations from both parts to be thoroughly accepted by all. The content needs to come from them, you can still use this material to guide the workshops and discussions but it cannot be forced. It is people you’re dealing with. Respect their profession, experience and competence.

The acceptance is one factor that radically improves your ability to accomplish the necessary change and to get people onboard. The end game is to facilitate the change that is required to improve the output. If the output does not improve, your wasting everybody's time.

I left out one thing in part two. That is the detailed activity flows for each of the sub processes. It is in these activity flows you design the order of activities and any dependencies there might exist to preform them. Dependencies can be to other activities in the same process, activities in other processes, specific information, tools, access etc. All these dependencies needs to be identified and documented. 

It is very important that the sub process activities identified and defined in the activity flow fulfills the sub process objectives. Individually or collectively does not matter but they must contribute to all of the defined sub process objectives one way or the other.

It is the detailed activity flow that can act as the baseline for any tool implementation that you might be planning or that you already have in place that needs to be changed and improved.

This series of posts only cover selected content from my process design. There are much more to be done and process documents to write to get a complete picture. But don't forget. This is not a one time job. As soon as you stop managing, analyzing and improving the process and sub processes, it will deteriorate. 

Links to all posts in this series:

What is process design (my way) post 1(5).

What is process design (my way) post 2(5). The two major parts.

What is process design (my way) post 3(5). Part one.

What is process design (my way) post 4(5). Part two.

What is process design (my way) post 5(5). Summary.

What is process design (my way) post 4(5). Part two.

So let’s get deep. I will continue with the Knowledge management process and here is content for each of it's sub processes.

Knowledge management process - Part two, the sub processes.

1. Identify, record and approve knowledge

Objectives:

• To identify and process any potential knowledge

Main focus:

• Process draft knowledge articles relevant to support and maintain an application, system or IT service
• Validate and approve draft knowledge articles to enable accessibility and usability to relevant audiences

Stakeholders:

• Service Delivery Managers
• IM/PM Manager
• Change Manager
• Service Desk Manager

Measurements:

• Time between draft, creation, review and approve
• Amount of articles reviewed by Knowledge Coaches
• Amount of articles reviewed by others than Knowledge Coaches
• Amount of draft knowledge articles created from change Management
• Amount of draft knowledge articles created from support issues 

Key functions/roles:

• Knowledge Manager
• Knowledge Coaches
• 2nd & 3rd Line support
• Change Manager

2. Transfer Knowledge 

Objectives:

• Document knowledge from Change management (proactively)
• Document knowledge from support handling (reactively) 
• Ensure accessibility and availability for the knowledge target operator, group or audience

Main focus:

• Ensure accessability, findability and usability of the articles by those who are to use it

Stakeholders:

• Knowledge Manager
• Service Desk Manager

Measurements:

• Amount of knowledge articles created from Change management 
• Amount of knowledge articles created from support issues 
• Number of knowledge repositories used and maintenance of them

Key functions/roles:

• Service Desk
• 2nd & 3rd Line

3. Monitor Knowledge

Objectives:

• Monitor knowledge articles to aid in support and management of IT services
• Monitor and evaluate the quality and rating of knowledge
• Monitor and evaluate the Use and effectiveness of knowledge

Main focus:

• Monitor quality and use of knowledge articles to optimize usability of content

Stakeholders:

• Knowledge Manager
• Service Delivery Managers
• IM/PM Managers
• Service Desk Manager
• Change Manager

Measurements:

• Usage of knowledge articles
• Average reuse of knowledge articles
• Amount of knowledge searches leading to incident resolution
• Rated quality of knowledge articles
• Monitor usage trends of knowledge articles
• Monitor searches that does not provide relevant knowledge

Key functions/roles:

• Knowledge Manager
• Service Desk
• 2nd & 3rd Line

4. Review, validate and retire knowledge

Objectives:

• Review and update knowledge articles to improve their quality and level of reuse
• Ensure that only relevant knowledge is available by validating content and retire and close irrelevant content

Main focus:

• Correct and improve knowledge article content and searchability
• Fix incorrect knowledge articles or flag them for review

Stakeholders:

• Change Manager
• Service delivery managers
• Service Desk Manager

Measurements:

• Amount of articles flagged for review
• Amount of articles retired and closed

Key functions/roles:

• Service Desk
• 2nd & 3rd Line
• Knowledge Manager
• Change Manager

Next post in this series: What is process design (my way) post 5(5). Summary.

What is process design (my way) post 3(5). Part one.

So let’s get real. I will use one of my favorite processes that I feel is so often misunderstood in the ITSM community as my example. The Knowledge Management process. You might think that the following is not a complete description and it is not. It is an example and a simplified one. It’s just to show parts of the content but it is real, no fiction.

Don't forget that this is not a "cut and paste" material. You still need to do the work yourself but feel free to reuse all of this content in any way you see fit.

Knowledge management process - Part one, the process.

Mission: 

Enable reuse of knowledge to deliver faster, more accurate and consistent support to business with decreased effort for resolutions and dependence on individuals. 

Goals: 

• Reduced dependency of individuals for knowledge
• Reduced time and effort required to maintain and support IT services
• Ensure that all knowledge used and stored is consistent and readily available.
• Improve the organization’s ability to utilize relevant information.

Success factors:

• Ability for staff and vendors to find and access relevant knowledge when needed
• Ability to distribute the creation, review and update of documented knowledge among staff and vendors
• Ability to follow-up and reward the right behavior among staff and vendors to create and maintain a culture of knowledge sharing
• Ability to track the usage and quality of documented knowledge 

Key Performance Indicators:

• Increased number of times knowledge articles are being reused
• Increased level of resolution within 1st line of support
• Increased amount of knowledge searches leading to incident resolution
• Increased rating of knowledge management satisfaction surveys among staff and vendors
• Increased speed of handling recurring incidents

Output:

• Increased speed, accuracy and consistency in IT support handling
• Decreased cost of labor for IT support handling
• Faster time to proficiency for IT staff and vendors

Sub processes:

1. Identify, record and approve knowledge
2. Transfer Knowledge
3. Monitor Knowledge
4. Review, validate and retire knowledge

Next post in this series: What is process design (my way) post 4(5). Part two.

What is process design (my way) post 2(5). The two major parts.

Assuming that the ability to achieve the necessary changes exists, I divide process design in two major parts. First part is very corporate oriented and tend to include a lot of theory and logic, the second part is very operation oriented and tend to include a lot of practice and how to. I have run both parts in parallel, in sequence and backwards all with the same result. It does not matter. They will affect each other so the number of iterations is dictated by the distance between them both. I promise you there will be a distance between them and that is exactly what the process design is to identify and to close that gap. 

I have heard and read about numerous process projects where the initial process design phase has been closed in the early phases of a project and the project team has only read books and talked to management at that stage, not talked to any process performer/operator/role. That would be a shortcut to failure to me. That would only address one of the two parts of process design for me. 

Part one in process design - The Process: Define and describe the process mission, process goals, critical success factors, Key performance indicators, sub processes and expected output/benefit aligned to corporate strategy and goals. This needs to be business oriented.

Part two in process design - The sub processes: For each sub process, define and describe objectives, stakeholders, measurements, main focus, key functions/role involved and a detailed activity flow. This needs to be practice oriented.

Part one is done with the business, management and function responsibles and part two is done with stakeholders and highly qualified and experienced process operators that really know how things are done in reality. 

When the first step with both these parts are done the gap needs to be identified, analyzed and closed. The gap will be there. There will be missing measurements and activities in part two that are necessary to achieve the objectives for that sub process and there will be activities that are identified that does not contribute to the sub process objectives or should belong to, and be performed in, another sub process where it contributes to the corresponding objective. 

There will also be missing sub process objectives that needs to be identified and included to support the overall process goals and mission. Some process goals will later be identified and changed to a sub process objective and vice versa. This is the iterations that the gap between the two parts will generate.  Both of them feed each other with valuable findings, changes and content etc. They need to be addressed and designed as one but due to the difference in detail and participants they can be managed as two different work streams e.g. part one and part two, in parallel or in sequence with iterations to close the gap.

When the initial design is done, the content for the process, part one, will tend to be quite static. There will be changes over time that is identified but still, they will be few. The sub processes on the other hand, part two, will be more dynamic. This content will, and need to change to evolve the overall process and is a never ending story. As soon as you stop managing, analyzing and improving them, the process will deteriorate. 

Next post in this series: What is process design (my way) post 3(5). Part one.

New jobb

It's sentimental and melancholy at the same time as I feel excited when I tell you this. 

The day I thought would come naturally in 20 years, will come in February. The day I speak of is my last employed day at H&M Hennes & Mauritz. I have had a wonderful and fun time during my +14 years in the company and I have learned so much from my colleagues, some have even become my best friends. It has been an honor and it is sentimental to meet and work with all of you the last few days I have left in Stockholm. 

The excitement is for my new employer Närkefrakt in Örebro. In February I will face a new business, new colleagues, new customers, new challenges etc as their CIO and I'm really looking forward to it. I bring 25 years of IT experience and I have so much to give while there is a lot new to learn. I am convinced that Närkefrakt will be a thriving environment where I can use my full capacity and develop together with the business. I can hardly wait to start contributing. 

Best regards / Mika Salo

Transitioning to CIO at Närkefrakt

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.

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.

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.

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.