Implementing a Service Desk Application, Part 1

In this multi-part series on planning and implementing a Service Desk application, I start with identifying the characteristics of the tools.

Tool Characteristics

Service Desk applications usually support at a minimum the ITIL® V3 processes of Service Request Fulfillment and Incident Management, Problem Management, and Change Management. They frequently also support Release Management, Service Catalog Management, Service Asset and Configuration Management. They less frequently support Capacity Management, Availability Management, and/or Asset Management, but the tools may support integrations with other products in these areas.

In a nutshell, a Service Desk application is a mechanism for tracking tickets. I am sometimes asked what do Service Desk tools do that cannot be done in open source bug tracking applications Bugzilla. Without commenting specifically on Bugzilla or other products, Service Desks usually have a few requirements not supported by those tools. In general Service Desks require support for multiple processes, each with different fields, statuses, priorities, workflows, and approvals, and they require integration of ticket flows between those processes. For example, an Incident can initiate a Problem, which can initiate a Change. An Incident should be held Pending until the Change is complete.

Service Desk applications usually provide some capabilities to develop workflows. They are not true workflow engines, but provide lightweight workflow development capabilities consistent with the needs of Service Desks. Usually they provide configurable priorities and statuses. Often they provide configurable fields. They usually provide the capability of one or more drop-down dependency trees for categorizing the tickets. Usually there are workflow rules around, for example, how long tickets can spend in a particular status, and what should happen if that time period is exceeded. They usually provide approval workflows.

Service Desk applications also need to provide some reporting capabilities, which can come in a variety of manners. Some provide built-in reports. Some provide built-in capabilities for reporting configurations. Others provide templates with 3rd party tools, such as Crystal Reports or Microsoft SQL Server Reporting Service. The reporting may also include exporting of ticket information for consumption, manipulation or presentation in a tool like Microsoft Excel or Microsoft Access.

It is also important to have methods of interfacing the Service Desk application with other systems. In order to automate the population of customer information in the ticket, the Service Desk tool needs to import or input data from a corporate repository such as Active Directory or an HR database. Ideally this data will be imported dynamically or real-time at the time the ticket is created, but some tools will replicate the data into its own data store. The most common method is to interface with Active Directory via the LDAP protocol. Service Desk systems might also provide the capability of importing other data into the tickets, such as asset data from a 3rd party SQL database. Some tools allow dropdown or multiselect field choices to be imported from a data table. If the application includes a CMDB, then it should also provide methods to import or confederate data from multiple 3rd party data sources.
Some Service Desk systems use a “fat client” that is installed on the machine. The issue with this is having to install the fat client on every machine which will be used for the service desk and or its customers. Other Service Desk applications support user interactions via a web browser, so there is nothing to deploy on the clients. Others support a hybrid model, whereby limited or customer interfaces are provided via the web, while assignee and/or administration functions are provide via the fat client.

Most tools provide email interfaces in which agents or customers can create or update tickets via email, and updates to tickets can be sent to agents and/or customers via email. In addition many tools provide API’s and/or web services interfaces for programatic updates to tickets. Finally, most tools provide role-based access to the tool. For example, customers have fewer rights than agents of the tools. Depending on the role, some people can approve tickets at certain times, or others can enter certain information depending on the status, for example.

Next week I will outline some steps to prepare and plan for the selection of a tool.

Are Standard Changes “Good”

ITIL practitioners commonly assume that standard changes are good, and that a high percentage of standard changes vs. normal changes indicates a mature environment. Is this maturity “good” by definition with respect to Change Management? The answer is mostly yes, but not always.

Let’s look at some ITIL definitions. ITIL defines a change as:

The addition, modification, or removal of authorized, planned, or supported service or service component, and its associated documentation.

This definition in ITIL necessarily broad and not very actionable. Every company must define on their own what is and what is not a change. For example, one customer of mine defined their Change Management scope around the financial system necessary to achieve SOX compliance. They defined specific servers, workstations, and application by name in their Change Management policy. Although their definition was narrower than most companies’, it nevertheless worked for them.

The execution of an individual Change typically contains the following steps (in various orders):

  • Recording the Change, along with some basic information about it.
  • Reviewing the Change, including filtering out Changes that are useless, ill-conceived, or otherwise inappropriate.
  • Assess the Change, including analysis of risk, efforts, resources, and possibly more detailed feasibility analysis.
  • Authorize the Change
  • Implement the Change
  • Review the Change after implementation

The most important differences between normal and standard changes are in the assessment and implementation. ITIL defines a standard change as:

A change to service or infrastructure for which the approach is pre-authorized by Change Management that has an accepted and established procedure to provide a specific change requirement.

This definition is strong but incomplete. Standard changes are typically low risk, low impact, highly repeatable, well-documented, and well-understood. Standard changes are pre-authorized by the change board or relevant authorization parties.

