Troy's Blog

Thursday, June 17, 2010

Using Lean Principles for Effective Continual Service Improvement

“Standing On A Lean Scale Takes Discipline and Unusual Courage”

Lets face it sometimes ignorance is bliss!

One of the challenges related to effectively engaging in continual service improvement or even the initial task of documenting processes, policies and roles is that it forces us to take a long hard look at what we do today.

The desire not to acknowledge or confront what we know to be issues stems from the same irrational dislike we have for bathroom scales or even worse the annual fitness assessment at our family doctor. As long as we don’t have the facts confronting us we can willfully ignore what we intrinsically understand to be true but do not have to will or desire to face.

This is where formal Improvement Models can be used effectively to move us into the discipline of self evaluation and prioritized improvements. This is the same reason we sign up at health clubs and work with expensive personal trainers or in our context consultants. It is not that we could not figure out what needs to be improved on our own, but somehow working within a structure and being held accountable gives us the discipline to get things done.

This is where Lean Principles can be used to drive a discipline of assessment and improvement.

First: We acknowledge that there are many things we do today that are not directly or indirectly beneficial to our goals or produce value. In short activities or actions in which we engage that are wasteful, redundant and provide zero to no value.

This means we have to first understand which activities of a process are part of its “Value Stream” where process inputs are worked on and transformed into a valued output that meets a validated need. In light of this understanding we can assess all process activity in terms of:

Valued Activity: Actions, resources or activities which have a direct connection to producing the desired outcome
Non Value Activity: Actions, resources or activities that while not having a direct hand in producing outcome provide the necessary measurement and governance elements to keep the process intact. (The glue that holds the process together and executed as expected)
Waste Activity: Actions we take that neither support the outcome or have a hand in keeping it glued together

With these principles in mind the goal is to optimize the valued activity, minimize the necessary Non Value Activity and eliminate the waste. However the question is how do we identify the waste, trim the fat and make sure we are only doing things that produce value?

This is where the Lean waste categories come in; time to have your process measured on the Lean Scale!

Consider using the following categories to evaluate either your current “As Is” process or even your freshly minted “To Be” process design and face the unpleasant and sometimes downright ugly facts of process bulge that will likely require a lifestyle change to remove.

Overproduction—Too many steps, transactions, authorization requirements, cycles in the process

Lets face it sometimes our processes look like Mac Trucks when what we really need is a Honda Civic or a GM Vibe. The problem with some of us process geeks is that we can over engineer a process based on the goal of perfection versus fit for purpose. Sometimes good enough is good enough!

ƒƒOver processing—Too much Non Value-added activity

Yes measurement is good, and assessments have their place to keep an eye on quality and service improvement opportunities. However, maintaining a sane balance of reports, administration and process governance is key based on the complexity and risk required.

ƒƒWaiting Unnecessarily—Too much time between process activities

Since a process is at heart a series of dependant or parallel tasks which take inputs from the upstream activity and passes them downstream towards the eventual value based outcome there are many points of potential wait states where the flow of the value stream spends unnecessary time queuing. Making sure that these wait states are not unduly long or even necessary is a key part of finding opportunities for process improvement.

ƒƒOwnership Issues—When a single person cannot be identified as the single point of process accountability (The request “Take Me To Your Leader” produces a blank stare!)

Without clear ownership a lot of finger pointing and “Someone should really take care of that” type of statements are common. Just like having 25 priorities means you have no priorities, a process with out clear ownership suffers from benevolent neglect. The concept of we all own it is sure to lead to wasteful activity.

ƒƒUnnecessary Movement —Too much or redundant movement between value-added steps

A good example of this is an incorrectly designed Change Management process where all changes regardless of risk or size flow through a change advisory board for approval. This tends to bog a Change Process down to where it is deemed to be ineffective, bureaucratic and yes wasteful of people’s time. The idea is that changes should have the right level of approval and release assurance based on the level of risk. To many approval cycles for a minor change is not beneficial.

