May 2010 Archives

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/ITSM 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

Reading through the articles on BSMReview.com, I started to wonder: "what is the problem?". Is IT really thàt disconnected from the business? Looking around in my living room and at the office, I can harldy imagine how life would be without any Information Technology to support me. And all of this is provided to me by companies in the form of products and/or services. Would I buy and/or use them if I didn't know what value they bring to me? No, of course not. Given that IT has penetrated already so much into my life, these "IT companies" must be connected to (or better say integrated within) "my business".

Interestingly some time ago I delivered an ITIL v3 based Service Portfolio Management workshop within a large Financial Institution. In preparing for this workshop we agreed to first focus on the question: "what is a service?". So I started by presenting the ITIL v3 definition of a service: "A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.". So far, so good. Then we looked at how to define a service and -more specifically- on how to define the business value of a service. Now when I asked the question "what is the busines value of your e-mail service?" the answer I got is "The e-mail service provides message traffic and storage of e-mail and e-calendaring". Does this describe a business value? Don't think so.

Looking at this sample, one might see it as a proof point that IT is really disconnected from the business and use it to justify a Business Service Management approach. Personally I wouldn't go that far. The only thing that it shows to me in this particular case is that IT is not able to articulate the business value of a service, but that doesn't mean the service doesn't have value or is not being used. On the contrary, the e-mail service sample above is one of the most used and appreciated service in the Financial Institute with an implicit value. Nevertheless and ultimately as one of the results of the workshop we came up with the following definition:

E-mail services provide value to the business when cooperative business communications are conducted without the constraints of location, device or time-zone. Value is created when IT operates for the business a store-and-forward messaging system, so that business employees can compose, send, store and receive e-mails with peers both inside as well as outside the business and in a manner that

  • Is accessible 24 x 7 x 365 across the globe
  • Allows only one outage of max. 5 min per 3 months
  • Enables messages up to 45Mb and mailboxes up to 100Mb
  • Supports protection of business confidential information
  • Ensures data availability and archiving within business policies

Similarly and on a bigger scale, I recently met with another customer (read: a service catalog manager within IT) who asked me to review his service catalog and provide feedback. Of course I accepted this and then found myself reading through a 193 pages thick service catalog printed on paper. When the guy returned after a few days and asked me for my opinion, I said: "Imagine that you are entering a restaurant and ask for a menu card. And when the waiter returns he delivers to you the cookbook of the chef. How would you feel?". He immediately got the point that the service catalog contained way too much information for their business customers. In addition I showed him that there was also information missing in the service catalog. And you probably have guessed this one already: it contained no descriptions of business value whatsoever.

Again also in this situation the reality was that all services in the catalog already existed and were actively being used by the business customers. So why then create a service catalog? Good question. In this particular case the main driver for producing a service catalog was IT's desire to explain what they deliver, however the business didn't ask for a service catalog and also was not involved in the creation. And like Bill Keyworth rightfully stated in The Why & What of Business Service Management: "BSM success is entirely dependent upon the willingness and skill of both IT and business to have an effective two way conversation ...one party without the other is doomed to failure.".

Reading through my samples above and several articles on BSMReview.com, I see a number of very specific issues and symptoms, but am still not sure what the main problem or need is for which we are trying to find a solution under the name of Business Service Management. When we define BSM as "the discipline that aligns the deliverables of IT to the enterprise's business goals" then I wonder what's the value in doing this? And isn't this already happening implicitly ? Is it really possible to define the package of whatever it takes to deliver the expected service to the business community ...in a way that they can understand and appreciate that delivery? To me this sounds a little bit similar like designing the perfect organizational structure, while we all know that this does not exist (otherwise everybody would have it by now...).

I realize that my statements are provocative, however I believe that a good understanding of and interactive discussion around the fundamental problem we are trying to solve should be the starting point for (m)any article(s) on BSM(Review.com). So let's first address the question: "Business Service Management: what's the problem?".

Looking forward to your comments.
bsm ibm


Richard L. Ptak, Bill Keyworth and Audrey Rasmussen believe that IBM's strategic focus on Integrated Service Management (ISM) and the application of IBM solutions under the Smarter Planet theme marks a milestone achievement in linking business and IT resources and assets for business success. Not the least because Integrated Service Management, in our opinion, leads directly to the broader message of how IT can effectively leverage and link together all enterprise assets and resources to achieve the goals of the business. ISM closely aligns with the Business Service Management (BSM) concepts that are being unnecessarily limited to discussions of just leveraging IT infrastructure. 

Learn how IBM illustrates and documents enterprise-wide benefits to be realized from BSM.  Read the article »

o1

"You Answer It; You Own It!"

A customer-focused service culture designed with the customer in mind will quickly benefit from the practice of Total Contact Ownership (TCO), where there is no ambiguity of ownership and direct accountability when it comes to the customer experience and ultimate satisfaction.

Read the article »

cloud 
migration

IT leaders must learn the necessity, value and process behind the development of a "Business Impact Statement" and the importance of crafting this statement in terms and metrics that are meaningful to the business community. Bob Multhaup & Ken Turbitt highlight its critical role in initiating business-oriented service management.

Read the article »

agileWhy would a business executive be interested in Agile software development? 

Why is Agile a topic of interest to the Business-oriented Service Management community? The answer involves strengthening the connection between the developer (...who provides software capabilities for business use) and the business entity (...who uses software technology for critical business functions.)  These two groups are frequently bridged (...successfully or unsuccessfully) by IT operations, adding complexity and increased business frustration to the BSM process of aligning business with IT (...both operations and development or DevOps.)

Read Bill Keyworth's book review >>

About this Archive

This page is an archive of entries from May 2010 listed from newest to oldest.

April 2010 is the previous archive.

June 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Pages