ServiceNow Problem Management Governance Model

Decision Forums and Governance Structure

Governance for Problem Management means named forums with defined authority, written standards for how problems are created, investigated and closed, configuration control over the module itself, and a decision register that the forums can run on. The sections below describe the Problem Review Forum and the steering forum, the standards for root cause and linking, change control for configuration, and a quarterly check that the model still fits.

A Problem Review Forum meets weekly or bi-weekly to assess problems in progress, discuss investigation status and blockers, and make decisions about problem closure or escalation. Attendees typically include the Problem Manager, representatives from incident management, engineering, and service delivery. This forum owns tactical decisions about individual problems.

A Problem Strategy or Steering Forum meets monthly or quarterly to review aggregate problem metrics, identify systemic trends requiring architectural changes, and ensure Problem Management investment aligns with business priorities. Attendees include service delivery leadership, engineering directors and IT management. This forum owns strategic decisions about Problem Management direction.

Escalation paths ensure that high-impact or blocked problems receive appropriate attention. A problem blocked by a vendor issue or requiring executive approval should be escalated clearly. Define who can escalate, to whom, and what authority each level has to approve or defer decisions.

Standards and Configuration Management

Document standards for how problems are created, investigated and closed. Standards should cover minimum documentation required (description, impact, root cause), investigation methodology, and closure criteria. Standards ensure consistency and make problem data useful for trending and analysis.

Define what constitutes “root cause” in your organization. Is root cause a single underlying issue, or can a problem have multiple contributing factors? Is root cause found through system analysis, customer interviews or vendor documentation? Clear definition prevents disputes during problem review and ensures investigations have sufficient depth.

Establish standards for problem linking. A problem should reference all incidents it is investigating. Multiple incidents linked to one problem indicate a systemic issue affecting multiple users or systems. Clear linking supports incident managers in identifying when incidents should be investigated as problems.

Define problem states and state transitions. Common states include: New, Under Investigation, Root Cause Found, Change Planned, Change Implemented, Closed. Each state transition should have clear criteria and owner. For example, a problem transitions from Under Investigation to Root Cause Found only when investigation is documented and approved by the forum or problem manager.

Configuration Control and Change Governance

Problem Management configuration—such as problem form fields, workflow steps, state definitions and integration with incident management—should be treated like production configuration. Document all configuration in a configuration management database or system, version changes and require approval before deployment to production.

Establish a change review process for Problem Management configuration changes. Who can propose changes? Who approves changes? How is impact assessed? When are changes deployed? A typical process includes: review meeting where changes are proposed and discussed, impact assessment identifying affected users and workflows, approval from governance forum or leadership, deployment to a non-production environment for testing, deployment to production during a maintenance window.

Common configuration changes include adding or modifying problem states, adjusting SLAs, changing escalation criteria or linking problem approval processes with change management. Each of these affects how the organization investigates and manages problems, so careful governance is warranted.

Standards for Problem Documentation and Knowledge

Problems should document investigation methodology and findings clearly so that teams can understand decisions and avoid repeating investigation effort. At minimum, each problem should include: a clear description of the symptoms, investigation steps taken and findings, root cause statement, action plan to prevent recurrence and closure notes.

Problem records should be linked to knowledge articles documenting the issue, the fix and how to recognize and resolve similar issues in the future. This creates institutional memory and helps incident managers quickly identify and escalate recurring issues.

Establish a knowledge retention strategy. As problems are closed, the most valuable findings (root cause, fix, recognition criteria) should be documented in a knowledge base or runbook. This documentation serves two purposes: it accelerates resolution of similar incidents in the future and it captures lessons learned so the organization can avoid repeating the same root causes.

Ownership and Accountability

Define who owns problem investigation: is there a dedicated problem manager role, or do incident managers also investigate? Is investigation distributed to engineering teams, or centralized in a problem management group? Clarity on ownership prevents problems from being orphaned or investigated by multiple parties.

Establish accountability for investigation progress. A problem stalled in investigation for weeks suggests either that the investigation is genuinely difficult or that ownership is unclear. Governance forums should monitor problem age and investigation time, identifying long-stalled problems and determining whether they need escalation, additional resources or different investigation approach.