ƒUnderutilization Of Human Resources and Talent — We don’t use the skills and talents that we have

We typically think of waste in regards to things we should not be doing. How about those things or people we should be using but do not due to political or lack of knowledge reasons. An example of these types of situations? How about not giving the Service Desk ownership of end to end incidents? Not utilizing your Quality Assurance folks as part of your production assurance steps of Release and Deployment Management Not tying your Architecture group into the process of defining IT Services (many of which they helped to design). Unfortunately we too often allow silo mentality block us from using the skills already inherent in our organizations.

Lets face it we could all loose a few pounds of inefficiency if we looked at our current practices through the pragmatic lense of value and waste.

Troy’s Thoughts What Are Yours

“Regret for time wasted can become a power for good in the time that remains, if we will only stop the waste and the idle, useless regretting.”
~Arthur Brisbane

Tuesday, May 25, 2010

The Three Perceptions of Implementation

Contrary To Popular Belief Semantics Do Matter!

In this article I am going to explore three very different perceptions / definitions about the word “Implement” that are critical in regards to any IT related project but also have a great deal to do with the success of an ITSM program.

The source of this article comes from a great book titled “Change & Effect” ISBN 978-87-993289-0-1 on Managing Organizational Change from our Partners in Denmark aptly called “Implement”

Now before the ITIL purists protest vehemently that you don’t implement ITIL practices, preferring to use the word adopt or adapt let me but this in context. What we are discussing in this article is the fact that you are going to implement a change of some sort into your management system that will impact the processes, policies, ITSM tools, job descriptions, measurements, etc. of your current organization. Also by Implement I am assuming you hope the change to stick and benefits come of all the work and money your organization has invested in your project.

The primary point of this article is to reflect on your personal or organizational understanding of this very important word! I may have already tipped my hand in the previous paragraph but consider that in the last decade or so I have seen many organizations fail at their ITSM projects due to the fact that they have greatly underestimated the work effort of their initiative. (Adopting, Adapting, Implementing) ITSM practices is not about simply documenting a process or purchasing and implementing and ITSM software solution. In fact these are only enabler’s to the goal of achieving a change of behaviour. More on this subject in the Article. “Establishing Or Assessing An ITSM Program”

However, on a more narrow scope of discussion lets apply the three definitions found in this excellent book.

Note: I have taken some literary liberty with the Headings but remain true to the concept’s of the three definitions.

Install The Software And Let Them Figure Out How To Use It

In this definition of the concept of Implement, the focus is typically centred on the software and little to no effort or thought is given to process, policy documentation outside those basic things needed to configure the tool such as the rudimentary classification structures. Any training sessions that are provided are strictly focused on tool functionality. Phrases you often hear from people who hold this perception of the word Implement are:

“These folks are IT professionals they should be able to figure this out for themselves”
“We don’t need to define processes since the tool will provide all the process we need. We will simply adopt the process in the tool”
“The tool is very intuitive we don’t need to develop much if any kind of training strategy”

Book Quote:

“Implementation is to install a change, You focus on commissioning the change initiative and handing it off to line managers, expecting them to accept responsibility for it.”

The good folks who hold to this perception of the word Implement largely focus on the Tool as the primary element that needs to be considered and managed. Unfortunately they are also the folks that will be accused of another IT project being thrown over the fence for someone to catch without any knowledge of what to do other than login and open a screen or two.

Define, Automate The Process and Train Users On How To Do Their Jobs

In this definition of the concept of Implement the focus goes beyond the tool to also having some definition around the job skills, policies, process and automation elements of the new working methods. Focus is given to creating what we often refer to as “Deployment Workshops” where the users of the new process and tool are required to go through a training session that covers both the newly defined process elements and provides exercise / use case based tool training in a lab or online environment before they are asked to begin using the new process. Phrases you often hear from this perspective are:

