Understanding Major Incident and Problem Management

TeamDynamix supports ITIL-based Major Incident and Problem Management through specialized ticket classifications.

Major Incident Management addresses large-scale, production-impacting issues requiring immediate attention and rapid resolution. These are typically service outages affecting multiple users or critical business functions. The focus is on fast recovery, often through workarounds, rather than identifying root causes.

Problem Management investigates the underlying causes of incidents to prevent recurrence. This is a deliberate, methodical process that may span weeks or months. Problem Management can be:

  • Reactive: Investigating problems identified through incident patterns
  • Proactive: Analyzing trends to identify potential problems before they cause incidents

Both processes use the ticket classification system in TeamDynamix, allowing organizations to track, manage, and report on these specialized workflows separately from standard incidents.

In this article, we'll cover:

 

Problem Management Activities

The following activities outline typical steps in the problem management process. Organizations can implement these using ticket workflows, status changes, and parent-child relationships:

Problem Identification and Logging

  • Create a new ticket with the Problem classification
  • Or promote an existing Incident to a Problem using Actions > Change Classification
  • Link related Incidents as children to the Problem ticket to establish patterns:
    • From the Problem: Use the Children tab > + Add Existing
    • From each Incident: Use Actions > Set Parent to select the Problem
  • Document initial symptoms and business impact in the Problem ticket

Problem Prioritization

  • Evaluate business impact based on frequency of related incidents and severity
  • Review the Children tab to see how many users or services are affected
  • Determine if investigation is justified based on organizational priorities

Please note that ITIL does not call out this activity.

Problem Investigation

  • Assign cross-functional teams using responsible groups or individual assignments
  • Track investigation activities through ticket updates and feed entries
  • Use ticket tasks to break down investigation steps
  • Document findings and progress in the ticket feed
  • Continue linking new related Incidents as children during the investigation period

Workaround Documentation

  • Record temporary solutions in the Problem ticket
  • Create knowledge base articles for known workarounds and link them to the Problem ticket
  • Communicate workarounds to the service desk team
  • When technicians update related child Incidents, they can reference the parent Problem's workaround

Change Implementation

  • When root cause is identified and a solution is determined, create a Change request
  • Establish the relationship using one of these methods:
    • From the Problem ticket: Actions > Create Parent > Select Change classification
    • Or create the Change ticket separately, then from the Problem: Actions > Set Parent
  • The Problem becomes a child of the Change, maintaining traceability from investigation through implementation
  • If the Change is part of a larger Release, the Change can be linked as a child of the Release
  • Process the Change through your change management workflow

Problem Closure

  • Problem records typically remain open as long as related incidents continue to occur
  • Monitor the Children tab—if new Incidents stop appearing, the fix was successful
  • Close the Problem only when:
    • The root cause has been permanently resolved
    • The affected components have been retired or replaced
    • Sufficient time has passed with no recurring incidents
  • Document the final resolution and root cause analysis in the Problem ticket
  • The ticket history preserves the complete investigation and resolution path

Implementation Considerations

Process Ownership: Problem management requires dedicated ownership and staff allocation. Before implementing, ensure you have:

  • A designated problem manager or team
  • Sufficient technical resources for investigations
  • Management support for investigation time allocation

Integration Requirements: Some organizations use automated monitoring tools to identify major incidents. If you receive automated notifications, you may need:

  • Email integration to create major incident tickets automatically
  • API integration for monitoring tool alerts
  • Custom automation rules to route and assign major incidents appropriately

Resource Planning Problem investigations can be time-intensive and require senior technical staff. Consider implementing an investigation approval workflow to:

  • Prioritize which problems warrant full investigation
  • Balance problem management with other organizational priorities
  • Manage competing demands on technical resources​​​​

 

Frequently Asked Questions (FAQs)

How do I decide if an incident should be classified as a major incident?

Major incidents typically meet one or more of these criteria:

  • Service outage affecting multiple users or departments
  • Impact on critical business functions
  • Potential for significant financial or reputational damage
  • Requires coordinated response from multiple teams