Typically when an organization initiates a formal Change Management process, they will have few or no standard or pre-authorized changes. As they learn and grow, they will s identify some changes that occur frequently and are low risk and low impact, and further authorization of each individual change will burden the change board.

Such changes are candidates to become standard changes. Somebody, typically the person who implements these changes, can raise a change for the purpose of pre-authorizing a specific type of change. If authorized through the Change Management process, a new standard change is born. As a consultant I recommended these standard changes should become quick change templates in the ticketing system.

In general the longer an organization has been doing Change Management, the more standard changes it will have defined, and a higher percentage of all changes will be standard changes. This is a good thing, and in general the process of defining the the implementation plan (or change model) for standard changes helps to build repeatability and organizational learning and maturity.

Is a high percentage of standard changes ever a bad thing? In general no, unless the organization is so focused on measuring percentage of standard changes that technicians stop recording normal changes. This is bad, but rare in practice (at least for this purpose).

Standard changes can be difficult to achieve in organizations that are very dynamic or growing rapidly. In these environments it can be difficult to identify classes of normal changes that are candidates for pre-authorization. Growth consumes cash, and growth consumes resources. Highly dynamic environments may simply not have the people and time required to define standard changes, despite the benefits in more static organizations. Standard changes indicate operational efficiency, and not all organizations define their strategic competitive advantage around operational efficiency.

Not a Review: SCSM 2010

At heart I am a hands-on geek. When I learned that Microsoft finally released its Service Center Service Manager 2010, I was excited to try it. I logged into my partner account and signed up for the 90-day trial.

Then reality set in. As is so frequent with Microsoft’s business applications, initial enthusiasm gave way to confusion, then to despair. Let’s look at the requirements. Microsoft defines the minimum server roles:

Server 1: Service Manager management server + Service Manager database + Service Manager console

Server 2: Service Manager data warehouse server + Service Manager data warehouse databases

Nominally there is a SQL Server 2008 instance running on each server, but kindly Microsoft allows us to use a single instance:

Server 1: Service Manager management server + Service Manager database + Service Manager console

Server 2: Service Manager data warehouse server

The point is that SCSM doesn’t allow the data warehouse server to run together with the management server. Now let’s look at the hardware requirements:

Service Manager database Dual Quad-Core 2.66 GHz CPU
8 GB of RAM
80 GB of available disk space
RAID Level 1 or Level 10 drive*
Service Manager management server Dual Quad-Core 2.66 GHz CPU
8 GB of RAM
10 GB of available disk space
Service Manager console Dual-Core 2.0 GHz CPU
2 GB of RAM
10 GB of available disk space
Data warehouse management server Dual-Core 2.66 GHz CPU
8 GB of RAM
10 GB of available disk space
Data warehouse databases Dual Quad-core 2.66 GHz CPU
8 GB of RAM
400 GB of available disk space
Self-Service Portal Dual-core 2.66 GHz CPU
8 GB of RAM
10 GB of available disk space

These hardware requirements a far higher than many competitive products, but still modest for an enterprise. On top of that you also need a domain controller. For all this you achieve capabilities that are even more modest:

  • Up to 20,000 users with up to 40 – 50 IT analysts providing concurrent support.
  • Up to 20,000 supported computers, assuming up to 10 to 12 configuration items (installed software, software updates, and hardware components) per computer.
  • 5,000 incidents per week with 3 months of retention for a total of 60,000 incidents in the Service Manager database for the 20,000 computer configuration, and 2.5 times that for the 50,000 computer configuration
  • 1,000 change requests a week with 3 months of retention for a total 12,000 change requests in the Service Manager database for the 20,000 computer configuration, and 2.5 times that for 50,000 computer configuration

What perplexes me the most, in this day and age of Web 2.0, is Microsoft’s decision to use a “fat client” aka the Service Manager console.

To be fair, Microsoft is probably making serious attempts to use their product in-house (a strategy Microsoft calls “eating your own dog food”). In fact they made a video of one of these attempts. What I saw in the video was a CMDB with a little bit of ticketing and assignment routing strapped on the front end, and some customizations required for notifications. It was an honest video, but not impressive and certainly not an inspirational endorsement of a weak first release of the product.

At the very least I can say that SCSM 2010 is a solid attempt to sell other Microsoft products (Windows Server, SQL Server). Microsoft will probably get SCSM right sooner or later. They can always be counted on that, but only after they have exhausted all other possibilities.

W00t: The ITSM podcasts are back

I posted almost two years ago about the dearth of ITSM podcasts. The IT Skeptic blog is alive and well, but the podcasts are dead.

Fortunately a new batch of podcasts have arisen. Three that appear to be alive and well are:

I think the first organization needs no introduction: Connect, Learn, Grow! The itSMF USA Podcast

A second is the ITSM Weekly The Podcast From the folks at the ServiceSphere.

