ITSM Professor

Monitor Control Loops

2012-02-07T09:54:00.000-05:00

One of the lesser utilized yet powerful ideas in ITIL is the concept of systems or feedback loops. ITIL defines a system as

A group of interacting, interrelated or interdependent components that form a unified whole, operating together for a common purpose.

There are two types of systems:

· Open-loop systems – value of outcome has no influence on input; performs a specific activity regardless of environmental conditions

· Closed-loop systems – value of outcome influences input; responds to changes in the environment

Using these concepts we can establish a powerful approach for managing and improving the ITIL processes we have implemented. One technique is called the Monitor-Control Loop. The loop consists of a set of steps that produces feedback to help improve individual process steps, the process as a whole, the stages of the lifecycle and the lifecycle as a whole.

· Begin the loop by conducting an individual process step by taking inputs and creating outputs. While conducting the step monitor the activity and the output. Monitoring involves observing the activity and gathering data about the step or output.

· Compare the data against an established norm. The norm will come from the targets established in the Service Level Agreements and in the Critical Success Factors (CSF) and Key Performance Indicators (KPI) determined for the process.

· Control the process by making improvements or changes to the way you conduct the activity or step based on the variance or difference from the norm.

· Continue to monitor-compare-control for the next step of the process.

You can then apply the monitor-compare-control steps to the process as a whole by monitoring the final output of the process, comparing against more tactical and strategic norms established through your service catalog and portfolio and controlling the process by making overall improvements to the process. The loop can then be expanded to monitor-compare-control the lifecycle stages and the whole lifecycle.

Monitor-Control Loops provide a simple and effective way of ensuring that your processes are delivering on the promises you make to customers and users in terms of value.

Service Design Package (SDP) and the Service Catalog

2012-01-31T13:29:00.000-05:00

Both the Service Design Package (SDP) and the Service Catalog are produced in the service design stage of the service lifecycle and to some extent both drive the activities that happen in all subsequent stages of the service lifecycle. The SDP will detail all aspects of a service and its requirements throughout the entire lifecycle. A service design package is produced for all new services, major changes to an existing service or the removal of a retired service.

From a high level the service design package will contain the following:

· Business requirements

· Service applicability requirements (how/where used)

· Service contracts

· Service functional requirements

· Service and operational management requirements

