Newsvine
LinkedIn
Digg
Yahoo! 360°
del.icio.us
Bloglines
technorati
MySpace
Getting Work Done Through People
Getting People Done Through Work
Pink Elephant - ITIL & Beyond
Help! No One Is Following Our Processes! Troy DuMoulin Thursday, September 2, 2010 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 con Content ↓ 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.
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”
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 |
Why You Need To Know ISO 20000 Troy DuMoulin Friday, August 13, 2010 When You Are Building a House It Needs To At Least Meet the CodeISO 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 Content ↓ 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) 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 |
Request Fulfillment Improvement Roadmap Troy DuMoulin Friday, July 9, 2010 Request Fulfillment And Its Many Moving PartsFrom 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 n Content ↓ 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:
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:
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 |
Using Lean Principles for Effective Continual Service Improvement Troy DuMoulin Thursday, June 17, 2010 “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 proce Content ↓ “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 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.” |
The Three Perceptions of Implementation Troy DuMoulin Tuesday, May 25, 2010 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 Content ↓ 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”
Note: I have taken some literary liberty with the Headings but remain true to the concept’s of the three definitions.
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” Book Quote:
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” Book Quote:
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” Book Quote:
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 |
The Art Of Building an ITSM Process Design Team Troy DuMoulin Thursday, April 8, 2010 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 Content ↓ 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:
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:
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) |
Reaching For The Future with BSM Troy DuMoulin Thursday, March 25, 2010 On The Path Towards Business “Oriented” Service ManagementI had a very interesting discussion this week with Bill Keyworth (Editor-In-Chief) of BSMReview.com about the concept of Business Service Management (BSM) and how there seems to be Content ↓ On The Path Towards Business “Oriented” Service Management I had a very interesting discussion this week with Bill Keyworth (Editor-In-Chief) of BSMReview.com about the concept of Business Service Management (BSM) and how there seems to be many conflicting definitions around this popular term. From my perspective: At a high-level BSM refers to the strategy, manufacturing and management processes/capabilities a Business Organization uses to deliver products and or services to an external consumer base. In this macro definition of BSM, the IT function works in partnership as one of many internal/external business support groups providing required and valued services to achieve the overall mission of the organization. In essence Service Management as a general term is a customer-focused approach to defining and delivering service a customer wants without asking them to worry about the details of how it is achieved. Sound familiar? “A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.” (ITIL V3) Unfortunately the confusion around the term Business Service Management often stems from one of the following incorrect assumptions:
While both of IT Service Management and ITSM Suites support the goal of BSM they are enablers as opposed to the goal itself. Consider that while IT is certainly a service provider the same can be said of other business functions such as Facilities, Plant Maintenance, Fleet Management, Human Resources, Finance, etc. Being a Service Provider does not make IT unique in a business context but it does focus the IT function on the value and purpose of the products and services it provides. For Example: A Bank has a business service called “Branch Banking” which is supported by Several IT Services related to telephony, desktop automation, application services, Internet connectivity, etc. At the same time the business unit within the bank responsible for delivering Branch Banking also subscribes to services supplied by Facilities Management, Marketing, Human Resources and Finance. Not to mention that there will need to be an external call center to take customer calls related to service disruption, complaints and requests. Every business function has strategic processes for defining requirements and portfolio, processes related to design and build, processes related to moving new products and services to a live state, and finally processes for supporting the ongoing management / maintenance of the products and services it provides to its consumers. A key principle related to the general concept of BSM is the realization that all service providers deliver products and services according to a lifecycle and require processes that relate to strategy, design, build, transition and ongoing operations. IT Service Management as documented in ITIL version 3 highlights the concept of IT as a service organization and provides guidance around good practice related to the processes required to define and deliver IT Services. In this context the only thing unique about the ITIL library specific to the IT function are the examples and case studies used in describing the processes from an IT context. Coincidentally many of the tools developed for use for IT Service Management are used by other business functions to support what are in essence the same processes in a different context. What is a company webpage other than a Service Catalog? The challenge that IT has historically faced in this discussion is the self held belief that it is somehow separate and distinct from the business it serves rather than being an integral part of the business context as one of many peer service partners. A Cultural Perception Of Separation Much has been written on the concept of “Business and IT Alignment” or “Running IT As A Business.” However, the primary challenge with both of these mindsets is that it leads to an inaccurate IT worldview that presents the business and IT relationship as somehow separate as opposed to inter-dependant. We see this perception reinforced by both business and IT executives. The business will discuss divesting itself of its non-core competency without considering its very lifeblood for manufacturing and delivering value to its customers relies on digital automation. In turn the IT Executive will focus on running IT as a business to the point that they see themselves as an internal / outsourcer and end up getting treated that way. To put this in perspective, it is important to first understand that information technology is only the latest of a series of technological advancements that have pushed business and commerce to new levels of automation and efficiency. The introduction of electricity, the advent of mass transportation systems and the more recent adoption of hydraulic based manufacturing technology have all gone through a similar model of adoption and integration with business processes. When these earlier technologies were introduced, they were seen as supplemental but separate from the business processes of their day and adopted in increasingly innovative ways until they became so intrinsic to the way business was done that separation was no longer possible. In the early phases of these technology adoptions, specialized management groups were often created alongside the business organization to manage and maintain these technologies. At one point the plant had a power generation department. (Concepts from Nicolas Carr’s “The Big Switch”)
So perhaps it is more appropriate to refer to the adoption of IT Service Management principles as a move towards Business Oriented Service Management. A focus on BSM elevates the role of the IT function from one that considers itself simply as a cost center managing information technology in mythical isolation from the business to one that understands its role as a critical partner in the business value chain. Perhaps IT should refer to any function in the business context as a “Partner” and reserve the term “Customer” for the external consumer of the organization it serves. (Despite what ITIL says!)
“People do not want quarter-inch drills. They want quarter-inch holes.” |
Supplier Managers and Olympic Hockey Troy DuMoulin Friday, March 5, 2010 The Supplier Manager Is Like the Coach Of An Olympic Hockey TeamIts funny how our current focus areas are usually the product of several streams of consciousness. I suppose it all comes back to the old saying about the product of our efforts be Content ↓ The Supplier Manager Is Like the Coach Of An Olympic Hockey Team Its funny how our current focus areas are usually the product of several streams of consciousness. I suppose it all comes back to the old saying about the product of our efforts being greater than the sum of it parts. As a Canadian I am still enjoying the afterglow of the most successful Winter Olympics in Canadian history, with a record breaking Gold Medal win. This feat was topped off by the entire nation watching the Canadian Hockey team win the final medal game in sudden death over time. (What a rush!) My second stream of thought has been focused on the topic of Supplier Management. A subject I decided to research and write about early in the new year as it began to dawn on me that there is a growing strategic requirement to successfully integrate external suppliers of both classic and cloud based IT services into our IT value chain and management models. I understand fully that we have been in the business of outsourcing both operational and strategic services to external suppliers for some time now. The question of course is how successful have we been at this up to this point. This is further complicated when we treat them like outsiders versus adopted family members. A challenge I have written on before: Your IT Outsourcer - A Brother of Another Mother The difference I see today is that this landscape is about to get a lot more complex now that we are also moving to off premise cloud services for both business and technical services. Having just returned from a very successful Pink conference where I spoke on the topic of ITIL in the Clouds I made a statement that I had initially written on this blog: Choosing to use cloud services is a choice to outsource multiple slivers of your IT value chain. In my article on this subject as well as in my session I made the case that it is critical to integrate our suppliers into the ITSM Management processes for delivering services to our business partners in a secure, reliable and cost effective manner. For this reason I personally believe that Supplier Management is the most important / strategic Service Design process for companies to get right for the next decade and beyond. So how does the concept of Supplier Management relate to Olympic Hockey you might ask? (I was hoping you would Consider for a moment how an Olympic Hockey team is formed. A Senior Management group selects players from multiple teams and assembles the best possible talent from all of these different sources to create what they hope is a team cable of great success. However, the challenge that an Olympic hockey coach faces is that while they have assembled star players into this new team they come from very different hockey clubs. Each club has its unique style, culture and ways of getting the job done. What they have to do is to take these individual talents “suppliers” and get them to start playing as a cohesive team with a common play book. (Enter a company’s IT Management Framework) In my weird way of looking at life the Coach for an Olympic Hockey team performs the same role as a Supplier Manager in multi-sourced IT Management environment. The Supplier Manager helps an organization to pick the right players for the value network and then ensures and contracts that they agree to operate by the common play book (ITSM Processes). Otherwise what you get is a lot of individual talent moving the puck towards the goal as a team of isolated individuals. Any Olympic hockey team that cannot make this transition from talented individuals to a cohesive team approach will never get close to a medal round let alone ultimate success and glory. If you think about it for a moment this scenario is exactly what we are faced with every day in IT organizations that have multiple suppliers that are not integrated well.
So in closing I would ask you if you have an Olympic Hockey Coach / Supplier Manager working on your team that is not only focused on getting the best players for the cheapest price but also defining a strategy to take individual talent and build it into a team with a common vision, goal and play book for success! Troy’s Thoughts What Are Yours? ”Teamwork is the ability to work together toward a common vision. The ability to direct individual accomplishments toward organizational objectives. It is the fuel that allows common people to attain uncommon results.” ~Andrew Carnegie |
ISO 20k The Industrial IT Password Troy DuMoulin Friday, January 29, 2010 The Value And The Misunderstanding of ISO 20000I am writing this blog post on my way back from a 2 week Pink Expert Forum Roadshow with stops in Kuala Lumpur, Singapore and Dubai and now have a 14 hour flight to capture some of my thoughts arou Content ↓ The Value And The Misunderstanding of ISO 20000 I am writing this blog post on my way back from a 2 week Pink Expert Forum Roadshow with stops in Kuala Lumpur, Singapore and Dubai and now have a 14 hour flight to capture some of my thoughts around what I heard and saw and reflect on the interesting interactions I had with various people in South East Asia and the Middle East. One of the most memorable discussions I had was with a CIO who declared to me very proudly at a networking event that his organization was going to adopt and implement ISO 20000 in their IT organization. I thought this was a curious statement and proceed to ask some clarifying questions. I probed with a few gentle leading questions about whether what he really meant to say was that he was going to adopt ITIL practices for his organization and then go for an ISO 20k audit to verify and validate the improvements. However, he was not going to be deviated from his declared goal and insisted that his organization was going to Implement ISO 20k and that he had no business case justification for ITIL. Hearing his insistence on this goal I did my best to explain the relationship between ITIL the Best Practice Framework and ISO 20 the Code of Practice (Check list) used by auditors to assess an organization’s compliance to 14 IT Service Management processes but there was no shaking this gentleman from his dogged focus on ISO 20k as the goal. Interested in why he wanted this goal so badly I asked him why he was so interested in ISO 20k. His reply was very candid and frank. He told me quite clearly that his goal was to obtain the certification as proof to his customers that their IT processes were mature and followed best practice. After unsuccessfully trying to explain the difference between an ISO audit for compliance and a process maturity assessment (ISO audits do not measure maturity) I finally said with some regretted exasperation. “So what you really want ISO 20k for is a marketing tool for your clients” his answer to me was “yes that’s correct” Feeling that this conversation was not being very productive for either of us I took one final stab at trying to explain the difference between ITIL and ISO 20k. I told him that the real detail was to be found in the ITIL Library and that the ISO 20k Code of practice was only 42 pages long and that it could not possibly have enough detail in it to provide guidance on how to adopt the processes and elements it describes for audit purposes. Perhaps this statement was a bit over the top and for that I am sorry since it ended our conversation quite abruptly and the gentleman walked away towards the food and beverage tables. A third person that had been part of this exchange looked at me and said something to effect. “What many Executives wan’t out of ISO 20k in this region is the industrial password that will get them new business or increase their organization’s status.” Now don’t get me wrong, neither of these goals are necessarily bad in and of themselves but my personal belief is that the goal should be to improve your IT organization and services first and then if you have done the heroic feat of actually adopting and implementing 14 IT Service Management processes described in ISO 20k across the full scope of your IT organization then by all means celebrate this achievement by having an ISO 20k audit validate all the hard work your organization has done. There is a purpose and use for process frameworks like ITIL as well as ISO standards but it is important not to confuse the ends with the means. Troy’s Thoughts What Are Yours? It is a mistake to think you can solve any major problems just with potatoes. ~Douglas Adams |
ITIL Castles In the Cloud Troy DuMoulin Thursday, December 3, 2009 Launching A Cloud Computing Strategy Means Outsourcing Multiple Slivers of Your IT Service Value Chain[Young Cosette - Les Miserables]There is a castle on a cloud,
I like to go there in my sleep,
Aren’t any floors for me to sweep,
Not Content ↓ Launching A Cloud Computing Strategy Means Outsourcing Multiple Slivers of Your IT Service Value Chain [Young Cosette - Les Miserables] There is a castle on a cloud,
Response: In one sense this is a correct, since you are paying an external supplier to provide a complete service outcome. The service can come in the form of an account for a hosted software service, a development platform or a set of virtual infrastructure components without you having to own or manage the physical assets. However, on the other side of coin it is critical to understand that what you are also doing is introducing a new set of players into your existing IT management processes. Just as Young Cosette discovered in the musical Les-Miserables we still have to sweep the floors and take care of business even when we live in the clouds. [At The End Of The Day - Les Miserables] At the end of the day you get nothing for nothing What the IT Community is quickly coming to realize is that to deploy a cloud strategy within their organization successfully a number of processes and IT Service Management elements have to be defined - and better yet - automated from request through verified provisioning and then keep running as long as needed. Take the following list as an example:
The key message I believe you may be picking up from this post is that the more complex your value chain of suppliers becomes, the more necessary it is to have defined, repeatable processes to support them. In the end moving to Cloud Services is a form of strategic outsourcing and comes with all the challenges and benefits of what that means. Don’t make the classic mistake of believing that once you outsource something you no longer have to worry about it (You are still concerned that the floors get swept). The old model of outsourcing your problem’s does not work in this model either. By all means look strategically at integrating alternative suppliers into your IT value chain, just be aware of what that means. For more thoughts on integrating external suppliers successfully take a look t the article I wrote: Your IT Outsourcer - A Brother of Another Mother [Finale - Les Miserables] Do you hear the people sing Will you join in our crusade?
“Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.” ~Alan Perlis |
ITSM / ITIL Program Leadership Troy DuMoulin Thursday, November 19, 2009 Transformation Efforts are Always Most Successful When Led from Top DownHere we are in the middle of November with the US Thanksgiving just around the corner and I find myself thankful for a very busy 4th Quarter leading into the holiday season Content ↓ Transformation Efforts are Always Most Successful When Led from Top Down Here we are in the middle of November with the US Thanksgiving just around the corner and I find myself thankful for a very busy 4th Quarter leading into the holiday season. Over the last few weeks I have been meeting with the Senior Leadership teams of several of our customers across the continent who are all re-starting their ITIL projects or finally taking the first steps into the ITSM adventure. My observation it that the Senior Leadership responsible for an ITIL program really benefit from a 1 day working session with their peers where the people, process, technology and governance considerations are discussed and addressed. This type of kick of session serves to put everyone on the same page so to speak as well as provide the leadership with a vision of how to accomplish the Service Management program they are envisioning. The Agenda for this 1 day Executive Workshop typically looks like this: Learn about the IT Service Life cycle as well as the business drivers for service management and key trends that are impacting IT Service Organizations. This one day executive session focuses on what senior managers need to understand about the life cycle approach and how it links to business value generation and IT strategy. Workshop Agenda Strategic ITSM Overview
The IT Service Management Lifecycle
Process Governance & Organizational Considerations
Roadmap To Adopt ITIL
IT Management Tools & Process Automation
Facilitated Discussion About Next Steps In fact we believe so strongly in this workshop we are offering it at our annual conference in February as a pre-conference 1 day Executive Session: Link: https://www.pinkelephant.com/ITM10/Workshops/PreWorkshops.htm
While the past couple of months have indeed been busy I have had the opportunity to participate in a couple of interesting Multi Media sessions. Interview by Rob England (The IT Skeptic): Follow this link to listen to a recorded interview and for a preview of a conference session I am doing on “5 Tips For Developing An ITSM Strategic Road Map” Speaking of Rob England and keeping in tune with the Theme of this blog post I highly recommend Rob’s book “Owning ITIL: A Skeptical Guide for Decision Makers” which has specifically been written for those individuals who have been given an ITIL project to sponsor or run and are now wondering what they have gotten themselves into!
Well onward and upward my friends as we power though November and into December! Troy’s Thoughts What Are yours? If you want something done, ask a busy person to do it. The more things you do, the more you can do. ~Lucille Ball |
Situational ITSM Leadership Troy DuMoulin Sunday, October 25, 2009 One Size Fits All Is Not A Viable Strategy For Footwear or Leadership!A consistent observation one can make about human nature is that we tend to lean heavily on what we know works for us and avoid areas where we are less sure or comfortable. O Content ↓ One Size Fits All Is Not A Viable Strategy For Footwear or Leadership! A consistent observation one can make about human nature is that we tend to lean heavily on what we know works for us and avoid areas where we are less sure or comfortable. Of course there are those rare individuals that throw caution to the wind, damm the torpedoes and throw themselves at new challenges, methods and approaches without blinking an eye. However for most of us, our personalities, culture, environment and past experiences shape how we look at life and become the filter by which we make decisions and take on new tasks. Each of these elements contribute to and mold a person’s primary leadership style or at least the default way we try to influence the behaviours of others. The challenge with this concept is that our default leadership style while effective in certain circumstances will totally backfire in others and unless we recognize this challenge the project or opportunity you have been asked to take on will have a limited chance of success and you may not even realize why. This leadership challenge is the basis of Ken Blanchard’s model called “Situational Leadership” The premiss of Blanchard’s model is that at various points in a team’s evolution a different type of leadership approach is required. This article will provide an example of this model in light of an IT Service Management Transformation project. First lets start with a few Definitions from Situational Leadership:
Four Leadership Styles:
The ITSM Application: Ok now that we have the basic definitions out of the way let me share with you the model and how it applies to transformation projects and specifically ITSM initiatives. The Story: You have been asked to take on an ITSM Improvement Project and and been provided with a team of people to participate in the process design and tool configuration work. You have had an in-house training session (hopefully provided by Pink However, a few weeks head down in a conference room facing both passive and active resistance to changing anything let alone adopting this foreign concept of common process begins to take the shine off their naivety. They now begin to understand that there is a lot more that has to be done other than documenting processes and implementing tools. They now begin to see that what they have been assigned to is a transformation project targeting the heart of the current IT culture and accepted values and beliefs. What at first looked like an interesting project now looks almost impossible and they still don’t really know how to get it done. Your enthusiastic team now have become ”Disillusioned Learners” and start looking for ways to transfer out of their current tour of duty. When it becomes apparent that they are in this for the long haul they begin to roll up their sleeves and begin learning the trade of ITSM improvement projects. Some things they intuit, others they get outside help for and some things they learn the hard way by making mistakes and having to re-do it the right way. Slowly but surely the team begins to regain some of their initial enthusiasm as they see successes and their capability for certain tasks grow. However give them a new hurtle to cross which they have not seen before and they quickly revert to the previous stage. Your team has now become “Capable But Cautious and will veer up and down on the enthusiasm and capability scale depending what you have asked them to do and their percieved ability to achieve the specific task or responsibility. Eventually if you have been able to sustain the initiative and keep a hold of your team members you will have a battle weary but hardened set of process improvement veterans who have come out the other side of your ITIL project as survivors with many lessons learned and the scars to show for it. That being said they now are subject matter experts on the specific ITIL process you have adopted and have learned the skills required to navigate the transformation jungle. They in essence have become change agents and process advocates and can now be viewed as ”Self-Reliant Achievers” capable of being told to head in a certain direction and take that hill while leading others over the perilous terrain.
The key message of Situational Leadership is that you need to apply the right leadership style at each stage of your team evolution through each of these distinct development phases. Apply the wrong style at the wrong time at your peril if not the project’s likelihood of success. For example if you naturally have a delegation approach to leadership. “They are professionals and should be able to figure this out on their own” and you apply this to a team that is at a stage 1 or 2 then they will simply stand there looking at you with a lost look in their eyes. I knew a consultant like that once, the guy’s first meeting with a new client was to sit them in a circle and ask what they wanted out of a service catalog and how they though a service catalog should look and function. The results of that meeting let alone the project was to be expected. For a early development stages you need to be directive, giving clear directions and “A-B-C” steps for the team to move. At this point they don’t know what they don’t know. Once they hit stage 2 now you still need to directive but also need to turn up the empathy putting your arm around their shoulder as their counsellor and tell them that it really is possible to get there from here laying out clearly the step by step approach the task will be accomplished. Pointing at the other organizations that have overcome the challenges and been successful. (conferences and trade shows are great for this). Eventually they begin to gain individual capabilities and increased enthusiasm. At this point you need to be the sports coach operating from the side lines calling the general direction of the play but leaving the actual means to execute in the hands of your team members. They begin to charge off and getting things done even when not specifically directed to. That being said there will still be points where they hit new tasks and you will have to revert to a supportive model. Finally once they have each been through the first three stages and they are the hardened and grizzled veterans you can use the delegation model of leadership knowing that you just need to set the direction and your team will blaze the way forward while you focus on other areas. At this stage if you use directive leadership your team will be resentful of what they perceive as lack of trust or micro management. Try being supportive and they will think you condescending and overly concerned with the details.  The key point of this article is that while each of us will have a default leadership style that comes naturally to us based on our personalities and history we need to recognize the situation we are dealing with and learn to apply different styles at different times of our team’s evolution. Troy’s Thoughts What Are Yours? “A leader who confines his role to his people’s experience dooms himself to stagnation; a leader who outstrips his people’s experience runs the risk of not being understood.” |
The ITSM Grieving Process Troy DuMoulin Sunday, September 27, 2009 Change Is A Process With A Beginning A Middle And End and A New Beginning!The longer I work in the field of IT Service Management the more I understand that the single most important contributor towards the success of an ITIL project is the act Content ↓ Change Is A Process With A Beginning A Middle And End and A New Beginning! The longer I work in the field of IT Service Management the more I understand that the single most important contributor towards the success of an ITIL project is the act of facilitating and managing the necessary changes of belief, values and actions that are required to adopt ITSM principles. This is the 2nd in a series of 3 articles that focuses on the primary goal of transformation versus focusing on such things as documenting ITIL processes and configuring tools. (Both necessary enablers but not the goal itself). For more on this concept please read: Establishing Or Assessing an ITSM Program While the concept of Service versus Technology Management is the compass providing direction and the ITIL process framework is the map providing the journey context and detail we still need to motivate, fuel and move the people to begin and continue on the journey. You can invest in ITIL geography lessons (ITIL certification classes) and that helps to abate the anxiety of the unknown shores and shoals. You can even invest in printed process maps and transportation in the form of ITSM tools to get you to your destination faster and more efficiently.
Looking at change as a grieving process is not a new concept but one I would like to revisit with the readers of this blog. The following model comes from the research of Elizabeth Kubler-Ross and was originally developed to help understand the stages of grief people transition through as they cope with the loss of a family member or loved one. The interesting thing is that this same model can be applied directly to understanding the emotional state of the people you are guiding through the transformational change and who experience very real emotions of anger, loss, depression through to the eventual acceptance and integration of the change.  Understanding The Grieving Process and Its Application To ITSM Transformation Projects: Denial: When you first start your ITSM awareness activities many people don’t believe you are really serious and that what you are telling them about will “actually” ever happen. They have seen these quality programs come and go many times and very rarely have they actually amounted to much. They look at your ITIL project as just another set of acronyms that will come and go in time without changing their lives in any significant way. So the people you invite to your town hall meetings, lunch and learns, process design workshops nod and smile enjoy your pizza and eat your coffee and donuts without any real sign of outward aggravation assuming that your effort will drown under the organizational complexities and crash into the political boundaries. Anger: However this good will soon vanishes for many people when they realize that you are actually serious about the changes you are proposing and they see Senior Management commitment start moving beyond just standing up in a meeting to say they endorse this new idea. At this point many people who were initially positive go into self protection mode and show real anger at what they see as changes to their current existence, new levels of accountability and potential loss of power and prestige. It is at this stage of the grieving process you can expect people to demonstrate either very active or passive resistance hoping to kill the project under the weight of lethargy. Negotiation: Realizing that their direct attacks or indirect attempts to subvert the change are not working the people going through the process now begin to barter and negotiate a middle ground where they are able to maintain some level of the autonomy, influence, and their current ways of doing things. The cry “but we are different”, “I will do this one thing but I will never go that far!” They reengage with the change program but not because they are now supporters of the change but primarily to preserve some level of their current state believing it is better to be at the bargaining table rather than be left out of the negotiation process. DIP: The dip represents the person’s or organization’s acceptance of the change as inevitable, inescapable and as something to be stoically endured but hated. Don’t expect them to be happy about the change, they will often now attend you meetings grudgingly providing input and feedback but they largely resent the change as something they have no further power (at the moment) to avoid but are required to support. Exploring Possibilities: The time spent in the dip of depression will largely depend on how long it takes for the individuals and groups to begin realizing personal benefits from the change. At some point the hope is that the realization of the change will have a positive impact which is recognized by those going through the transformation which in turns begins to slowly turn the attitude from negative resentment into positive possibilities. The earlier these benefits are seen and experienced the better which of course is a strong argument to look for quick wins that can be put into place with speed before the full activities are of the change are completed. Integration: There comes a point in all transformations when the changes that have been put in place are no longer seen as new, nor are they seen as specifically positive or negative but simply as the way things are done. At this point the transformation will have become integrated into the daily lives, routines of the people and it will be hard to consider going back to a previous state. Consider that all new things that transform society go through this trend. At some point Microwaves and Digital Cameras are just part of the landscape and it becomes difficult and even silly to consider going back to processed film except for specialized applications. The world has simply moved on and is set for the next transformation and the next beginning. For those of us who have been through ITIL projects this curve is a familiar experience, one that takes time and to some degree re-starts for each new initiative undertaken based on the amount of change required. A key to successfully navigating this cycle of grief and acceptance is understanding it is normal, to be expected and planned for. Also consider that your style of leadership will need to change depending on where people are in the grieving process. Use the wrong messaging or leadership style at the wrong time and you could potentially pour gas on the fire and loose everything up in smoke. Ken Blanchard’s model of “Situational Leadership” provides wisdom for us all to apply during these times of change. My next post will describe Blanchard’s model and why and when to use the four styles of leadership (Directive, Supportive, Coaching, Delegation) during a transformation project
“To spare oneself from grief at all cost can be achieved only at the price of total detachment, which excludes the ability to experience happiness.” ~ Erich Fromm |
Cultural Roadmap For ITSM Adoption Troy DuMoulin Saturday, August 29, 2009 The Road To IT Service Management Has Several Cultural ShiftsA few months back I wrote an article called the “Incident, Problem, Change Dance” which has as its central premise the claim that while ITIL is now over 20 years old most organiza Content ↓ The Road To IT Service Management Has Several Cultural Shifts A few months back I wrote an article called the “Incident, Problem, Change Dance” which has as its central premise the claim that while ITIL is now over 20 years old most organizations have struggled to adopt Service Management best practices beyond a few of the operational and service transition processes. This article and screencast is focused on providing an explanation for this interesting fact and is based on an observation that demonstrates that there are significant cultural and governance shifts that must first occur before and organization is ready to successfully to adopt certain practices. For several years I have spoken and written about an ITIL adoption roadmap based on the logical sequencing of process and data dependancies. For those who are interested you can find some of my writings on this subject on a series of blog posts starting with: ITIL Implementation Roadmap. However, it is my personal experience and belief that logic alone is not adequate for establishing an ITIL roadmap. To fully develop an ITIL adoption strategy the cultural readiness of an organization must be taken into account. Also related to this understanding is the discussion of whether you believe IT needs to be “aligned” or “integrated” with the business organization. In the spirit of switching media formats from time to time I have prepared a short Screencast on my thoughts. Troy’s Thoughts What Are Yours
|
Establishing Or Assessing An ITSM Program Troy DuMoulin Tuesday, July 28, 2009 A Health Check For ITSM Program SuccessIT projects do not have a great track record of success. Various studies published by the Standish Group, KPMG or Robbins-Gioia all conclude that the likelihood of IT projects delivering on their promised Content ↓ A Health Check For ITSM Program Success IT projects do not have a great track record of success. Various studies published by the Standish Group, KPMG or Robbins-Gioia all conclude that the likelihood of IT projects delivering on their promised value proposition is no higher than 54%. At Pink Elephant our experience shows us that IT Service Management projects falter at even higher rates due to their high dependency on organizational and behavioral change and their tendency to be misunderstood, underestimated and under-managed. The tangible tasks of creating process documents, and configuring service management tools is the easy part and is not by the way the goal of a service management project. The primary risk to ITIL project success is the political and cultural ability to deploy the process and policy changes across the non-aligned, separately managed IT towers and technology silos that make up a typical IT organization. Without the ability to drive real change across these political and often external boundaries the project returns almost no value and the money spent on process design and tools is a wasted investment. To avoid this trend we need more than our best intentions. The following lessons learned from failed projects can help us open our minds to managing risks and planning to succeed rather than become yet another statistic
Many organizations that undertake programs to improve their IT Service Management processes and service delivery capabilities are frustrated by a general lack of results or the overriding failure to achieve their ambitious goals. Much of that frustration can be directly attributed to a single, pervading factor: Certainly these two elements are necessary and even critical but they are still only enablers - not the goal itself.
The goal of a Service Management initiative is to establish a common and efficient approach for the various functions within the internal and external IT value chain to deliver stable and reliable IT Services to the business customer. Process documentation and the underlying IT tools are simply a means to the end and not the end in and of themselves.  Building Blocks for ITSM Programs
The key to managing successful ITSM programs is understanding the building blocks to success! Troy’s Thoughts What Are Yours? “It is a mistake to think you can solve any major problems just with potatoes (tools and process documentation)” ~Douglas Adams with my artistic add |
)
