Addressing the requirement for Post-Incident Reviews (PIRs) for Standard Incidents

danielmcken · 59m ago

Executive Summary

Within ServiceNow ITSM, Post-Incident Reviews (PIRs) are delivered as a component of Major Incident Management (MIM) . Outside of this there is no out-of-the-box PIR mechanism, yet many organisations want to run PIRs on standard incidents where an escalation occurred, a service level was breached, or a recurring fault needs to be understood and prevented. To note, Security Incident Response provides separate post-incident functionality for security incidents, but this is outside the scope of this paper.

This white paper examines three ways to meet that requirement and recommends an approach that delivers the outcome with minimal customisation and minimal ongoing risk. It evaluates leveraging Problem Management, leveraging Continual Improvement Management (CIM), and extending the existing MIM PIR functionality to standard incidents.

The conclusion is that Continual Improvement Management is the strongest fit for tracking PIR follow-up actions on standard incidents, with Problem Management retained where a formal root-cause analysis is required. Extending the MIM PIR to standard incidents is not recommended: it requires unsupported customisation of out-of-the-box workbench components, blurs the boundary between major and standard incident processes, and creates upgrade and maintenance risk that outweighs the benefit.

Introduction

Within IT Service Management (ITSM), Post Incident Reviews (PIRs) are structured reflections conducted after an incident has been resolved. The core purpose of a PIR is to examine what happened, why it happened, and what can be done differently next time. The goal is learning and process improvements to prevent recurrence.

Within ServiceNow ITSM, PIRs exist as a component of Major Incident Management (MIM) and are not a part of the incident management process outside of MIM. The objective of this article is to discuss how standard incidents, outside of MIM, can leverage a PIR process with minimal customisation to the base platform and minimal implementation effort.

A note on terminology: PIR is not RCA

It is worth separating two ideas that are often conflated. A Root Cause Analysis (RCA) seeks the underlying technical cause of a fault and is the natural output of a Problem record. A PIR is broader: it reviews how the incident was detected, handled, communicated and resolved, and identifies opportunities for prevention and process improvement. An incident may warrant a PIR without warranting a full RCA, and vice versa. This distinction drives much of the options analysis that follows, because the right platform capability depends on which outcome the organisation seeks.

Guiding Principles

When analysing requirements for enhancements to the ServiceNow platform, it is important to adhere to key guiding principles as part of a wider decision-making framework with the overall objective to avoid technical debt.

The scope of this article is not intended to re-establish these guiding principles. However, in short:

Leverage out of the box functionality in the first instance to minimise customisation where practicable.
Where customisation is required, the value of the customisation should outweigh any potential technical debt and risk created. This analysis is described in the business-smart customisation best-practice asset.

Each customer context is unique and has a different risk appetite when it comes to configuration and customisation. Regardless of the risk appetite, customisations should be examined within established guardrails as part of a robust decision-making framework.

Three questions to frame the decision

Before selecting a mechanism, three design questions should be answered, because they eliminate the most common anti-pattern before it is built.

Design question	Answer	Rationale
Should the PIR and its actions be managed under the incident?	No	The PIR itself runs several business days past resolution and its follow-up actions run for weeks or months. Long-lived actions held under the incident would be force-closed when the incident closes.
Should the incident be closed while actions remain open?	Yes	Close the incident when service is restored, on its own criteria. Keeping it open to hold PIR actions corrupts MTTR and SLA reporting.
Should the follow-up actions be Incident Tasks?	No	The out-of-the-box business rule closes child tasks when the incident closes. By default, for new customers, ServiceNow's Incident Management configuration closes open Incident Tasks when the parent incident is closed or canceled. When an incident closes, open Incident Tasks are set to Closed Incomplete. Although this behavior can be configured, changing Incident Task closure behavior simply to support long-running PIR actions would work against their intended use for work associated with incident resolution

These answers point the follow-up work away from the Incident table and towards a record type with its own life-cycle. The options analysis evaluates which record type is the right one.

Continual Improvement Management (CIM) Overview

According to ServiceNow Product Documentation, CIM is the ServiceNow application for capturing, prioritising and delivering improvements in a governed way. Improvement Initiatives are the core record. Each has a defined life-cycle, an owner, a target and progress tracking, and can be grouped under enterprise strategies for reporting.

Roles and responsibilities

Role	Responsibility	System role
Process Owner (Improvement Manager)	Owns and maintains the CIM process. Typically, a senior manager with the authority to ensure the process is implemented and used by all stakeholders.	sn_cim.improvement_manager
Improvement Coordinator	Coordinates improvements within an area of expertise at the process or service level. Existing ITSM process owners can be assigned this role for their respective areas.	sn_cim.improvement_coordinator
Improvement Requestor	Submits improvement initiatives. Available broadly to anyone who interacts with processes and has insight into bottlenecks. Inherited by ITIL users.	sn_cim.improvement_requestor