· Service design and topology (including service definition and model

· Organizational readiness assessment

· Service Program (timescales and phasing of transition, operation and improvement of the new service)

· Service transition plan (overall transition strategy, objectives, policy and risk assessment).

· Service operational acceptance plan (overall operational strategy, objectives, policy and risk assessment).

· Service acceptance criteria (acceptance criteria for the progression through each stage of the lifecycle)

The service catalog provides a single source of information for all operational (live) services, services that are about to go live and are currently being prepared for deployment to the live environment. Your service catalog can initially start as a simple matrix, table or spreadsheet. As you grow your ITSM processes in maturity, your catalogs sophistication can grow along with them. Many organizations will integrate their service portfolio and their service catalog and maintain them as part of the Configuration Management System (CMS).

The service catalog can be produced with two distinct views available. You can have the business/customer view which relates IT services to business units and processes. This view represents what your customers will see. The second view is the technical/supporting service view. This relates IT services to supporting services and to the underlying components that underpin the delivery of the IT services and business functions. This includes items that will not be viewed by the customer. Both will enable proactive service level management and quicker more effective incident and change impact analysis.

Some critical success factors (CSF) that should be accomplished by the service catalog and service catalog management could be to produce an accurate and up to date catalog. This should lead to a greater awareness of the services being provided to the business and should also enhance the IT staffs ability to support these services and their related underlying technology more efficiently and effectively.

CSI and the 7 Step Improvement Process

2012-01-24T13:15:00.000-05:00

I would like to revisit the 7 step improvement process from the perspective of CSI, since there has been a slight (logical) modification to it. The concept of measurement, what we measure, gathering the data , processing it into understandable formats and then being able to analyze it, is fundamental in our ability to perform (CSI) Continual Service Improvement as an overall vision and in support of the business need and the underpinning of tactical and operational goals.

1. Identify the strategy for improvement: (Plan) Talk to the business, to your customers and to IT management. Utilize your service catalog and the associated service level requirements to define a starting point. The question “What is important to the business?” must be answered. Look to the corporate vision, mission, goals and objectives. Identify the IT vision, mission, goals and objectives. Are these properly aligned? Tie in the Critical Success Factors. Are these being met? Is value creation happening? (Wisdom)

2. Define what you will measure: (Plan) This directly relates to the organizations strategic, tactical and operational goals. It is in this step where we actually define what can be measured. If a gap exists between what can be measured and what we need to measure, then a gap analysis must be completed and then finalize an actual measurement plan. CSI can identify opportunities for improvement. (Data)

3. Gather the data: (Do) Data can be gathered from multiple sources. Quality is the key objective of gathering the data for CSI. The emphasis is not on assuring real time performance (that is an operational perspective) but on identifying where improvements can be made to existing levels of service, or IT performance. (Data)

4. Process the data: (Act) Data is processed in alignment with Critical Success Factors (CSF) and Key Performance Indicators (KPI). If necessary we can align this data all the way up to the vision. The goal here is to process the raw data into an understandable format that can be rationalized and made consistent. We begin to create information. After this we can begin to analyze the information and begin to make the essential comparisons. (Information)

5. Analyze the data: (Check) In this step the information begins to be transformed into meaningful knowledge of the events that are impacting the organization. We can begin to define any trends that may be happening within our environment. We can also determine if these trends are positive or negative. It is important that we ensure that proper analysis takes place, to support our future recommendations before we present this data to the business. (Knowledge)

6. Present and use the information: (Check) At this point we present and use the information in whatever way is necessary for the target audience. It is imperative that you understand your audience and the purpose for which the report is being given. The purpose and the value being created must be properly articulated. This will prevent the gap that often happens between what IT reports and what is of interest to the business. This will underpin our recommendations and assist the business in defining the next steps. (Knowledge)

7. Implement improvements: (Act) Here the knowledge gained is used. We can optimize, improve and corrects services and processes. The issues have been identified and solutions can now be applied. Since each stage of the lifecycle has limited resources it is also here where we prioritize which improvements can actually be implemented. Once done, new baselines can be established and the process can begin again.

The Value of Business Relationship Management

2012-01-17T13:15:00.000-05:00

One of the key processes in the ISO/IEC 20000 standard is Business Relationship Management. This process “establishes and maintains a good relationship between the service provider and the customer based on understanding the customer and their business drivers.”

Business Relationship Management (BRM) within ISO/IEC 20000 is one of the Relationship Processes (along with Supplier Management). These processes help to establish the links in what Harvard Professor Michael Porter described as the “value chain”. BRM creates the link between the service provider (including IT, but full delivery may involve other organizational functions) and the customers and users, both internal (“the business”) or external (“the end customer”).

Business Relationship Management is now a formalized process in newest (2011) edition of ITIL. With the newest edition, the authors recognized the importance of having BRM as an extent process, rather than as guidance embedded in other ITIL processes (such as Service Portfolio, Strategy Management and Service Level Management). The formalization of BRM now paints a complete picture of the service lifecycle, one that has slowly emerged since the earliest days of best practice guidance in the form of ITIL.

I sometimes encounter people who had begun their journey with V2 guidance, yet had only been exposed through formal training to the two core books of Service Delivery and Service Support. This narrow exposure gave them a limited perspective of the service lifecycle that had always existed (albeit in a disjointed and disconnected way). Unfortunately, many people did not know about or read the other books in the V2 library. However, best practice guidance had been put forth in V2 as to the importance of engaging the customer and understanding their needs. The last of the V2 books to be published, titled The Business Perspective, focused on this vital idea. In ITIL V3 (2007 edition), the authors brought this idea into the mainstream service lifecycle, yet had not made it a formal process. BRM has now taken its rightful place in the canon of processes in ITIL 2011.

I am very glad to see the full vision of the service lifecycle emerge. BRM is a fundamental process that helps a service begin its own journey to delivering value to customers and users. Although one could (and many have) begun their service delivery journey from IT outward, BRM provides an often misunderstood or forgotten view or perspective from the customer towards the service provider. Following the standards laid forth in ISO/IEC 20000, an organization can begin to build an even stronger linkage to those stakeholders who benefit most from efficient, effective and economical services delivered by service providers.

Drivers for the Various CSI Orders or Levels

2012-01-10T13:15:00.000-05:00

In a previous blog we discussed the revised 7 step improvement process. Step 6 of that process is to present and use the information. There are various levels of management in an organization. When presenting this information and implementing improvements it is important to understand which level to focus on and have a good understanding of the perspectives of each level and what their drivers are. This will enable us to derive the maximum value and benefit out of the information delivered.

First order drivers: At the highest level of the organization are the strategic thinkers. The reports delivered at this level need to be short, quick to read and deliver precise data about risk avoidance, protecting the image or brand of the organization, profitability and cost savings. These are the drivers that will support your reasons for improvement efforts.

Second order drivers: The second level of management is occupied by vice presidents and directors. Here, reports can be more detailed and must summarize findings over time. Defined is how the processes delivered support and underpin the business objectives and enable the organization to react early and quickly to issues that put the business at risk. They will also illustrate how these processes are aligned to our existing measurement frameworks which enable us to define the health of the business from the perspective of the IT organization.

Third order drivers: This third level of management is made up of managers and high level supervisors. At this level reports and measurements need to demonstrate compliance to stated objectives and overall team and process performance. They should provide insight into resource constraints and continual improvement initiatives.

Fourth order drivers: At this level are the team leaders and staff members. Reports must emphasize personal benefits. Metrics must define individual performances, provide recognition of skills and identify training and career growth opportunities.

Knowledge Management - the "why"

2011-12-20T13:15:00.000-05:00

When I teach, I like to talk about knowledge and wisdom and the value that they bring to the organizational table. A lot of the time people give me a quizzical look, Knowledge? Wisdom? Where is this conversation going? I ask people how they capture the knowledge or do they even capture the knowledge that is gained when they develop a new service, application or when some new technology is introduced into their live environment.

Although what we deliver can sometimes be intangible (availability, capacity, security) it is very complex and can take years to build up the know-how on how to deliver these elements and continually meet the changing needs of our customers. However you need knowledge, born from experience, to solve problems, to always improve, to use your wisdom to answer the question of why should we make one choice over another?

Like any other organization we must brand the product we deliver. This brand will then garner a reputation; the reputation will be built on the knowledge that is gathered from the designers, engineers and support staff. Knowledge must be stored, protected and shared to create a culture of quality among the staff of your organization.

Many people think you can deliver this quality by compartmentalizing the different components in the delivery chain, siloing the different processes and technologies. Continual service improvement isn’t about putting a bunch of smart people in a room and designing some new infrastructure or service. It requires skills that are difficult to attain. It’s about people being immersed in the day to day activities of the entire organization and utilizing and sharing the knowledge that is developed by these processes and functions. In some future discussions we will talk about the methods and best practices on how to we can capture and share our knowledge to continually meet our customers changing needs.

Knowledge Management - the "what"

2011-12-13T13:15:00.000-05:00

George Santayana, the Spanish American philosopher, wrote the famous saying, “Those who cannot remember the past are condemned to repeat it.”

This really is the underlying basis for the process of knowledge management. It plays a key role in CSI but data must be captured in each of the service lifecycle stages. This Data capture must then be processed into Information, synthesize the information into Knowledge and applied to the context of the environment we are supporting to create Wisdom. This is known as the Data-to-information-to-Knowledge-to-Wisdom structure. DIKW. Wisdom (not repeating the past) will allow us to make more informed & better decisions around improvements in our processes, functions and services. The purpose of knowledge management process is to quantify all of this D-I-K-W and then to share perspectives, ideas, experiences and information at the right time in the right place with the right people to enable informed decisions efficiently by not having to rediscover this valuable knowledge.

Let's review the four elements of DIKW:

Data: Is a set of discrete facts about the CIs that we have within our environments. This data is captured in highly structured databases such as “Service asset and Configuration management systems. These advanced systems allow us to create relationships between these CIs and the discrete facts are captured as attributes of these CIs. This allows us to identify the relevant data and accurately capture it. We can then analyze and synthesize this data into information.

Information: We create information by putting the data into some context as it relates to our environment. This information is typically stored in things like emails, records, documents and multimedia. We do this so that it can be easy to capture, query, find, re-use and learn from. I like to think of the information as somewhat static. It’s the state of a CI at a particular moment in time. We can then trend these different moments in time to garner knowledge about the lifecycle of a CI or group of CIs.

Knowledge: Knowledge is gained from the analysis of information. This is then combined with peoples own experiences, insights and expertise to create new knowledge. Knowledge is dynamic and context based.

Wisdom: Wisdom is the ability to make use of our combined knowledge to create value through correct and well informed decisions. (Back to that not repeating the past thing).

In our next blog, we will explore "why" Knowledge Management is critical to successful service management.

Should Service Requests be Included in First Call Resolution metrics?

2011-12-06T13:07:00.000-05:00

I recently had a question regarding the inclusion of Service Requests into metrics for First Call Resolution. As always, the answer is “it depends”!

ITIL now treats Service Requests and Incidents as two different processes – Service Request Fulfillment and Incident Management. Both are generally logged into the same tool and owned by the Service Desk. They are also measured by their own key performance indicators and metrics. ITIL does not consider first call resolution as a process metric - it is more of a service desk performance measurement.

First call resolution historically helps measure the handling of incidents by the Service Desk. The definition of an incident is usually pretty clear. However, since the definition of a service request can vary greatly from organization to organization, the value of including requests in incident metrics may also vary.

If your definition of a service request includes pre-authorization and funding, then the Service Desk’s ability to fulfill the request during the first call likely falls into the same percentage as incidents. However, if service requests may require an additional layer of management approval or the service desk does not have the skills and authority to fulfill the requests, then it is unfair to hold them to a first call resolution metric that is unachievable. What do you consider to be the “first call”?

I would also consider your assignment of urgency, impact and priority when deciding whether to include service requests in your statistics. Are you using the same standard for determining the priority of service requests and incidents? Should an analyst spend more call time fulfilling a service request in order to meet the target while a user with a potentially higher priority incident is in queue?

HDI’s recently published results of its Support Center Practice survey, including some statistics about first call resolution. While most respondents targeted over 70% first call resolution, only about 40% actually achieved that goal. Given that, I would recommend reviewing all of the criteria used for this important measurement.

Financial Management and SACM KPIs

2011-11-29T13:00:00.000-05:00

A learner who is working towards developing a Cost Management department recently asked about key performance indicators (KPIs) for the Financial Management and Service Asset and Configuration Management (SACM) processes.

ITIL 2011 actually maps Critical Success Factors (CSFs) to KPIs for each process. Key performance indicators for Financial Management can be found in section 4.3.8 of the Service Strategy book while those for SACM can be found in section 4.3.8 of the Service Transition book.

While I cannot list all of the KPIs for both processes, here is a good sample:

Financial Management

The financial management for IT services framework specifies how services will be accounted for, and regular reports are submitted and used as a basis for measuring the service provider’s performance.
All strategies have a comprehensive analysis of investment and returns, conducted with information from financial management for IT services.
Internal service providers receive the funding required to provide the agreed services – showing a break-even at the end of the financial planning period.
Customer and service assets are recorded in the configuration management system, and all required financial information is complete.
Regular reports are produced on the costs and utilization of customer and service assets and action plans are targeted for any deviations from required performance or utilization.
The cost of each service is reported on a monthly, quarterly and/or annual basis, and compared with the return achieved by that service
The service provider uses an accounting system, and this is configured to report on its costs by service.
Regular reports are provided on the costs of services in design, transition and operation.
Improved accuracy in budgets and charges for the assets utilized by each customer or business unit
Increase in re-use and redistribution of under-utilized resources and assets
Reduction in the use of unauthorized hardware and software
Reduction in the average time and cost of diagnosing and resolving incidents and problems
Improved ratio of used licences against paid-for licences
Improvement in time to identify poor-performing and poor-quality assets
Reduction in risks due to early identification of unauthorized change
Increased quality and accuracy of configuration information

Service Asset and Configuration Management

Improved accuracy in budgets and charges for the assets utilized by each customer or business unit
Increase in re-use and redistribution of under-utilized resources and assets
Reduction in the use of unauthorized hardware and software
Reduction in the average time and cost of diagnosing and resolving incidents and problems
Improved ratio of used licences against paid-for licences
Improvement in time to identify poor-performing and poor-quality assets
Reduction in risks due to early identification of unauthorized change
Increased quality and accuracy of configuration information

What are IT Services So Hard to Define? (Part 2)

2011-11-15T13:15:00.000-05:00

In my last blog, I provided some suggestions for overcoming challenges in obtaining agreement on the scope and definition of IT Services. As I mentioned, the Service Catalog is one of the first and most important assets in any service management program.

Today we are going to take a high level look at mapping IT Services to business processes. The first step is to understand what your business or customer does and how it does it.

In truth, every business only has five primary focus areas - regardless of whether it is public, private, governmental, non-profit, small or large. Consider this:

Every business designs, develops or acquires products and/or services
Every business communicates, markets and sells those products or services
Every business delivers those products or services
Every business supports its products or services
Every business has to have a corporate infrastructure (HR, IT, Finance, etc.)

Can you identify where these activities are performed within your organization?

Starting at the highest level of your enterprise, create a running list of possible outcomes that are needed to fulfill each of these critical focus areas. For each outcome, identify the associated end-to-end IT service or services. For organizations with multiple lines of business, you may want to repeat this exercise until you reach an acceptable, agreeable and manageable level of service definition.

The key to this exercise is to not perform it in isolation. Try to take a 360 degree view of services and outcomes. Engage stakeholders at all levels from IT and the business. An interesting by-product will be an improved dialogue between IT and its customers and users.

My final piece of advice is to start simple and stay simple. A service catalog does not need to be very complex; it needs to be very clear.

Why are IT Services So Hard to Define? (Part 1)

2011-11-08T13:15:00.000-05:00

A Service Catalog is one of the first assets that an organization should build when initiating their Service Management program. After all, how can you manage services if you do not have a clear understanding what services your IT organization provides?

Unfortunately, many organizations struggle with obtaining agreement on the scope and definition of end-to-end, business enabling services. If left unchecked, these struggles can turn political and widen the divide between IT and the business as well as cause conflict between internal IT units.

To avoid some of the potential challenges in service definition exercises, here are some helpful suggestions:

Set the stage by providing IT staff with a chart of business processes and begin integrating business vocabulary into service parameters ("Order Processing" not "Ecommerce"). Have business stakeholders conduct "lunch and learn" presentations that educate IT on how each unit uses IT Services. Start your service definitions with a business outcome and work the technology backwards ("Claims" instead of "XYZ application")
Stop equating applications with services - one service is likely going to be built upon multiple applications. This is a big culture change and requires constant reinforcement.
Watch for political minefields that imply that an application, individual or team is less important if not designated an official "service". Just because the network may not independently qualify as a business service, it is still critical to the delivery of other services.
Avoid making definitions too technical or so business centric that business and/or IT staff can't relate to or envision the service.
Speak in terms of value to the business ("What value does this service provide? What business process does it enable? How does it affect the bottom line?"). Avoid discussing the underlying technical infrastructure with customers.

These are all good first steps to creating a common understanding of outcome-based service.

Leadership Lessons from Fusion 2011

2011-11-01T13:15:00.000-04:00

Having recently attended the Fusion 11 conference in Washington DC, I came away with some key insights that I thought I would pass along. The event brought together the worlds of IT Service Management and Help Desk in a great mix of information sharing and learning through breakout sessions and emotion and motivation in the form of five fantastic keynotes.

One of the sessions I attended talked about being a leader in an ever globalizing world. The presenter shared her knowledge and wisdom of how to build a framework of leadership by embracing diversity and different cultures. A couple key takeaways:

“I’m different, like you”: Understand that we all have different cultures, backgrounds, knowledge and experience that make us important and unique individuals. Embrace the differences and use them to your advantage. It is our differences that make us similar as people trying to be successful in a complex and technology filled world.
“Help me understand”: Keep an open mind and spirit of learning to better grasp why someone struggles to connect with an idea or concept. Do not simply assume that someone is not capable of understanding or communicating. Place the responsibility on yourself rather than others, to make sense of a situation by working with the other person or group. Avoid forcing them to see things your way.
Create a Wisdom Journal: Keep a notebook of the important things you hear, see, experience and feel throughout your day as a leader. This was a practice of Leonardo da Vinci and one of the reasons he was such a greater thinker. He did not let ideas slip away. He reflected on what he captured (incubation) and turned those nuggets of knowledge and wisdom into works of genius (innovation).

Being a leader takes work, especially in the world of technology. There are many brilliant minds working to make life better for all of us. But we must keep in mind:

“If we think we are leading and no one is following, we are just going for a walk.”

Dr. Deming's Cycle

2011-10-25T13:15:00.000-04:00

Many of you have probably heard of Dr. William Edwards Deming. But how many of you really know who he was and why he is so important to IT Service Management and ITIL? I mean going beyond the contribution of the Plan-Do-Check-Act cycle to Continual Service Improvement? What was the most important contribution of Dr Deming and why should we care so much about his other efforts?

According to Wikipedia, Dr. Deming (1900-1993) was a statistician, professor and consultant by trade, hailing originally from Iowa. He went on to earn degrees from the Universities of Wyoming and Colorado, and a Ph.D. from Yale University. One interesting fact of which most people are not aware was his relationship to Walter Shewhart, the originator of the ideas of statistical process control. In fact the Plan-Do-Check-Act cycle was originally an idea generated by Shewhart (and is sometimes referred to as the Shewhart Cycle, rather than the Deming Cycle). We must remember though, Dr. Deming’s contributions go much further than just the PDCA Cycle.

It was the combination of Shewhart’s work and Deming’s practical applications of the ideas that helped to serve as the foundation of quality management. Most importantly was his contribution to the understanding of “systems”. As quoted on Wikipedia, “Dr. W. Edwards Deming taught that by adopting appropriate principles of management, organizations can increase quality and simultaneously reduce costs (by reducing waste, rework, staff attrition and litigation while increasing customer loyalty). The key is to practice continual improvement and think of manufacturing [or delivery of services] as a system, not as bits and pieces."
It is the concept of a “system” that makes the most contribution to ITSM and ITIL. Dr. Deming (and later experts like Peter Senge, author of The Fifth Discipline) showed how important it is to view not just individual processes, procedures, and work instructions. We must begin to see ITIL and ITSM as a holistic system.
A system is “a set of interacting or interdependent entities forming an integrated whole.” Systems have parts or components (as in ITIL processes) yet these parts or components work together as a whole. Dr. Deming applied these ideas beyond just statistics into what he called “The System of Profound Knowledge.” This System consisted of four parts:

Appreciation of a system: understanding the overall processes involving suppliers, producers, and customers (or recipients) of goods and services (explained below);
Knowledge of variation: the range and causes of variation in quality, and use of statistical sampling in measurements;
Theory of knowledge: the concepts explaining knowledge and the limits of what can be known
Knowledge of psychology: concepts of human nature.

One of the ideas I bring to my own classes is the need to see ITIL not as a collection of processes, rather as a single system of interconnected and interrelated parts. Once the learners understand the idea of “ITIL as a system”, they have a much easier time understanding how each of the processes works.
So we should give thanks to Dr. Deming not just for Plan-Do-Check-Act, but also for his emphasis on “systems” and how they drive quality.

The Beginning of Good Process Implementation

2011-10-18T13:15:00.000-04:00

Many organizations that I meet with often are struggling to implement best practice processes into their environments. They sound completely overwhelmed and often I hear “Where do we begin?” I smile and usually respond with “At the beginning of course”. The beginning of good process implementation of course is “defining and analyzing your customer’s requirements”. I once read that to provide good services a service provider must have good customers. I think this statement also holds true for processes as well. Good customers / employees must:

Understand the process
Understand the expected results of the process
Know where they fit into the process
Understand how they and others contribute to produce the expected results

When your employees understand the processes within your environment they can easily identify new customer requirements and positively respond to rapidly changing customer needs. This is the basis for making it part of the service culture within your organization, ensuring that business and customer requirements are always driving process enhancements.

The first step is to understand when change is necessary and then gather customer requirements for the changing business needs. This can take place through several mechanisms. It can happen in one on one conversation or through town hall type meetings. Some organizations have analysts who manage the relationship between the business and IT and meet with customers regularly to discuss these needs. Some industry standard techniques that can be utilized are:

Surveying customers
Conducting needs assessments
Creating and agreeing on Service Level Agreements (SLAs)
Benchmarking

Customer surveys are a defined set of questions that help IT to understand the how our customers perceive the services being delivered. We want to define what they see as weakness as well as the strengths of the services and if their needs are being met. Is the service enhancing their ability to do their jobs? Value creation! These surveys can then be used to identify opportunities to create process improvements.

Next we can do a deeper dive by conducting a needs assessment. This can take several forms and, used in conjunction with our surveys, can lead to in depth and complete needs assessment. By trending data received from our surveys we can then focus further with direct interviews, documentation review and analysis and physical reviews such as formal tours or demonstrations.

Through the use of Service Level Agreements (SLAs) IT and the customer can define and agree on the level of utility and warranty that will be delivered by IT to guarantee that the customers current and future agreed needs are being met. The service provider must also ensure that the underpinning agreements (contracts, OLAs) are aligned to the SLAs.

We may also want to do some benchmarking. This is the process of comparing your organizations practices and performance metrics to industry best practices and industry standard metrics. This can allow you to identify practices and processes in place at other organizations that can be utilized for improvements in your own organization.

Once all of this data has been gathered you can then begin to categorize the data and prioritize your opportunities and options for improvements. Requirements generally fall into four distinct categories:

People
Process
Technology
Information

From all of these activities a formal Requirements Definition document can be created to define a roadmap for your organizations journey forward.

Resources for Business Relationship Management

2011-10-11T13:15:00.000-04:00

A student recently asked for resource references for about Business Relationship Management (BRM).

BRM is emerging as a critical process in several prominent service management frameworks and standards. Recently, BRM was formalized in the 2011 edition of Service Strategy as part of the core ITIL library. This is a significant addition since many believed that BRM and Service Level Management (SLM) were the same process. While similar, BRM strategically focuses on the relationship between a service provider and it’s customer (more like an Account Executive) where SLM operationally focuses on the negotiation and achievement of service performance.

The ISO/IEC 20000 standard has mandatory requirements and suggested guidance for Business Relationship Management. Even if your organization is not considering ISO certification, the standard does define the minimum essential activities for each process, including BRM. Put together with ITIL 2011, it’s a powerful combination.

Microsoft Operations Framework (MOF) has a similar process/service management function called “Business/IT Alignment” in the Plan Phase that is worth reviewing. In addition to process descriptions, MOF provides task-based questions for ensuring that complete information is gathered as well as job aids. MOF is available for free through www.microsoft.com/mof.

The Purpose and Value of Business Impact Analysis

2011-10-04T13:15:00.001-04:00

When discussing Service Design I am often asked the purpose and value of a Business Impact Assessment (BIA). The purpose of a BIA is to quantify the impact to the business that the loss of a service would have. It is a valuable source of input when trying to ascertain the business needs, impacts and risks that the organization may face in the delivery of services. The Business Impact Assessment is an essential element of the overall business continuity process. It identifies the most important services to the organization and therefore will help to define the overall strategy for risk reduction and disaster recovery. At a more granular level these assessments enable the mapping of critical service applications and technology components to critical business processes. It is an invaluable input for Continuity Strategy, Availability Design, and Capacity Management.

The BIA’s strategic purpose is to show which parts of the business will be most affected by a major incident and what affect it will have on the company as a whole. The form these damages or losses may come in are:

Loss of income
Additional costs
Damaged reputation
Loss of goodwill
Loss of competitive advantage
Breach of law, health or safety
Immediate and long term loss of market share
Political, corporate or personal embarrassment
Loss of operational capability

As part of the design phase of a new or changed service the BIA should be conducted to help enable a greater understanding about the function and importance of a service. This will allow the organization to define:

Acceptable levels and times of a service outage. How the degree of damage is likely to escalate after a service disruption, and the times of day, week, month or year when a disruption will inflict the greatest damage.
The staffing, skills, facilities and services necessary to enable critical and essential business processes to continue to operate at minimum acceptable levels.
The time within which all required business processes and supporting staff, facilities and services should be fully recovered.
The cost the loss of a service has to the business. This is critical for Financial Management.

Additionally, it has been shown that the BIA can be a useful input to a number of other areas across ITSM and the business and would give a far greater understanding of the service then would otherwise be the case.

ITIL 2011: Design Coordination

2011-09-20T13:15:00.002-04:00

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
Coordinate all design activities across projects, changes, suppliers and support teams, and manage schedules, resources and conflicts where required

Oftentimes when we work very closely to a specific operational activity we can get tunnel vision towards the both the effort and results of our activities. The Design Coordination process allows us to take a virtual “step” backwards and to see the bigger picture of needing to coordinate many parts, pieces and players into a final deliverable in the form of a comprehensive and effective Service Design Package.

The Design Coordination process also provides a method of instilling governance and rigor to our effort to create the best possible design of the IT services we provide to the business and customers. Some aspects of the rigor and governance that the Design Coordination process can bring include (SD 2011 4.1.2):

Assisting and supporting each project or other change through all the service design activities and processes
Maintaining policies, guidelines, standards, budgets, models, resources and capabilities for service design activities and processes
Planning and forecasting the resources needed for the future demand for service design activities
Ensuring that all requirements are appropriately addressed in service designs, particularly utility and warranty requirements

An important factor to keep in mind is that the Design Coordination process does not do the actual detailed design of either the individual service solutions or any work outside the scope of the Service Design phase. Those activities are best left to the specific Service Design processes or other stages of the lifecycle. Design Coordination (as the name implies) works to make sure all those individual processes work together in a seamless flow to produce effective designs that later stages can transition to production.

Design Coordination is also one of several points of integration and connection to a formal project methodology. Before a project undertakes the formal creation of deliverables, Design Coordination provides guidance on aligning the deliverables of the project to the requirements and needs of the business and customers in terms of IT services. Design Coordination provides guidance on the resources and process activities available to the project to validate that the project has what it needs to be successful.

The Design Coordination process is a breath of fresh air for those looking to construct a means of keep everyone pointed towards the same goal of effective and successful IT service designs. Take a look at the guidance provided in ITIL 2011 to bring the greatest benefits possible during Service Design.

ITIL 2011: Strategy Management

2011-09-13T13:15:00.000-04:00

The publication of ITIL 2011 has brought several new or revamped processes to light. One of those is the Strategy Management for IT Services process. This Strategy process is not actually new. It represents the formalization of best practice guidance for managing strategies contained in earlier editions of the ITIL publications.

The purpose of this newly minted process is to use a company’s perspective, position, plans and patterns to ensure better management, governance and control of the IT services an organization provides to support the business outcomes. The basic principles of the Strategy Management process include helping to identify the overall business strategy and then tie an underpinning IT strategy (including an IT service strategy) or manufacturing strategy to the business outcomes through integration and alignment activities.

Once an IT strategy emerges in relation to the business strategy, the organization can then decompose the IT strategy into IT tactics and IT operations. These lower, more detailed levels of decisions and activities then exist in parallel to the business tactics and operations.

The key takeaway from the Strategy Management process should be a recognition that the IT policies, plans, projects, processes, procedures and work instructions do not exist or get created in a vacuum, independent from the business strategy, tactics, or operations. IT is wholly dependent upon the business for its existence. The work of IT (and the delivery of IT backed services) occurs at the request of the business and on behalf of the business. IT does not and should not exist for the sake of existing.

ITIL does provide a cautionary note when attempting to undertake Strategy Management for the first time, especially when no overall strategy exists or there is no linkage from IT to the business. An organization can quickly become “…inundated with data and information, before they can produce anything that can be signed off by senior management” (SS 2011 4.1.4.1)

When undertaking this important, yet potentially overwhelming process, an organization should ensure involvement by the right stakeholders and to seek “…incremental progress to get an organization up to the point of addressing service strategy in the comprehensive manner described…” (SS 2011 4.1.4.1)

Taking a properly scoped and steady, yet measured pace to Strategy Management can produce great benefit for an organization. Perhaps the biggest challenge will be an organization’s willingness to undertake a process-driven approach to developing strategies that help to meet the business outcomes and the needs of both internal and external customers.

Are you willing?

Major Incidents and Problem Records

2011-09-06T13:15:00.000-04:00

The other day someone asked me if a Problem Record should be opened for all Major Incidents.

Not necessarily – the goal of a Major Incident is still to restore service when a major event occurs that has significant impact on the business. Incident Management is not necessarily looking for a permanent solution but for some level of regained productivity.

If viable and necessary, raising a Problem Record will engage the necessary resources to find the root cause (if not already known) and find a permanent solution to remove the error (if one is available). However, sometimes the root cause of a Major Incident is immediately known and a permanent solution not viable at the time.

Here is a practical example – we have hurricanes in Florida that can cause massive power outages. We know the root cause and the permanent solution is to repair the power lines. This will likely take some time. Do we need a Problem Record to capture that information? Maybe, if there is a need to document the repair of the power lines separate from the implementation of workarounds such as generators and other temporary solutions. Maybe not, if there are other ways of time-stamping the workflow associated with the repair. In this case, it is not the need to identify the root cause that would generate the Problem Record - it would be the need to manage the known error and, ultimately, the permanent solution.

Reasoning for Problem Management

2011-08-30T13:15:00.000-04:00

When it comes to Problem Management two things should come to mind: Root Cause Analysis (RCA) and finding a permanent resolution. How often have you thought about what it takes to conduct these aspects of Problem Management? An important underlying aspect of conducting a Root Cause Analysis and finding the permanent resolution are the reasoning approaches used.

Three types of basic reasoning approaches are:

Inductive: Reasoning from specific examples to general rules
Deductive: Reasoning from general rules to specific examples
Abductive: Reasoning to the most likely answer

Each has its own uses and can be applied to problem solving and Problem Management at different times and for different reasons. However, when performing the Problem Management process we should be open to using all three reasoning approaches. They all complement each other with Inductive and Deductive reasoning forming two ends of a spectrum while Abductive thought looks for the balance between the other two approaches.

Let's take a look at some ways we can use these reasoning methods to help us with Problem Management.

Using an Inductive approach we should begin by looking at specific Event or Incident data. Turn this data into information by sorting and categorizing it into meaningful groups. You can do this by looking for commonalities or trends among the data or facts. Once you have grouped the data into information, ask yourself: “What is this information trying to tell me?” By answering this question you will produce knowledge which will lead to identifying root cause or help to identify a proper permanent resolution.

Using the Deductive approach we would begin by establishing a general set of characteristics against which we will then compare data or facts to see if it matches. This allows us to begin with knowledge and decompose (deduce) it into information and then into data or facts. Then ask yourself the question “Do these facts, data and examples still fit the rule?” Once we have specific examples that fit our general rules or criteria we can then turn again to Induction for validation!

Using an Abductive approach would allow us to start with the data, information, knowledge and most important, wisdom, at hand. From our personal and professional experiences we can draw conclusions that would help us eliminate unlikely causes or ineffective fixes and thus save ourselves from going down dead ends of problem solving. Ask the question “Are the proposed root causes or fix recommendations likely, plausible or even possible?” We must be careful with abductive thought because we can often throw out what might in the end turn out to be an unlikely but actual root cause or identified fix.

When attempting to perform the Problem Management process we should see these reasoning methods as three parts of a triangle that should be used altogether and in an iterative fashion. Look at your problem from multiple sides and use different tools and approaches to understand the problem. This varied approach will allow for more effective and efficient efforts at Problem Management!

Incident vs Problem

2011-08-23T13:15:00.000-04:00

In a recent conversation I was asked about the difference between an Incident and a Problem.

This is one of the most often confused points in all of IT Service Management and ITIL. Part of the confusion comes from the fact that both words are used (at least in the English language) to express similar ideas. Each reference some kind of issue occurring that potentially could lead to human action. However, in ITIL words are more clearly defined and have particular contexts for usage.

Incident: Any unplanned event that causes, or may cause, a disruption or interruption to service delivery or quality

Problem: The cause of one or more incidents, events, alerts or situations

While Incidents have to do with disruption of delivery or quality, problems have to do with causes. From these distinct definitions we can see that not every incident would result in a problem, and not every problem even needs to be related to an incident. Keep in mind that “Incidents never grow up to be Problems.” The difficulty arises when we want a nice quantitative way of determining when to begin the Problem Management process. We look for some formula, algorithm, quantity or structure that acts as a clear objective indicator to begin the Problem Management process. Unfortunately this may not be the right approach to take.

What figures into when we should use a problem has to do with our desire to find the root cause of an occurrence. The trigger for starting the problem process, or even for determining if you have a problem, is the basic question of “Why?” Anytime anyone asks the question “why?” you have moved into the Problem Management process. The question could be generated from one incident, one event, a series or trend of incidents or events, a major incident, or even no incidents or events. The last situation results in proactive Problem Management. A desire to investigate our current delivery and quality capabilities may lead someone to ask “why?” and begin the process of determining root cause and a permanent fix.

Problem Management is much more subjective and qualitative in its nature than Incident Management, which is more objective and quantifiable. This is what leads to the confusion between the two. They should be seen as two sides of the same coin or two ends of a spectrum. They are complements to each other and should be done in parallel based on the need to understand situations from both an objective (Incident) and subjective (Problem) perspective.

ITIL 2011: Business Relationship Management

2011-08-16T13:15:00.003-04:00

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 relationship between the service provider and the customer based on understanding the customer and their business needs
To identify customer needs and ensure that the service provider is able to meet these needs as business needs change over time and between circumstances. Business Relationship Management ensures the service provider understands these changing needs.

The key to making full use of this valuable process is to see that it focuses on the needs of the customer and the business. The service provider (whether that is IT alone or in conjunction with other internal business functions) needs to have a means of staying in touch and in tune with the entities (the customer and the business). The Business Relationship Management process serves in this capacity. This touchpoint also provides a way of anchoring the service provider to the customer and creating full business-IT alignment and integration so that everyone in the organization focuses on the same outcomes and objectives.

Rather than leave the activities of the Business Relationship Management process up to chance, ITIL 2011 identifies that we can and should manage all activities undertaken as formally documented and mature processes. For Business Relationship Management these include two key activities:

Being the voice of the service provider to the customer
Being the voice of the customer to the service provider

As the key role in the process, the Business Relationship Manager serves as this voice through ongoing communications and interaction with representatives from the customer and the service provider. Business Relationship Manager could also easily combine with the Service Level Manager role to create a seamless conduit from customer to service provider capabilities used to ensure value.

The Business Relationship Management process is a simple yet powerful tool to ensure value to the customer and the business. Now that the process has a formal structure, it should provide even more benefit to your organization as you work to increase quality and customer satisfaction.

The Service Design Package (SDP)

2011-08-09T13:15:00.001-04:00

I was recently asked by one of my followers if I might have an example of a Service Design Package (SDP).

When seeking to implement ITSM and ITIL, we often seek to find examples and models we can use to give us more guidance. This is no less true of the SDP. Unfortunately when we try to seek out specific examples of a SDP it can often be difficult, if not near impossible. So why is it hard to find actual examples of a SDP? It goes to the very nature of the guidance of what we call best practices. ITIL is not prescriptive as to what should go into a SDP or what one might look like. It provides best practice guidance on the types of items contained, but not the exact look and feel of the content. Therefore each SDP will be unique to the organization that creates it. The organization, type of content, what the content says, and how it is managed are all decisions made by each organization to meet the needs of their customers and users. Just like a Service Catalog or a set of Service Level Agreements are unique, the SDP may not mean anything to someone outside the organization that is providing that service and has that particular group of customers or users. It may also contain proprietary or confidential information.

At a minimum the SDP should address the Five Aspects of Design: the services, tool, architecture, metrics and processes needed to deliver value to the business or end users. For some organizations this might be a long list of items, for others a few diagrams, lists, or tables of data and information. The SDP is a formal collection of information that moves with the service as it proceeds through its lifecycle, rather than being an odd collection of randomly associated documents. The key to a successful SDP is that it contains all the information needed by the Service Transition processes to build, test, configure, release and deploy the services and their underpinning components.

Quick Wins

2011-08-02T13:15:00.002-04:00

Not too long ago we discussed John Kotter’s Eight Steps towards Leading Organizational Change. The sixth step outlined the necessity of establishing Quick Wins. As IT Service Management professionals we need to show upper management service improvements within a short time frame. We also need to get our IT staff on board with the ITIL program and what better way than showing benefits quickly. I have outlined 10 quick wins, some are for those who are just starting their service improvement journey, and some are for those at a higher maturity level.

To help illustrate this, we are going to try something new. The ITSM Professor would like to solicit your opinions and success stories on Quick Wins and IT Service Management improvements. We may publish your stories in upcoming blogs on topics such as

Recording every Incident and Service Request
Defining models for your frequently occurring Incidents
Starting to create a Standard Change library
Producing trending reports of Incidents and Service Requests
Performing Trend Analysis on most frequently occurring Incidents
Identifying a Pain Point / Issues meeting with your business stakeholders
Following up on the issues meeting periodically to revise priorities
Establishing a regularly scheduled CAB meeting
Training the Service Desk to answer the phone professionally
Communicating, marketing, advertising, and communicating your ITSM program

Again, we would love to hear from you. Share with us your success stories, your service improvements, even some of your failures. We can learn much from our peers! Thank you in advance for your participation.

Is ITIL Best Practice or Good Practice?

2011-07-26T13:15:00.005-04:00

By definition, ITIL is a set of best practices (refer to glossary and section 1.2.3 of any of the books) It is also considered a "source" of good practice. While this may be confusing, it is important to understand the distinction.

There are many sources of good practice but not all of those sources are validated as "best" practice. While the term is loosely used, best practices should be repeatedly proven to demonstrate tangible value in actual organizations. In fact, today's documented best practice could be tomorrow's good or common practice. That's how service management evolves, improves and becomes institutionalized. Building a service management program can also involve other sources of good practice (i.e., other frameworks, standards, and proprietary knowledge).

ITIL makes it clear that it's best-practice guidelines are not intended to be prescriptive. Each organization is unique and must 'adapt and adopt' the guidance. This will involve taking into account the organization's size, skills/resources, culture, funding, priorities and existing ITSM maturity. The guidance can then be modified as appropriate to suit the organization's needs. I do not know of an organization that has adopted "pure" ITIL best practices. The end result will be a set of practices that are "good" for the organization given its level of maturity.