Define approval authority for problem closure. Who confirms that root cause has been determined sufficiently? Who approves the action plan? Is closure approval delegated to the problem investigator, or does it require review by the Problem Review Forum? Clear authority prevents closure delays and ensures governance forums maintain visibility into completed problem work.

Metrics and Review Cycle

Track metrics that indicate Problem Management health: problem creation rate, average investigation time, percentage of problems resulting in changes, incident recurrence rate for closed problems, and problem backlog age. Review these metrics monthly and discuss trends in the governance forums.

An increasing problem creation rate can indicate better incident identification or a worsening underlying system quality, requiring investigation. Increasing investigation time may signal that problem investigators are being pulled to incident response or that investigations are becoming more complex. Decreasing change rates may indicate that problems are being closed without adequate fixes.

Establish a review cycle for Problem Management process itself. Quarterly or biannually, the governance forums should step back and assess whether Problem Management is achieving its goals: reducing incident recurrence, preventing major outages, and supporting system stability. Use this review to make process adjustments or shift resources.

Compliance and Audit Requirements

Some regulations require organizations to track and remediate problems systematically. Healthcare, financial and critical infrastructure organizations especially must demonstrate compliance with problem management standards. Document your Problem Management standards, review procedures and closure criteria. Maintain audit trails showing who investigated problems, what decisions were made and when.

Define retention policies for problem records. How long should problem data be retained? Some organizations archive problems older than two years; others retain indefinitely for historical reference. Retention decisions are often driven by regulatory requirements or business need for historical analysis.

A decision register that a governance forum can run on

Governance for problem management is usually described as a set of meetings. It succeeds or fails on a smaller artifact: a decision log that records who decided, what the decision rested on, and the point at which it gets reopened. A forum that meets regularly but keeps no register spends its time re-arguing settled points, because nobody can see what was decided, under which assumptions, or by whom. The register is also often the first thing an auditor or a newly appointed service owner will ask for.

The table lists decisions that often need a recorded owner. Each row also shows the level at which the decision usually belongs. Placing a decision at the wrong level is a common reason it stalls.

Where the register and the forums go wrong

The first failure is a forum that ratifies rather than decides. Items arrive already agreed in a side conversation, and the meeting signs them off without the evidence that could have changed the answer. Require the evidence column to be filled in before an item reaches the agenda. If the evidence is missing, the item waits.

The second failure is an escalation path that only runs upward. Every disagreement goes to the strategic level, which soon has a queue of tactical questions it was never built to answer. Let the tactical level settle disagreements about evidence, and send upward only questions of direction, budget or cross-service ownership. Write that split into the terms of reference so the rule does not depend on memory.

The third failure is a register nobody reads. New service owners who are not shown it will make decisions that quietly contradict earlier ones. Make the register part of the handover for anyone who inherits a service.

A quarterly check that the model still fits

1. List every decision recorded in the last quarter and mark any that were revisited before their review date. Repeated early revisits suggest the original evidence was weak.
2. Note how long each problem waited for a governance decision. A wait longer than the investigation itself points to a forum that is too slow for its volume.
3. Check whether any decision was taken by someone outside the level shown in the table. Explain those to the forum rather than reversing them quietly.
4. Remove states that nobody sets, and give a definition to any state people use for something else. The change governance model is a useful reference when deciding who approves a state change that affects implementation risk.
5. Record the agreed changes to the terms of reference as a dated version, with the people who agreed to them.

Questions about running the register

Who keeps the register current?

The problem manager, as a standing duty. Investigators record their findings in the problem record itself, but the register is a summary of decisions, and summaries drift when they rely on many people remembering to update them. The operations review agenda is a practical place to make the register a fixed item.

Does every closure need a forum decision?

No. Closures that meet an agreed rule, such as a verified fix followed by an observation window with no recurrence, can be closed by the investigator and noted in the register afterwards. The forum should review the exceptions instead of the routine closures.

What happens to decisions made by a service owner who has left?

The decision stays. Add a note that the owner has changed and put it on the next agenda for confirmation. Decisions are re-confirmed when the person relying on them is replaced, not when the person who made them moves on.

Can the governance forum override a change approval?

It should not. The forum can decide that a problem needs a fix and ask for that change to be prioritized, but the change approver decides whether and when the change goes ahead. Keeping those two authorities apart is what makes the audit trail credible.