Options Analysis

Three options have been examined in relation to using PIRs for standard incidents. These are:

Leveraging the existing MIM PIR functionality
Leveraging Problem Management
Leveraging Continual Improvement Management (CIM)

Leveraging the Existing MIM Post Incident Report (PIR) Functionality
The most intuitive-seeming option is to reuse the PIR that already exists for major incidents. On closer inspection this is the weakest option for standard incidents, because the PIR is deliberately scoped to, and technically bound to, the Major Incident Management process. Note that two Post Incident Report implementations now exist, one in the Major Incident workbench and a separate one on the Post incident report tab in Service Operations Workspace. Both are only available once an incident has been accepted as a major incident and resolved, so neither provides a route to standard incidents.

Why the MIM PIR should not be used:

The PIR lives inside the MIM workbench. It is a tab within the Major Incident workbench and is only editable, in a usable form, through that interface or via the Service Operations Workspace (SOW). Using it for standard incidents would require handlers to access the MIM workbench, which blurs the boundary between major and standard incident processes.
The rich experience exists only in the workbench UI page and SOW. The formatted timeline, related improvement records and regenerate and edit controls only exist within the MIM process. A likely consequence of extending this is that a separate or duplicate workbench would need to be built and maintained or the SOW customised accordingly.
Outside the workbench the record is not fit for purpose. Opened directly as a record, the Timeline Events field displays as a raw JSON string rather than a readable timeline, and the summary is a plain HTML editor. It is effectively unusable for end users without the workbench.
The roadmap is outside our control. Extending the PIR means customising out-of-the-box workbench UI pages, script includes and PDF generation. Out-of-the-box script include changes are not reapplied on upgrade and must be manually reviewed and merged each cycle, making every upgrade a regression-test and rework exercise. Any future platform change to MIM or the PIR could break the customisation.

In short, this option requires a significant level of custom development to achieve an outcome that can be gained out of the box through CIM. It is not recommended.

Leveraging Problem Management

Problem Management is well suited to situations where an incident leaves an unresolved technical question that requires further investigation. Examples include an unknown root cause, a recurring failure pattern, an incomplete workaround, or uncertainty about the permanent technical remediation.

A Problem record provides a dedicated lifecycle for investigating these questions after service has been restored and the incident record has been resolved. ServiceNow describes Problem Management as the process for identifying and managing the root causes of actual and potential incidents. The Problem record can progress through assessment, root-cause analysis, remediation and closure without extending the lifecycle of the originating Incident.

However, Problem Management does not provide a complete post-incident review capability. A PIR typically examines more than root cause. It may consider the effectiveness of detection, escalation, communications, decision-making, stakeholder coordination, recovery activities and the overall incident response. It may also identify process, governance, documentation, monitoring or training improvements that are not technical problems and do not require root-cause analysis.

Using a Problem record as the sole container for a PIR may therefore narrow the review too heavily towards technical causation. It may also result in Problem records being created for incidents where the root cause is already understood and the outstanding actions relate instead to broader operational improvement.

Problem Management should consequently be used as a complementary mechanism:

The PIR captures the complete review of the incident and the effectiveness of the response.
A Problem is created where the PIR identifies an unresolved technical question or a need for formal root-cause analysis.
Problem Tasks coordinate the investigation and technical follow-up.
A Change manages the controlled implementation of an identified technical fix.
Non-technical improvement actions are managed through an appropriate improvement or action-tracking process.

Strengths

Provides a structured life-cycle for investigating unresolved technical questions.
Allows root-cause analysis (RCA) to continue after the Incident has been resolved.
Maintains traceability between related incidents, technical investigation and remediation.
Supports the assignment of discrete investigative activities through Problem Tasks.
Connects the identified cause to a controlled technical fix through Change Management.

Considerations

Problem Management is not a substitute for the complete PIR process. It is most appropriate when the review identifies something that remains technically unknown or requires deeper causal investigation.

Creating a Problem for every reviewed incident risks conflating two different purposes. A PIR evaluates the incident and the response, while Problem Management investigates the cause of actual or potential incidents. A Problem should therefore be raised based on the need for investigation, not simply because a PIR needs to take place.

Leveraging Continual Improvement Management (CIM)

Continual Improvement Management is purpose-built for tracking improvement items through to completion, with formal state management, ownership and progress monitoring. It is the strongest fit for the specific shape of PIR follow-up: actions with long tails that do not belong under the incident.

A CIM Improvement Initiative can be created directly from an incident using the out-of-the-box Create Improvement Initiative UI action, including from closed incidents, and the Improvement Initiative related list preserves the link back to the incident. Each initiative has its own lifecycle and approval workflow, so it can be tracked, reviewed and approved long after the incident has closed.

