Thursday, September 02, 2010
Help! No One Is Following Our Processes!
I Just Don’t Understand Why They Don’t See The Value!
We did everything by the book and We thought for sure this would work.
- The CIO stood up and declared that she/he believes
- We sent everyone to ITIL Training
- We engaged knowledgeable consultants
- We developed process design teams with participation from key stakeholders
- We had creative communication sessions
- We conducted proof of concept pilots, focus groups, process testing workshops
- We delivered quick wins and small improvements to show people we were on the right track
- We designed and executed a brilliant marketing campaign
- We purchased a great ITSM Service Management Software
- We trained all key stakeholders on our new processes
Why then is there no real adoption or compliance to the new Process?!!!
Interesting question, can you relate?
Apparently many organizations are in the same boat. This week alone I spoke to three quite different companies with this specific challenge.
Now to be clear, all of the points above are necessary and the right things to do when you are tackling a major transformation project. However all of that is not sufficient to ensure the organization follows the process after you go live and disband the project team.
The item missing from this list comes down to Professor John Kotter’s 8th Step for Managing Organizational Change “Anchoring new approaches in the culture” from his well known books “Leading Change” and the “Heart of Change”
- Establishing a sense of urgency
- Creating the guiding coalition
- Developing a vision and strategy
- Communicating the change vision
- Empowering broad-based action
- Generating short-term wins
- Consolidating gains and producing more change
- Anchoring new approaches in the culture
Without that last step in the Kotter model the result of all your work comes to naught leaving you (and the rest of IT management) frustrated and disappointed.
In the end, this last step may well be the most critical to your transformation activities. You have to find the courage and organizational will to transcend silos, create new governance/ownership structures, new roles and personal performance measures that will ensure that Executives, Managers and Staff feel personally accountable to actually change their behaviour and practice the new methods.
When you address these critical success factors for anchoring the new approach at a personal level for every individual in your organization you will get real change. Oh, the more positively inclined and cooperative people will get your message and intuitively understand why the new process is better. However it probably means more work for them and they will willing follow the process until during a stressful moment they are forced to make decisions about what to do and what to drop.
Unless the individuals / departments and organizations believe they are being measured and held accountable for the process in a real and tangible way that actually has consequences, they will resort to the path of least resistance when deciding about how they operate and what work they will prioritize.
This inability to establish the organizational capability to deploy the process is one of the key impediments to success that we hear over and over again, and is a key finding of the research we did at our Pink Perspectives in 2008.
7 Enablers for ITSM Expanded - Ability To Deploy - Designing An ITIL Process Is The Easy Part
Moving people to change their current practices takes effort on many levels. In one sense you need to engineer out of the organization any potential legitimate excuse for non compliance. A topic I explore in greater depth in the following article: Employee Compliance A Key Factor For ITIL Process Adoption
So, if you are on an IT Service Management journey and you look back on your efforts and are asking “Why is there no real adoption or compliance to the new Process?” , the chances are that you have not created the necessary organizational structures, governance roles and performance measurement systems to motivate people to believe that this is a change that benefits them as well as the organization and that they have to follow the processes or suffer the consequences.
Ask yourself, “What are the real consequences of not following that process you worked so hard to establish?”
Build it and they will come only works in fantasy movies like “Field of Dreams”
You can have the world’s best process design and a great IT Service Management tool and people will still not choose to change and follow your process unless you have anchored your new approaches into the culture with personal accountability.
Troy’s Thoughts What Are Yours
Insanity: doing the same thing over and over again and expecting different results. ~Albert Einstein
ITIL & Beyond • (1) Comments • (0) Trackbacks • Permalink
Friday, August 13, 2010
Why You Need To Know ISO 20000
When You Are Building a House It Needs To At Least Meet the Code
ISO 20000 as the International Standard for Service Management has been published since 2005 and it is going through its first major update this year and next.
My good friends and fellow Pinkers Jack Probst and Robin Hysick are involved in the update project and Jack has the honor of serving as the US Task Group lead (Task Group 25) for the 20k update and is in the thick of things.
Add to this a noticeable lift in general interest and the addition of the ISO Foundation course to our growing portfolio of IT Management Education products and you will see why ISO 20000 is top of mind for me.
In my role of Product Strategy and as the Lead of our Consulting Practice I am expected to answer the “So What” question on a frequent basis.
So What: Why should I care about ISO 20000, if I have an ITIL background and certifications up the wazoo? Or conversely why should I care about ITIL since I have my Auditor’s or Consultants Certificate in ISO 20000?
Both are good questions that until recently I have struggled to find a concise “Elevator Speech” for. That is until just recently when I was talking with another Pinker friend of mine Anil Dissanayake. Anil and I were discussing the ISO 20000 class he was teaching and wrestling with the best way to position these two elements ITIL / ISO 20k when an analogy came to me that made the whole puzzle crystal clear in my head.
First we need to establish some baseline understanding.
ITIL is a library of knowledge or good practice which provides a reference model covered in 5 substantial books of a few hundred pages each
ISO 2000 (2005) Is a standard documented in two main parts:
Part 1: Specification - “Must Haves” (24 Pages including all the white space, terms of references and the usual acknowledgements)
Part 2: Code of Practice “Nice To Haves” (42 Pages providing an expansion on the specification with illustration, commentary and additional concepts)
So in total being overly generous there are 66 pages of content to teach, consult or Audit on - providing you count the title pages and table of contents.
This is why I find discussion about adopting or implementing ISO 20k extremely frustrating. A topic I address in the following article.
ISO 20k The Industrial IT Password / The Value And The Misunderstanding of ISO 20000
So that being said why should you or anyone want to attend a course on ISO 20000?
This is where my analogy comes in: Electrical Code and ISO 20k
Lets for the moment put this in the context of the trade of Electrical Engineering or simply the study to become a Certified card carrying Electrician.
As an Electrician you will need to study a body of knowledge relevant to your trade through a series of courses which start with the fundamentals of electricity and then progress on to harder courses studying the application of the fundamentals in various circumstances. This course of study will likely take you a series of years requiring you to pass a set of exams and certification processes which will eventual reward you with your license as an Electrician.
As part of this course of study you would also take one or more courses on the “Electrical Code” ensuring that you understand the minimum requirements for either the design of new projects or the repair and maintenance of existing facilities. As with most codes there is a minimum specification or mandatory set of requirements and also subsequent documents that expand on and provide context and further explanation of the code itself.
As part of your course of study you would study both the body of knowledge and the specification or code. It would not occur to you to do otherwise, even if your certification process as an Electrician did not require it.
So in this analogy you can make the following tie into the ITSM world.
As a student of IT Service Management you study frameworks of knowledge such as ITIL and COBIT but you also need to have a firm grasp on the minimum specification and code of practice for ITSM to ensure you build with the code in mind or conversely ensure your suppliers are providing you an ITSM service that meets at least the mandatory set of requirements. Explicitly: ITIL is the framework of reference and ISO 20k is the specification / code of practice that validates a minimum level of quality.
So the correct answer to the question: Which course should I take ITIL or ISO 20k? is Yes (Both are required)
Troy’s Thoughts What Are Yours?
”He knows the tax code as thoroughly as the pope knows the Lord’s Prayer.” William Proxmire
ITIL & Beyond • (2) Comments • (0) Trackbacks • Permalink
Friday, July 09, 2010
Request Fulfillment Improvement Roadmap
Request Fulfillment And Its Many Moving Parts
From the dawn of IT Support the users and customers of IT services have looked to the Service Desk or at least someone who will answer a phone or monitor an email account to respond to requests for new, modified or additional services.
As of ITIL version 3 Request Fulfillment is understood to be a separate and distinct process from Incident Management. I explored this process in an earlier article.
Service Request vs. Request for Information
From the ITIL v3 glossary we can find the following definitions:
Service Request: A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted. See Request Fulfillment.
Now that the debate over wether an Service Request is part of Incident or Change Management is over despite your personal views on the matter. Lets look at what it really means to tackle improvements around this process we have been doing for years.
First it is important to point out that making improvements to the process of managing requests is not as simple as dealing with one workflow. Like most things in life Request Fulfillment is more complicated under the surface than it may seem. Sure you can create an efficient way to submit requests without too much of a challenge. However, its what happens behind the scenes from the point of someone filling out the web form or making a call to the Service Desk until the shining new laptop is delivered fully loaded that takes the real work to figure out.
Think of the Request Fulfillment process like the two slices of bread on a sandwich, in between the top and tail of the processes are several other inter-related but separate processes. To improve the maturity of this process (make sure the new employee is productive on day one, or that that laptop comes with the right OS and software image) it is necessary to understand the approval, ordering, inventory and supply elements that support the provisioning of the request. A key understanding is that Request Fulfilllment is typically front ended by a Service Catalog or IT Portal and integrates key processes such as:
- Service Catalog
- Procurement, Cost Center Approvals
- Asset Management
- Service Asset and Configuration Management
- Service Level Management
- Provisioning
- Access Management (On boarding / off boarding of employees)
- Image Management
- Etc..
Without the tight integration of these various management practices the request is received and not progressed through these process dependencies in an efficient and time sensitive manner.
For Example: You receive a request to prepare for a new employee start in 5 business days but it is several weeks before all the accounts and elements the employee requires to be productive are delivered for their use.
Since what we are describing here is the coordination of a set of variable and dependant tasks executed by many different groups it is highly recommended that this process be implemented leveraging a tool best suited to supporting the full lifecycle of the request and that supports the management of dependant and parallel work orders or tasks.
Since what I have described can be a complex task it is typical that an organization will improve Request Fulfillment as a series of maturity stages or steps. In my experience the maturity of this process can often be improved in the following steps.
Step 1: The process is managed as an extension of Incident Management and front ended by the Service Desk. There are no separate process elements or established ownership elements. The process record is differentiated from the Incident record by an attribute on the incident record that establishes it as a request. This record level differentiation supports reporting separation and different escalation policies.
Step 2: The process is understood as separate and distinct from Incident Management and has defined in relationship to both process and requestable service elements. The Request Process is managed by an ITSM tool that supports the management of complex task assignments to multiple support groups that are required to provision different aspects of the request in a parallel or set of sequential tasks.
Step 3: The Request Fulfillment process is front ended by a Portal or Service Catalog that enables the workflow and approval aspects of requesting and provisioning service elements. Integration is defined with other key processes such as procurement, asset management and various supplier-provisioning processes.
Remember that perfection is not always the goal and that incremental improvement is better than no improvement at all.
Troy’s Thoughts What Are Yours?
“Consciously or unconsciously, everyone of us does render some service or another. If we cultivate the habit of doing this service deliberately, our desire for service will steadily grow stronger, and it will make not only for our own happiness, but that of the world at large.” ~Mahatma Gandhi
ITIL & Beyond • (0) Comments • (0) Trackbacks • Permalink