“We need to train process users how to do their new or modified Jobs”
“We need to measure how the process is being executed for compliance”
“We need to make sure people understand the policies related to the new way of working”

Book Quote:

“Implementation is to install a change and secure stability of the new state. You launch the change and make it stick by training the users and helping them develop procedures to support and reinforce the change.”

This approach is typically help by organizations that look at the process and tool holistically and are focused on making sure that that Joe and Jan process user knows how to perform their daily tasks.

Establish A Process Governance Structure To Build And Improve On The New Process and ITSM Tool Deployment

This perception starts interestingly enough with the understanding that perfection is not the goal. Rather the goal is to create an overall organizational capability relative to the governance, process and tool structures that will target the realization of value from day one but that also focuses on establishing the structures needed to take what is initially deployed and to improve and further refine it over time. In essence the focus of the project is on creating a platform for continual improvement that will take the initial project and hand it over to an organization that will immediately begin to personalize and improve it based on Continual Service Improvement principles. Phrases you often hear from this perspective are:

“ITSM is not a project or a short term diet, its the rest of your life”
“The goal is not perfection but just good enough for now so we can build on what is first deployed”
“The ITSM project is a transformational program needing serious management of change, not just a tool or process documentation exercise”

Book Quote:

“Implementation is to install a change and build capacity for the organization to develop by itself. You work to integrate the change into current practice while leaving things open for further change. The new elements are not considered an end-state in themselves.”

Based on my personal experience this third perception of the word Implement most accurately describes the appropriate perspective of an ITSM program. Unfortunately the first two understandings of the word are all too common and often lead to very disappointing and unexpected results. Success with your ITSM/ITIL project is ultimately determined by what foundations and structures you have put in place to take your initial project deliverables beyond the proverbial “Toss Over The Fence” to a more integrated approach to establishing the elements required to realize positive change that endures the test of time.

Troy’s Thoughts What Are Yours?

Things alter for the worse spontaneously, if they be not altered for the better designedly.”  ~Francis Bacon

 

Thursday, April 08, 2010

The Art Of Building an ITSM Process Design Team

Sometimes the journey is more important than the destination!

Documenting processes is rarely on the top 10 list of an organization’s fun and interesting things to do with its non-existent free time! However, it is a fundamental necessity once the organizational complexity no longer supports an organic or immature approach to key management processes.  Or perhaps other key drivers that force a company to the drafting table may be risk to the business mission or the legal requirement to comply with audit and legislation. Whatever your drivers may be you will one day find that it is time to formally put pen to paper and map out the who, what, when and why of what you do or perhaps more importantly what you should be doing.

As each organization reaches this point they are inevitably faced with the fact that they have scant resources to accomplish their process design goals. They also often find out that their current processes no longer scale or need to be changed to follow best practices.  This double constraint gives them the idea that surely they are not unique and that there must be other organizations or consultants that could help them short cut the time required to define new processes with pre-defined templates and hard won experience.

While this is true it is important to understand that there is a positive and a disastrous way to bring in external assistance to help with your resource and knowledge gaps.

Using External Consultants:

How and when to use external resources is a very important decision that can either fast track you on the way to having your processes defined or end up with you wasting a great deal of money with little to no real lasting impact or value for your investment.

While it is true that external resources can provide the missing expertise, knowledge and pair of extra hands you so desperately need it is equally true that they are seen as not belonging to the inside family circle and have limited ability to change perception and practice.  The result of which is that they can excel at some tasks but will fail miserably at others if used unwisely.

For example if you are brining in external consultants to document what you do already then it is feasible for them to hold a series of workshops and interviews to piece together the intricate workings of your existing policies, processes and roles and hand over a written account of what you do today. However, if you are changing what you do to follow an external best framework such as ITIL or CMMi then what you are really talking about is a transformation project where you have to convince a very distributed and culturally diverse organization that they need to change their long held behaviours, beliefs and tools. In this second scenario it is self-destructive to assume that you can hire out all the work to an outside firm. What you will end up with at the end of the day is a very nice process binder that no one in the company believes they had any part of designing (even though you involved them in interviews and workshops) and will treat it as a “Not Invented Here” deliverable which will sit beautifully on the shelf and not be followed.

