Skip to main content

Posts

The Best of Service Design, Part 4

ITIL 2011:  Design Coordination Originally Published on September 20, 2011 The Service Design stage of the ITIL Service Lifecycle can be a powerful and beneficial set of activities and undertakings if managed, guided and coordinated in a holistic and comprehensive manner. One of the more powerful processes to emerge with the publication of the ITIL 2011 addition is the Design Coordination process. Previous editions of ITIL had the reader and practitioner assume or extrapolate the guidance provided in the Design Coordination process. ITIL 2011 formalizes the guidance and shows the need to have a method of ensuring the smooth operation of all the moving parts of Service Design.   Design Coordination has several important objectives including (SD 2011 4.1.1): Ensure the consistent design of appropriate services, service management information systems, architectures, technology, processes, information and metrics to meet current and evolving business outcomes and requirements

The Best of Service Design, Part 3

The Importance of Availability Management Originally Published on July 5, 2011 The Availability Management process ensures that the availability of systems and services matches the evolving agreed needs of the business. The role of IT is now integral to the success of the business. The availability and reliability of IT services can directly influence customer satisfaction and the reputation of the business. The proactive activities of Availability Management involve the proactive planning, design and improvement of availability. These activities are principally involved within design and planning roles. The proactive activities consist of producing recommendations, plans and documents on design guidelines and criteria for new and changed services, and the continual improvement of service and the reduction of risk in existing services wherever it can be cost-justified. There are several guiding principles that should underpin the Availability Management process and its focus:

The Best of Service Design, Part 2

ITSM Requirement Gathering Techniques Originally Published February 20, 2010 In a previous discussion, we talked about the three levels of requirements in Service Design: Functional, Usability and Management and Operational. There is a range of techniques that can be used to actually obtain these services requirements. It is often difficult to get your customers to verbalize what they need. It has been my experience that the customers and the business are not completely sure of what their requirements actually are. They will need assistance and prompting from the designer or requirements gatherer. This must be done in a professional and sensitive manner to ensure that it is not seen as IT dictating the business requirement. We are all familiar with the most popular techniques, interviewing and workshops. The following is a list of additional techniques which might aid you in the Service Design requirements gathering stage: Observation: Watch your customers perform a spec

The Best of Service Design, Part 1

We continue our "Best of" blog series by  moving into Service Design. The Service Design Package Originally Published in 2010 I have gotten many questions about what value does the Service Design Package provide? We first must understand that all design activities are triggered by changes in business needs or service improvements. In order to design and deliver IT services that meet the changing needs of the customers and the business, clear, concise and unambiguous specifications of the requirements must be documented and agreed. The SDP is where we document and agree to Requirements – What the business wants and how they plan to use this new service. Define who all of the stakeholders are  Service Design – Functionality of this new or changed service (SOR). Service levels to be delivered (SLRs, SLAs). Operational management requirements (OLAs, Contracts). Overall design and topology. Defined outcomes and deliverables.  Organizational Readiness Assessment

The Best of Service Strategy, Part 5

ITIL 2011:  Business Relationship Management Originally Published on August 16, 2011 With the recent publication of the ITIL 2011 edition, several items within the best practice set have undergone a transformation. One of the goals of the 2011 edition is to bring even more consistency and standardization to the best practices by formally recognizing and organizing several ideas and activities that the 2007 edition had not previously structured as full, formal processes.  While always referenced in the 2007 edition (and ISO/IEC 20000), Business Relationship Management is now an official ITIL process The newly structured Business Relationship Management process now formalizes the activities and links between the customer or user and the service provider through a central contact point embodied in the Business Relationship Manager role. The ITIL 2011 edition states that the purposes of Business Relationship Management are twofold: To establish and maintain a business relatio

The Best of Service Strategy, Part 4

Cycles Originally Published December 4, 2012 As we move into the waning of the year in the northern hemisphere and the waxing of the year in the southern hemisphere, it becomes time to reflect on the meaning and understanding of the idea of cycles. The yearly cycle of seasons was long ago recognized by early mankind as playing a significant role in culture and society. Planting, growth, maturity and harvesting each set the day to day activities of peoples around the globe throughout a given year. This is no less true when it comes to the lifecycle of services and the lifecycle of Service Management. Both play a significant part in the culture and functioning of an organization. A cycle is defined as “any complete round or series of occurrences that repeats or is repeated.” This definition holds true for service management and IT services. When it comes to providing value through IT services and governing, controlling and managing those services, we do not exist in a “once and

The Best of Service Strategy, Part 3

The Fundamentals of Portfolio Management Originally Published June 14, 2011 IT must begin to align with drivers of business value other than just managing infrastructure and applications. In order for IT to organize its activities around business objectives, the organization must link to business processes and services, not just observe them. IT leadership must engage in a meaningful dialogue with line-of-business owners and communicate in terms of desired outcomes. We have to become a Business & Service oriented organization. The transition from managing infrastructure to managing services is a fundamental cultural shift for many organizations. Managing infrastructure requires a focus on component operational availability, while managing services centers on customers and business needs. In order for us to link service assets to business services we must first begin to develop a portfolio of services using the following work methods. Define: Begin by collecting informatio

