INTERNAL USE ONLY

Overview

This article gives an overview of the classification of items, provides sample use cases, and provides additional notes regarding how these classifications manifest themselves within TeamDynamix.

Directions

Incident An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted one or more Services is also an Incident. For example: Failure of one disk from a mirror set.

Problem  A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation.

Change The addition, modification or removal of anything that could have an effect on IT Services. The Scope should include all IT Services, Configuration Items, Processes, Documentation etc.

Release A collection of hardware/software documentation, Processes or other Components required to implement one or more approved Changes to IT Services. The contents of each Release are managed, tested, and deployed as a single entity.

Service Request A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk and do not require an RFC to be submitted.

Use Cases

A good simple use case for most of these would be that there are fifty Incidents of Wi-Fi being interrupted. Those Incidents are then rolled up into a single Problem ticket about the lack of suitable Wi-Fi infrastructure. A Change ticket could then be opened and the Wi-Fi infrastructure is then changed/upgraded to be more resilient and reliable. A Release ticket could then be created and then the institution could then release new documentation and justification for the upgrade in Wi-Fi infrastructure. Also, release the news that the new Wi-Fi infrastructure should be more consistent and that people should not worry, etc.

Use in TeamDynamix

The hierarchy of what can be used as parent/child tickets in TeamDynamix is as follows:

Note that a parent ticket can contain any of the child classifications below it. This means that a Release can contain any Problems, for example, without a Change between them in the hierarchy.

When a parent ticket, such as a Release, is updated, a technician can elect to update/close all the child tickets, such as Changes, Problems, and Incidents. that are nestled within it.

When a ticket is converted to a project task, any existing parent linkage is removed, but children tickets will remain; however, updates made to the ticket based on the corresponding project task's status will not be cascaded to its children.