Strengths

No closure dependency on the incident. Initiatives age independently in the CIM Workbench.

Designed for multi-week and multi-month items, with formal state management and ownership.

Provides a formal improvement register, which is valuable for operational reviews.

Considerations

CIM introduces its own roles and personas that must be defined and assigned before use.

If PIR volume is high, the CIM register itself becomes the thing to govern. Without a named owner reviewing it, open initiatives accumulate and the process loses value.

CIM does not perform root-cause analysis. Where RCA is required, it should be paired with Problem Management.

Leveraging CIM for PIRs

The recommended pattern requires no custom Incident lifecycle logic and no extension of the MIM PIR. It uses the supported CIM integration with Incident Management, with only lightweight form/workspace configuration where required.

The incident closes normally on service restoration, a CIM Improvement initiative can be created from the resolved/ closed incident, and each follow-up action becomes a CIM Improvement task with an owner, a due date and an independent lifecycle. Initiatives are then governed through the CIM Workbench and standard dashboards.

Process flow

Incident resolved. Service is restored and the incident moves to Resolved.
Incident closed on its own criteria. No custom tasks are held open, so MTTR and SLA reporting remain intact.
A PIR is raised as a CIM Improvement Initiative, linked to the incident via the Improvement Register.
Initiatives are triaged, approved and tracked to completion in the CIM Workbench, escalating to Demand or Project where required.

Implementation Considerations

It is highly recommended to pilot a basic CIM process before layering on additional capability. This keeps the initial footprint out-of-the-box and defers anything requiring governance approval until the process has proven itself.

Do now	Do later
Activate/configure CIM Define PIR qualifying criteria Assign CIM personas and roles Define the pilot group Configure the Incident-to-CIM experience Define ownership and review cadence Configure a lightweight Initiative view	Enterprise strategy alignment KPI integration using Platform Analytics Formal approval/governance stages Demand/Project integration Automated PIR qualification Executive reporting

Basic configuration (to get the pilot going)

Create CIM persona groups and assign users to those groups.

Enable the Create Improvement Initiative UI action on the Incident table so it can be selected from the Incident table when incidents are resolved or closed.

Make the Improvement Initiative visible as a related list on the Incident form. This is the link between a CIM initiative and an incident.

Configure the CIM approval model appropriately for the pilot, avoiding unnecessary approval stages where the product configuration and governance model permit.

Define strategies to be associated with PIR-type CIMs, created on the Enterprise Strategy table.

Create a view so only the necessary fields are surfaced on the CIM form initially. Fields can be added back as process maturity develops.

Guardrails

Be selective about when a PIR is triggered. Mandating PIRs across most tickets creates significant overhead. Trigger on qualifying criteria such as recurring incidents, SLA breaches, customer-escalated incidents, or incidents flagged manually by a lead.

Cap and review the CIM register. If PIR volume is high, the CIM backlog becomes the thing to govern. Assign a named owner to review it regularly, otherwise open initiatives accumulate and the process loses value.

Conclusion

Standard incidents can be given a genuine PIR capability without customising core incident behaviour and without bending the Major Incident PIR to a purpose it was not designed for. The three design questions settle the shape of the solution early: the PIR and its actions should not hang off the incident, the incident should close on its own criteria, and follow-up work should not be modelled as Incident Tasks.

From there, the choice of record type follows the desired outcome. Continual Improvement Management is the recommended primary vehicle for tracking PIR follow-up actions, because it is purpose-built for improvement items that outlive the incident, it carries no closure dependency, and it provides supported integration paths into Demand and Project Management where an improvement requires more formal investment or delivery governance. Where an incident genuinely requires root-cause analysis, Problem Management remains the correct tool and can be combined with CIM in a mature pattern. Extending the MIM PIR to standard incidents is not recommended, as the customisation cost and upgrade risk outweigh any benefit over these fit-for-purpose, out-of-the-box alternatives.

The most valuable architectural decisions are often the customisations you choose not to build. In this case, ServiceNow provides existing capabilities that can satisfy the underlying requirement without extending the Major Incident PIR into the standard Incident process. The recommended approach is therefore to use CIM for governed improvement actions, Problem Management where formal causal investigation is required, and only introduce additional configuration where there is a clearly defined gap in how the PIR itself is captured or presented.

References

Configuration vs. Customization? - wrong question! https://developer.servicenow.com/blog.do?p=/post/configuration-vs-customization/
Business-smart customization - https://mynow.servicenow.com/now/best-practices/assets/businesssmart-customization
Continual Improvement Management - https://www.servicenow.com/docs/r/it-service-management/continual-improvement-management/cim-landing...