5.5 Planning and implementation

5.5.1 Timing and planning

Some guidelines for planning Incident Management are as follows:

• Do not plan to implement and operate Incident Management in isolation. If possible, the scope of planning should be extended to include the implementation, integration and operation of the Service Desk, Problem Management, Configuration Management, Change Management and Release Management processes.
• If resources are not available to implement all Service Support processes at the same time, begin by implementing the Service Desk function together with Incident Management. This will result in 'quick wins' and therefore acceptance of process implementation in general within the IT organisation and with Customers.
• Plan to create the Service Desk and to define Incident Management processes at the earliest opportunity. If a major new Customer IT service is being implemented with gradual User take-on, install the Service Desk from the outset. Do this even if the initial number of Users would normally fail to justify a desk. This approach allows the Service Desk to grow with the new service take-on.
• The planning phase for Incident Management could last from three to six months for a sophisticated, extensive solution. The implementation phase could last from three months to a year, although implementation and improvement should be considered as an ongoing activity.
• The procurement of hardware and software can be time-consuming. Start selection procedures as soon as possible, based on seeking those that support the ITIL processes, and provide the required level of flexibility to allow for organisation-specific needs.
• Keep closely linked systems, especially Configuration Management, in step. Plan for the creation of a Configuration Management Database (CMDB) and the conversion of existing equipment inventories. If no integrated Configuration Management system is in place, make this database part of the Incident Management system.
• Plan for an interface with the Problem Management system to assist Service Desk staff in recognising and giving advice on circumventing Known Errors. If such a system is scheduled for later implementation, consider the use of an interim paper-based or
• free-standing electronic solution (e.g. spreadsheet) to 'bridge the gap.'

5.5.2 Critical success factors

Successful Incident Management requires a sound basis, as highlighted by the following points:

• An up-to-date CMDB is a prerequisite for an efficiently working Incident Management process. If a CMDB is not available, information about Configuration Items (CIs) related to Incidents should be obtained manually, and determining impact and urgency will be much more difficult and time-consuming.
• A 'knowledge base' in the form of an up-to-date Problem/error database should be developed to provide for resolutions and Work-arounds. This will greatly speed up the process of resolving Incidents. Third-party Known Error databases should also be available to assist in this process.
• An effectively automated system for Incident Management is fundamental to the success of a Service Desk. Paper-based systems are not really practical or necessary, now that good and cheap support tools are available.
• Forge a close link with the Service-Level Management (SLM) process to obtain necessary Incident response targets. Timely Incident resolution will satisfy Customers and Users.

5.5.3 Possible problem areas

Be prepared to overcome:

• no visible management or staff commitment, resulting in non-availability of resources for implementation
• lack of clarity about business needs
• working practices not being reviewed or changed
• poorly defined service objectives, goals and responsibilities
• no provision of agreed Customer service levels
• lack of knowledge for resolving Incidents
• inadequate training for staff
• lack of integration with other processes
• lack of, or expense of, tools to automate the process
• resistance to change.