Should projects log Incidents and Problems

By ITIL® from Experience©

When projects need services from operations it is advisable that they use the operational processes in place. For example: the Request Fulfillment process should be used to request a new server, or the Change Management process to authorize the installation of an application or the deployment of a solution. The same goes if the project has an incident or discovers a problem with the operational, live/production environment.

At first glance it seems reasonable for projects to log issues encountered during development of a solution as incidents or problems in the ITSM tool because it:

Enables the project to track issues to ensure that none are forgotten
Builds a knowledge base of issues and known errors1 benefiting the Service Desk after the project is completed
Helps operations people involved in the project to manage their project and operational priorities in one tool.

This works well when an appropriate Service Level Agreement (SLA) is applied to these requests. An SLA is required This is required to avoid creating a conflict whereby development issues take precedence over high-priority

Priority: (ITIL® Service Operation) (ITIL® Service Transition) A category used to identify the relative importance of an incident, problem or change. Priority is based on impact and urgency, and is used to identify required times for actions to be taken. For example, the service level agreement may state that Priority 2 incidents must be resolved within 12 hours.
Source: ITIL® glossary and abbreviations, English, 2011, www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx

operational incidents. It also requires a certain maturity of the Configuration Management process to ensure that incidents and problems can be tracked against the Configuration Item (CI) in development and not the version of the CI in production – moreover the CI must be in the CMDB to do this tracking. In addition, the Change Management and Release Management processes must be mature enough to distinguish between non-operational RFCs and releases to production.

A challenge with this approach can be the specialized bug/defect tracking tool(s) used by the Application Development group. These tools can be quite sophisticated with functionality to associate code changes to the defect record and the ability to check in a fix to the code repository so that it is part of the next build. Some ERP2 systems even require the use of their functionality to deploy releases. In this context, using the ITSM tool would be a step back in the process and organizational maturity and likely result in more bureaucracy.

Most organizations struggle with the implementation of ITIL processes for their operations. To extend these processes to handle projects adds a level of complexity and challenges which may be best addressed once processes have attained a certain level of maturity and once they become part of the organization’s day-to-day work practices.

As a result, yes projects should log incidents and problems in the ITSM tool when they are related to the operational (production) environment, but only mature organizations should consider tracking project/development issues in their ITSM tool. In the meantime, project issues and action items should be tracked outside of the ITSM tool. Some ITSM tools also recognize the separation between project/development and operations. Their RFCs have a project code field, however, their incidents and problems cannot be associated to a project as they are missing the project code field.

Related:

ITSM Implementation Quotes

Category:
Implementation > Project Management
ITIL Process > Incident Management
ITIL Process > Problem Management

Plugin disabled

Plugin footnotearea cannot be executed.

Disclaimer

<HR>