Building Buy In Through Sweat Equity and Emotional Attachment:

At the end of the day a transformation project requires organizational involvement in the heavy lifting of a process design and software configuration project. As indicated in the paragraph above the internal stakeholders will not feel connected to the new process unless they have the perception that they have been involved in it’s design in more than a casual way. However, if you accept this premise the key question and constraint continues to be how do you free up the internal resources to work on this project in some meaningful capacity.  The answer to this question is a blended approach to using both internal and external resources.

Here are a few important assumptions:

• You need to involve key stakeholders in the design for the organization to believe it will work for them.
• You also need to use external consultants to bring to the table the key value elements of experience, knowledge, resources and fast track templates.
• It is important to realize that without a formal project approach to the transformation effort little change will occur. Transformation efforts never succeed as a side of the desk activity.
• The most likely candidates for your internal design team are already engaged in other activities making dedicated commitment to the project not plausible.
• You need to balance the involvement of high value internal resources with a need for speed to delivery.
• The true deliverable of your project is not a completed document or process but your organization operating in a new way with new values. 

This last point is perhaps the most significant of all the assumptions and is the basis of why using only consultants to help define your new processes is not a viable solution. The key realization here is that it is the process of building and gaining agreement (not consensus) that is the true deliverable of a process design project. The actual achievement of a finished product is the icing on the cake and perhaps a minor but relevant detail for actually supporting a transformation project.

Consider that the true goal of a transformation project is to change behavior and eventually culture. To achieve this it is necessary to define a process, write it down and automate it in a software application but these are only enablers to the true outcome of transformation.

At Pink Elephant our experience tells us that there are seven key ingredients for a successful recipe when building transformation teams:

1. Establish a formal project with the classic project sponsorship, governance and controls necessary to accomplish any major initiative.
2. Source a reliable external trusted advisor that has a solid track record in supporting process transformation projects. This vendor should provide both strategic and operational support and come with a little red wagon full of time saving tools.
3. Develop a small part time internal process design team that will work on the process deliverables 2 to 3 days of week schedule permitting. This team should be made up of internal subject matter experts, change agents from key stakeholder groups and be supported by your external advisor and software administrators responsible for process automation.
4. Define an extended internal stakeholder group of middle and Sr. Management roles that will provide feedback and approval on your process deliverables via email feedback loops or workshops to optimize organizational acceptance.
5. Start early on defining the ongoing process governance, support and execution roles that will use the process after it has been deployed.
6. Leverage other organizational support groups such as corporate communications, HR, internal audit, procurement and software development to support your initiative.
7. Plan your deployment and rollout strategy to occur as rapidly as possible without jeopardizing your existing service delivery. (Its not easy to change your tires as you are driving down the highway)

As individuals and key stakeholders take an active part in the design of your new processes they begin to feel the necessary emotional attachment to their deliverables and want to see the blood, sweat and tears they have shed be effective and successfully deployed. It is amazing how a far a little bit of sweat equity will go in the effort to convince people that change is a good or at least an acceptable thing.

Many organizations have tried to short cut this effort or relied exclusively on external resources believing that this level of involvement and internal investment is not really necessary. Only to find out that to ram the change down the corporate throat with out consultation or involvement may have short-term success but will also just as likely result in the organization’s eventual rejection of the change once the heavy hand of compliance is lifted.

This Article was originally written for publishing on ITSMWATCH.com

Troy’s Thoughts What Are Yours?

“That’s the best thing about walking, the journey itself. It doesn’t matter much whether you get where you’re going or not. You’ll get there anyway. Every good hike brings you eventually back home.” (Edward Abbey)