IT Management Reference Guide

In this section I discuss how to initiate an effort to design a robust problem management process. This type of effort requires a number of key steps that need to be executed in the proper sequence. In order to get your process design off to a solid start, it is important to understand these preliminary steps thoroughly, and to implement them successfully. This section shows how to do this by describing the initial portion of this process design.

Key Steps to Developing a Problem Management Process

In Figure 1 I list the 11 key steps required to develop a robust problem management process. I will discuss the first of six of these steps in detail in this section. Part three of this series will discuss the final five steps and several other important aspects of problem management.

Figure 1 Key Steps To Developing a Problem Management Process

Step 1: Select an Executive Sponsor.

A comprehensive problem management process is comprised of individuals from an assortment of IT departments and of suppliers that are external to IT. An executive sponsor is needed to bring these various factions together and to ensure their support. The executive sponsor must also select the problem management process owner, address conflicts that the process owner cannot resolve, and provide executive leadership, direction, and support for the project.

For most of my clients, the sponsor was either the vice president of IT operations or the CIO. In a few instances the manager of client services was this sponsor, but employing higher level executives for this role seemed to work best.

Step 2: Assign a Process Owner.

One of the most important duties of the executive sponsor is to assign the appropriate process owner. The process owner will be responsible for assembling and leading a cross-functional process design team, for implementing the final process design and for the ongoing maintenance of the process. The selection of this individual is very key to the success of this project as this person must lead, organize, communicate, team-build, troubleshoot and delegate effectively.

The ability to promote teamwork and cooperation is extremely important due to the large number of level 2 support groups that become involved with problem resolution. This is also why the ability to work with diverse groups is necessary though not at as high a priority. Knowledge of desktops is key due to the overwhelming number of desktop calls. The ability to analyze metrics and trending reports ensures continual improvements to the quality of the process. Effectively communicating and meeting with users is essential to good customer feedback.

At some of the shops I worked, the service desk manager or his designate was the process owner. One of my clients had the change coordinator serve as the problem management process owner, and this worked surprisingly well. The integration of the two processes of problem and change management became very apparent and beneficial.

Step 3: Assemble a Cross-Functional Team.

A well-designed problem management process will involve the participation of several key groups. Mature, highly developed processes may have up to a dozen areas serving as second-level, tier–2, support. A representative from each of these areas, along with key user reps and tier 1 support, normally comprise such a team.

This team is responsible for identifying and prioritizing requirements, establishing the priority scheme, negotiating internal service level agreements, proposing internal process metrics and external service metrics, and finalizing the overall design of the call-handling process. The specific areas participating in this cross-functional process design team will vary from shop to shop but there are some common groups that are usually involved in this type of project. Figure 2 lists typical areas represented by such a team.

One should take care to ensure you have representatives on your team who are every supportive of your efforts. I have watched a few process design teams leads struggle to move forward when representatives with hidden political agendas undermine the team's efforts.

Figure 2 Areas Typically Represented on a Problem Management Process Design Team

Step 4: Identify and Prioritize Requirements.

Once the cross-functional team members have been identified and assembled, one of the team's first orders of business is to identify and prioritize requirements. Specific requirements and their relative priorities will depend on an organization's current focus and direction, but several common attributes are usually designed into a robust problem management process. It should be noted that this step does not yet involve the actual implementation of requirements, but focuses on acquiring the team's consensus as to a requirement's inclusion and priority.

A variety of brainstorming and prioritizing techniques are available to do this effectively. I discuss brainstorming in more detail and list helpful brainstorming ground rules in the section called "Utilizing Effective Planning Techniques."

Step 5: Establish a Priority Scheme.

A well-designed priority scheme is one of the most important aspects of an effective problem management process. Priority schemes vary from shop to shop as to specific criteria, but most all of them attempt to prioritize problems based on severity, impact urgency, and aging. Closely related to the priority scheme is an escalation plan that prescribes how to handle high-priority but difficult-to-resolve problems. Using an even number of levels prevents a tendency to average toward the central, and employing descriptive names rather than numbers is more user friendly. Table 1 is an example of a combined priority scheme and escalation plan from one of my former clients.

Table 1 Sample Priority and Escalation Scheme

Step 6: Identify Alternative Call-Tracking Tools.

The call-tracking tool is the cornerstone of an effective problem management process. Requirements for the tools will have already been identified and prioritized in step 4. Companies usually lean toward either having their tools custom developed or purchasing a commercially available application. I have seen several instances of both of these types of call-tracking tools, and each kind offers unique advantages and disadvantages.

Commercial packages generally offer more flexibility and integration possibilities while custom developed solutions normally cost less and can be more tailored to a particular environment. In either event alternative solutions should be identified for later evaluation.

In next week's final installment of this three-part series, I will present the last five steps of the 11 required for developing a world-class problem management process. Part Three will also include a discussion on process and service metrics, and a technique for assessing the quality of any organization's problem management process.

References

Walker, Gary, IT Problem Management, Prentice Hall, 2001

Schiesser, Rich, IT Systems Management, Prentice Hall, 2002