Although difficult jobs to perform, the job descriptions of the professional footballer, the nun, the solicitor and the teacher can all be defined through one-on-one experience with those professionals, through what one observes on the television, in the courtroom or in the classroom. These roles are visible to many. The job descriptions for each of these professionals, given by observers, may be incomplete, but are not, necessarily, incorrect.
Incident managers, however, are not seen by masses and their job description is difficult to explain. To individuals outside of an IT department the role of incident managers are unlikely to be understood as a profession, in terms of the tasks that need to be performed, or as an IT profession. Simply, the incident manager‘s role is to restore normal service operation as quickly as possible and minimise the adverse impact of the unplanned outage on business operations (Cartlidge et al., 2007). The role of incident manager is one of only a few roles in the IT subspecialty referred to as Service Support. In large organisations, Service Support is one of five process segments (see Figure 2-4), each of which has accountability to perform some function(s) that allow optimal performance in the IT production environment.
Figure 2-4. Service Design and Service Management Processes (Orr, 2008, p. 11)
The Service Design and Management Processes, the Release Processes, the Control Processes and the Supplier Processes are components of Service Support, but are not within the scope of this research. Service Design and Management Processes are those activities performed that result in the collection and documentation of business requirements, the design and development of solutions to meet the aforementioned requirements, the
Control Processes
working with all other required parties to ensure what is required and what is designed align to meet not only IT requirements but business requirements, the production and maintenance of all required documentation, and the associated activities to ensure requirements identified can be met and achieved. Release Processes are those activities performed to ensure that new and changed services deliver significant business value by delivering changes at optimised speed, minimised risk, and effective cost, while offering consistent and appropriate implementation of those changes. Control Processes are actions taken to identify, control and account for assets of the IT environment, ensuring integrity of that environment. Supplier Management is performed to ensure that a business is receiving value for the money it spends for all work performed from IT suppliers and that the contracts established to perform the work are aligned with the needs of the business (Cartlidge et al., 2007).
The set of work performed by incident managers within the Resolution Processes is key to the successful and continuous running of an IT environment (Ritchie, 2008). The primary goal of incident managers is to improve the quality of service provided to the IT customers by returning lost service to the users in as short a time as possible, with as minimal a business impact as possible. It is the restoration of service when unplanned outages occur that is the Resolution Process for which incident managers are accountable.
Though both incident management and problem management are components of the Resolution Processes, an important distinction is made between what each of those functions is designed to do and the tasks executed by individuals performing them. The objective of incident management is to restore service as quickly as possible when an unplanned outage occurs. Alternately, the objective of problem management is to diagnose the root causes of incidents and to provide workarounds or permanent fixes. While an incident is active until the service is restored, a problem is active until appropriate changes are implemented (Anonymous, 2005). If, for example, a computer server fails daily at 00:01, its service can be restored by restarting the server and using it until 00:01 the next morning, when it is known that it will fail. Incident managers are tasked with ensuring the server is available when it is needed; the action required to ensure its availability may include knowing that it will need to be restarted after it fails, again, at 00:01. Making the lost service available is the job of the incident manager. This is known as restoring service. Problem managers, however, are responsible to determine why the server fails at 00:01 each morning and to take actions to ensure it stops failing and continues to work without interruption. When the problem manager has identified and deployed a permanent fix that stops the daily failure of the service, the service has been restored permanently. This is known as resolving the problem.
Incident managers provide the greatest value to the organisations they support by having a business focus to ensure the optimization of resources; it should be viewed as a discipline to bring value to the organisation that uses it, rather than as a firefighting exercise (Holden &
Thomson, 2006). To achieve this, an incident manager must help technical support teams and corporate managers work together to restore service. Alternatives must be found and selected for use, sequentially if not in parallel, in the expectation that one alternative will restore service. To determine what alternatives are viable, the asking of questions is important.
A study was performed by means of engaging business executives (N = 18) on a one-hour telephone call, asking open-ended questions, and speaking individually and confidentially to each of the respondents (Armenakis, Harris, Cole, Fillmer & Self, 2007).
Through the use of this telephone survey, the researchers found that the data collected were responses to broad questions and that the responses were nondirective. However, other studies indicate that the asking of questions can provide insightful information into a problem trying to be solved, when the questions asked were not broad, but were binary. In a case study on the responses from a single patient in a medically diagnosed vegetative state due to a car accident, research was done on brain wave performance. The subject studied was asked only binary questions in order to monitor the brain waves when responses were given from the non-verbal medical patient. The patient thinking about tennis conveyed the value of yes; the patient thinking about a house conveyed the value of no. Each of these thoughts (tennis and house) result in stimulating different areas of the brain, allowing researchers to ensure they clearly understood if the answers they were receiving were yes or no, since the brain imaging used reported activity in one part of the brain when tennis was imagined (yes) and another part of the brain a house was imagined (no). The results indicate that clear communication can occur even when verbal skills are diminished (Singer, 2007). Applying the findings from this research to incident managers, one concludes that incident managers benefit from obtaining information available from responses to binary questions, allowing all parties engaged in the restoration of service to determine in what areas each party needs further detail without detaining those engaged, en masse. The use of binary questions by incident managers offers a simple tool to determine the general technology area that is experiencing the problem that caused the unplanned outage and work to restore service.
There are two important factors to remember. The first is that the participants in the restoration of service from unplanned outages are rarely non-verbal and the second is that the incident manager must control the conversations in order to expedite the restoration of service.
A simple example of trying to find information is having an individual remove a card from a deck of playing cards. For ease of understanding, assume the deck has 52 cards and
there are no jokers. The person who does not know which card has been chosen can ask, card-by-card, if a specific card has been drawn from the deck. This use of binary questions will, in fact, result in the eventual identification of the selected card. Table 2-4 shows the number of questions that need to be asked to determine which card is drawn. It is obvious that luck will result in a short exercise if, using a card-by-card approach, the person determining the identity of the drawn card intercepts the selected card prior to asking 51 times ―Is it the . . . ?‖ Alternately, by eliminating groups of cards, one question at a time, the person determining the identity of the drawn card eliminates blocks of cards as questions are asked and answered. Using binary questions that reveal more valuable information than a
―yes‖ or ―no‖ allows the identity of the selected card to be obtained by asking seven questions instead of 52 questions. Indeed, if time is a measurement of performance and it is considered of greater benefit when the duration of time is short, either set of binary questions will identify the selected card; however, the wise selection of binary questions can expedite its identification.
Table 2-4. The Ace of Diamonds Can be Identified Quickly The Ace of Diamonds Can be Identified Quickly
Question When binary is yes or no When binary is x or y 1 Is it the king of hearts? Is it a red card or a black card? (red) 2 Is it the queen of hearts? Is it a heart or a diamond? (diamond) 3 Is it the jack of hearts? Is it a face card or a number card?
(number)
4 Is it the ten of hearts? Is the value of card an odd number or an even number? (odd)
5 Is it the nine of hearts? Is the value of the card greater than four? (no)
6 Is it the eight of hearts? Is it the three of diamonds? (no) 7 Is it the seven of hearts. . . ? It is the ace of diamonds.
14 Is it the king of spades . . .?
26 Is it the king of clubs . . , ? 39 Is it the king of diamonds . . . ? 52 It the ace of diamonds.
When an incident manager uses binary questions from groups of options for why it is that an unplanned outage has occurred, the likelihood of restoring the lost service increases because the worst-case scenario of selecting one avenue of exploration after another avenue is removed and groups of unlikely options are eliminated en masse from investigation.
It is reported that incident management is all about urgency (Cartlidge et al., 2007).
Technical support teams must restore service urgently. Good incident managers live on adrenalin, quick wits, among other skills, combined with resourcefulness (Waschke, 2006).
Key skills of incident managers were identified as the ability to build relationships, maintain
focus, be organised, coordinate different teams, delegate, demonstrate leadership, listen, use intuition and have a customer focus (O‘Callaghan & Mariappanadar, 2006[a]). In all cases, the speedy return to service that failed and caused an unplanned outage is the goal of all incident managers.