And last, but not least, the ITSM Manager: the IT Service Management Podcast, from ITSM Manager.

All are linked from the iTunes Store.

Changing Priority

Question: An Incident meets the criteria for P1. However, midway through resolution the impact has changed to that of P2. How should we treat the Incident now? How should we measure the SLA, based on P1 or P2?

Answer: I don’t believe ITIL provides much specific advice about this condition. How you want to handle this is really up to your organization and, more specifically, your Incident Policy.

In general organizations will prioritize Incidents based on the Impact (i.e. how many people or systems are affected) and Urgency (how long the organization can function with that service down or degraded).

Was the original assessment of Impact and Urgency incorrect? In this case you should change the prioritization.

Did the impact change because you applied a fix or workaround? In this case you should not change the prioritization.

Your SLA’s usually measures to full restoration. You could also measure to workaround provided. Your SLA’s won’t usually include fractional measurements based on changes to prioritization. For that matter, most organizations don’t even have formally agreed SLA’s with their customers.

Exploring the Role of Steering Committees in Realizing Value From Project Management

Abstract: The impact of steering committees on project performance and their role in creating value from project management capabilities is not well understood. A case study analysis was chosen to analyze the configurations and specific functions of project steering committees. A measurement model for steering committee configurations was developed to enable further survey-based studies. One of the major insights resulting from the authors’ interviews with project managers and senior managers was that they perceived the existence of a project steering committee only when the context was defined and clarified. Furthermore, a large variety of committee involvements was identified, concluding that steering committees per se are very rare. On the project level, the cases clearly demonstrate that committees with project steering functions play an important role in the selection, initiation, definition, and control of projects. On the organizational level, they are important to implement and maintain project management standards. Finally, the results clearly indicate that steering committees directly support project success and are instrumental for attaining value from an organization’s investments in its project management system.

Reference: Project Management Journal, Vol. 40, No. 1, 42-54.

Authors: Thomas G. Lechler, Stevens Institute of Technology; Martin Cohen, Stevens Institute of Technology

Link: http://www3.interscience.wiley.com/journal/122217097/abstract

Comments: My first reaction was: I wonder what relevance this research has to Change Advisory Boards in a Change Management process. However, beyond the superficiality they are not very similar. Projects, and hence project steering committees, are more strategic. Project steering committees consist mostly of executive management; the CAB may consist of representatives of management, users, partners, and vendors among others.

What surprised me the most of the research is how little research has been performed this area. Lechler and Cohen sought to address the questions of project steering committees: 1) what are the various configurations and responsibilities, 2) which project decisions are made, 3) how are they organizations, and 4) do they increase project management value? In order to do this they examined four companies in depth, as part of a larger PMI-sponsored study.

They found wide variety in steering committee composition, which is consistent with my observations of CABs in organizations implementing Change Management. In general they found steering committees are perceived to improve project management performance with minimal detrimental elements, such as political infighting or delayed decision-making. I wonder what would have resulted from the study of project-oriented organizations that lack the element of a structured steering committee–would they perceive lack of a steering committee hinders project management success?

What is the dividing line between a Project and a Change?

When is a Change really a Project? ITIL simply says the following are not changes:

  • Changes with significantly wider impacts than service changes, e.g. departmental organization, policies and business operations – these changes would produce RFCs to generate consequential service changes
  • Changes at an operational level such as repair to printers or other routine service components.

It isn’t clear to me that the natural agency—PMI—offers any clear guidance. PMBOK defines a project as a temporary endeavor undertaken to create a unique product, service, or result. Temporary endeavor implies a definite beginning and end.  Unfortunately, this definition is not inconsistent with a Change.

PMBOK offers little guidance about how big or how little a project needs to be in order to become a “Project” except to say the PMO exists to support project managers including developing a methodology, best practices, and standards. I would say a project is a “Project” when the benefits of managing it as a “Project” outweigh the overheads of the PM method. Hence the answer is organizationally dependent. If the organization’s PM methods are non-existent, then you can call anything a “Project” and send it off the secretary masquerading as a PM.

If the PMO’s PM method is detailed and rigorous, then projects would be greater than 80 hours at a minimum. However, in order to avoid the tendency of middle managers to “break up” projects in order to avoid PMO oversight, PMO’s will generally make the PM method scalable, requiring less overhead and oversight for smaller projects and more for larger projects.

In general time alone is a poor indicator for defining the boundaries of a project. A PMO should also look at factors such as strategic alignment, whether the Change supports or endangers the company’s strategy, and the project’s risk profile. Riskier projects should be overseen by the PMO in order to ensure the risk profile is in line with its support of the strategy.

In most organizations the PMO is more strategic and is independent of the IT operational processes. The Change Manager may hear about projects a few days before they are expected to go live (as a Change). In other words, the Project usually precedes the Change, not the other way.