Organizations should establish clear criteria in their incident management procedures.

What's the difference between major incidents and problems?

Major incidents are large production outages (e.g., a campus-wide email outage) and are focused on rapid recovery and quick service restoration.

Problems focus on preventing recurrence and conducting root-cause investigations, which may have a longer, less urgent timeline.

A major incident may be related to an existing problem or reveal a new problem requiring investigation.

Should I use workflows for problem tickets?

Workflows are highly recommended for problem management, especially for:

  • Investigation approval - ensuring leadership authorizes the time and resources needed
  • Team coordination - routing problems to appropriate technical teams
  • Status tracking - moving problems through investigation, resolution, and validation stages

The workflow can enforce accountability and provide visibility into the problem management process. 

How do I communicate active problems to technicians?

Several approaches work well:

  • Create a dashboard module showing active problems and embed it on technician desktops
  • Use automation rules to send notifications when new problems are identified
  • Configure SLAs with notification rules to alert relevant teams
  • Publish internal knowledge base articles about known problems and workarounds

When should I create a change request for a problem?

Once you've identified the root cause and know what change is needed, and if the change requires review and approval, you should create a change request.

Set the change as the parent of the problem record to maintain traceability. Process all problem-related changes through your change management workflow rather than implementing them directly from the problem ticket.

Can I promote an Incident to a Problem?

Yes. TeamDynamix supports classification promotion, allowing you to convert tickets between classifications while preserving ticket history and relationships.

To promote an Incident to a Problem:

  1. Open the Incident ticket
  2. Click Actions > Change Classification
  3. Select Problem
  4. Update any required fields for the Problem classification
  5. Click Save

This is useful when you initially log a ticket as an Incident but later determine it requires problem management investigation. Note that the original ticket ID is preserved—only the classification changes.

Alternatively, you can create a new Problem ticket and link the original Incident as a child, which preserves both tickets separately.

How do I get started with problem management?

The first step in problem management is developing an effective process. Begin by helping your organization identify major issues, such as whether a specific service is causing numerous incidents. Then consider demonstrating problem management by applying it to these specific service issues.

How do people find the time to practice problem management?

While ITIL does not explicitly require it, adding a problem investigation approval step at the beginning of your process can be beneficial. Problem management typically involves senior representatives from various teams—the same who are on the critical path for important projects and initiatives. By incorporating an investigation approval step, management can prioritize urgent issues that truly need resolution and decline those that are less critical. This helps technical teams focus on enhancing systems that are already functioning well rather than on perfecting those that are already satisfactory.

Examples

Major Incident with Multiple Affected Users:

  • A campus-wide network outage impacts 50 users who each submit tickets
  • Create or identify one ticket as the Major Incident (parent)
  • Link all 50 user tickets as children of the Major Incident
  • Update the Major Incident status with cascading enabled to notify all 50 users simultaneously

Problem Investigation with Recurring Incidents:

  • Multiple users report slow printing to a specific network printer over several weeks
  • Each report creates an Incident ticket
  • Create a Problem ticket to investigate the root cause
  • Link all related Incident tickets as children of the Problem
  • Investigation reveals a printer firmware bug
  • Create a Change request to update the firmware
  • Link the Problem as a child of the Change to track the complete resolution path
  • Hierarchy: Change (parent) > Problem > multiple Incidents (children)

Complex Multi-Level Relationship:

  • A firewall configuration issue causes recurring network disconnections
  • Multiple Incidents are logged by affected users
  • Create a Problem ticket and link the Incidents as children
  • Investigation identifies the need for firewall reconfiguration
  • Create a Change request and link the Problem as its child
  • The Change is part of a larger network infrastructure Release
  • Link the Change as a child of the Release
  • Final hierarchy: Release > Change > Problem > multiple Incidents

This structure allows you to:

  • Track the investigation (Problem level)
  • Manage the fix implementation (Change level)
  • Coordinate with broader infrastructure updates (Release level)
  • Maintain visibility to affected users (Incident level)
Print Article