The Best of Service Strategy, Part 2

Service Strategy's Four P's Originally Published on July 10, 2012 Whenever I am introducing ITIL and ITSM to a new group of students I always make sure that the concept of Strategy as a process is always discussed.   The reaction that I usually get from most is: “Strategy isn’t something the business does?”   I begin our discussion with a simple definition.   Service Strategy comprises the processes of: strategy management for IT services, service portfolio management, financial management for IT services, demand management and business relationship management.   In the world of ITSM, Service Strategy is the stage of the lifecycle were we align our IT strategy the with business strategy and define our perspective, position, plans and patterns that we as a service provider will have to execute in order to meet an organizations business outcomes.     These four elements must be present and help guide us in defining and documenting our overall IT strategy.     

The Best of Service Strategy, Part 1

I've been hearing a lot lately about "going back to the basics" of ITIL and IT Service Management.  So for the first half of 2013, I'm going to package and republish the best of my blogs for each lifecycle stage.  As always, I welcome your comments and questions!   ~~ ITSM Professor Utility and Warranty Equals Value Originally published October, 2012 When a service provider is developing a service for a customer or group of customers the underlying goal is to ensure that the service has value for the customers by meeting a set of defined requirements.    The value is often defined by what the customer is willing to pay for this service rather than what it actually cost the service provider to produce the service or any other essential feature of the service itself. Services themselves do not actually have intrinsic value.   That value is created by the outcome enabled by employing the service and therefore the value of the service is not determined by the provid

Change Evaluation

I often get asked where change evaluation takes place.   Isn’t it part of change management?   It is a separate process however it is driven by change management and is triggered by the receipt of a request for evaluation from Change Management. Inputs come from several processes including the SDP and SAC from Design Coordination, change proposal from SPM, RFCs, change records and detailed change documentation from Change Management.   It holds discussions with stakeholders through SLM and BRM, testing results from service validation and testing to ensure that its members have a full understanding of the impact of any issues identified and that the proper risk assessments can be carried out against the overall changes and in particular the predicted performance, intended affects, unintended affects and actual performance once the service change has been implemented.    The purpose of change evaluation is to provide a uniform and structured means of determining the performance of a c

Stability vs Responsiveness

In an earlier blog I spoke to the conflicts that all operational organizations face.   This struggle can be broken down into four general imbalances so that an IT organization can identify that they are experiencing an imbalance by leaning more towards one extreme or the other.   At a high level it can provide the service provider with the opportunity to develop some guidelines on how to resolve these conflicts and move towards a best practice approach in resolving discrepancies.   We talked to the first and most common which was the Internal IT view vs. the External Business view.   Today I would like to speak to the dilemma of Stability vs. Responsiveness. IT operations must ensure that the IT infrastructure is stable, performs at an agreed and defined levels on a consistent basis and is available with the correct amount of capacity to meet the demands of ever changing patterns of business activity. These changes can be evolutionary.   Needed changes in functionality, performance

Balance in Service Operation

In every organization the one constant is change.   In operation all functions, processes and related activities have been design to deliver specific level services.   These services deliver defined and agreed levels of utility and warranty and doing so while delivering an overall value to the business.   The catch is this has to be done in an ever changing environment where requirements, deliverables and perceived value changes over time.   Sometimes this change can be evolutionary or can take place at a very fast pace. This forms a conflict between maintaining the status quo and adapting to changes in the business and technological environments.   One of the key roles of service operation together with processes from the other stages of the life cycle is to deal with this tension between these ever changing priorities. This struggle can be broken down into four general imbalances so that an IT organization can identify that they are experiencing an imbalance by leaning more to

The Future of Communication

I recently had the chance to encounter a very telling situation about the modern world. A presenter was talking about how the college age generation (the future employees of IT and business) was moving away from what he called “old style web pages”. That is full web sites and pages overloaded with content and information that requires someone to commit time to actually “reading”. The preferred communication approach for the upcoming generations is rather the “text” or “tweet”—140 or so characters of information or knowledge spun into the universe as snippets of data, information, knowledge and wisdom. Older generations are capable of producing such ‘text bites” of knowledge, but generally see them as links or parts of a much bigger activity called a conversation. For the future those “texts” and “tweets” will be the whole conversation or story: beginning, middle and end in 140 characters or less. It brought to mind the importance of coupling existing knowledge management with new or

Service Vs. Project

A question arose recently concerning the relationship between Service Management and Project Management. This is a topic of interest to many people since on the surface both approaches seem to be fighting for some of the same work space in organizations. When we go back to the basic definitions of each we can see that the two are not in conflict, rather are very complementary. However, the relationship may not be as many people expect. I have found that the relationship is one of time: short term bursts of creation activities (outputs) inside a larger ongoing management lifecycle (outcomes). Let us start with the definition of service and service management (according to ITIL ® ): Service : A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks Service management (SM) : A set of specialized organizational capabilities for providing value to customers in the form of services.  Both of these de

Managing Knowledge

I recently had the opportunity to chat with a practitioner about the importance of knowledge management and had to smile when she declared that ‘knowledge management is back.’ The premise of the comment was that early attempts at knowledge management were unsuccessful as organizations seemed to think that the knowledge was going to ‘magically’ appear. Gartner speaks to the fact that organizations also often focused on collecting knowledge, rather than dispersing it. It has taken the IT industry a while to understand that there needs to be a strategy for knowledge management that culminates in the right information being delivered to the right place or person at the right time. Doing that successfully requires a process, methods, policies, procedures, tools, and metrics. Another consideration is the shifting of generations in the workforce. Think about it. How do young – or young at heart – people solve problems today? They Google or Tweet and draw upon the knowledge and exp

Pain Management

Picture this: A patient walks into the doctor’s office and says “doc, every time I raise my arm it hurts”.   Of course you know the punch line.     But can you see the analogy?      Fill in the blank:   Every time we _____, our customers/services/users hurt (how?)   To identify and improve pain areas, you must analyze the overall performance and capabilities of your services, processes, people, partners and underpinning technology.   Do you know how they support desired business outcomes and where they fall short?     The first step is to identify the “as-is” state in order to document current performance and justify the need for improvement.    Part of this step will involve determining what needs to be measured and who is going to collect, process, analyze and synthesize the data into useable information.   Key stakeholders will need to be identified and engaged in order to understand the intensity of their pain, the residual impact and their input into possible opportuniti

Unsourcing

I recently read a very interesting article in the June 2, 2012 Technology Quarterly edition of The Economist magazine.     There is a new trend in technical and customer support that relies heavily on the contributions from actual customers, “Unsourcing” involves the use of online communities to enable peer – to – peer support among users.   Instead of speaking to a paid internal or outsourced service desk analyst, customers post issues to a central forum and wait for answers from experienced users.     To create unsourced communities, companies are setting up discussion groups on their website or leveraging social networks like Facebook and Twitter.  As you can imagine, the savings can be considerable. Gartner estimates that user communities can reduce support costs by as much as 50%.   When Tom Tom, a maker of satellite navigation systems, switched to social support, members handled 20,000 cases in the first month , saving the firm around $150,000.   Best Buy has instituted an

Institutionalizing Continual Service Improvement

In this age of the global economy we repeatedly hear about how organizations must continually innovate and change to meet the challenges of global competition.   Does your organization have a plan of continual service improvement (CSI)?   Has the executive level defined how CSI will be part of the overall business strategy?   Is there alignment, from IT management?   How much time, resources and budget is being allocated towards improvement?   Is it a structured corporate program or an ad-hoc initiative with little direction and no defined benefit?  Institutionalizing CSI is one of the critical success factors for the 21 st century. A well-defined and managed strategy is necessary when confirming that all resources and capabilities of the organization are aligned to achieving business outcomes and that those investments are lined up with the organization's intended development and growth.   It also safeguards that all stakeholders are represented in deciding the appropria

Control Charts

In the 1920’s while working at ATT Bell labs, Dr Walter Shewhart (mentor of W Edwards Deming) sought a way to improve telephone transmission systems. Seeking to reduce variations and failures, on May 16, 1924 Dr Shewhart wrote an internal memo introducing the concept of the control chart [Wikipedia]. Today the control chart (AKA process quality control chart or Shewhart chart) has become the standard statistical tool for finding variation that lead to continual improvement. As with other continual improvement tools, the control chart can be understood in a short time, yet takes a lifetime to master as a truly powerful tool for statistical and incremental improvements. The control chart is a tool that tells us whether a process or system is in a state of statistical control. The state of statistical control is one in which a minimum or acceptable amount of variation is acceptable while still meeting the desired output of the process. Shewhart recognized that every process and sys

How Do You See ITIL?

As with most things, ITIL® can be viewed from multiple perspectives. I have found that many people seem to take a polarized view of the set of best practices. They either see ITIL® from a very literal, functional and operational focus or they see ITIL® from a more figurative, conceptual and strategic perspective. The interesting thing about ITIL® is that it is both of those things and everything in between all at the same time! After spending many years reading, thinking, teaching and using ITIL® I have found that one of its greatest benefits is its flexibility. The set of best practices can be seen from strategic, tactical and operational perspectives. In addition it is my firm belief that to be a true expert in the best practices one must be able to think at all three of those levels at the same! Because ITIL® takes a lifecycle approach (cradle to grave for the life of a service) it operates very strategically. Because ITIL® provides a set of processes for achieving value fo