Change Management ITSM
Control every IT change. Protect service stability. Move faster with less risk.
Most IT incidents are not random. A significant share are caused by poorly controlled changes — a configuration update pushed without approval, a patch deployed without impact assessment, a release with no rollback plan. Change management exists to prevent exactly this.
SMC Consulting designs and implements ITIL v4 change management processes that give your organisation the governance to move fast without breaking things.
What is Change Management in ITSM?
Change management, now called Change Enablement in ITIL v4, is the process that controls the lifecycle of all changes to IT infrastructure, services and applications. Its purpose is to enable beneficial changes while minimising disruption to live services.
A change is any addition, modification or removal of anything that could affect IT services. This includes infrastructure updates, application releases, configuration changes, security patches and network modifications.
Three types of change you need to manage differently:
- Standard changes are pre-approved, low-risk changes with a documented procedure
- Normal changes require assessment, authorisation and planning before implementation
- Emergency changes must be implemented immediately to resolve a critical incident or security threat
Unclear boundaries between these three types is the most common source of governance failure.
The Change Management Lifecycle: 7 Stages
Change Request (RFC)
Every change starts with a Request for Change — capturing what needs to change, why, what the impact is, and what the rollback plan is. No RFC, no change.
Assessment and Classification
The change is assessed for risk, impact and urgency. Classification as standard, normal or emergency determines the approval path, CAB involvement and planning requirements.
Change Planning
Normal and emergency changes require a detailed implementation plan: who does what, when, which systems are affected, testing approach, and rollback triggers. The CMDB is essential here — understanding which configuration items are affected and their dependencies directly determines impact assessment accuracy.
Change Advisory
Board (CAB) Review
The CAB reviews normal changes before authorisation. A well-functioning CAB is not a bureaucratic bottleneck — it is structured risk assessment with the right people in the room. CAB membership should include IT operations, service owners and, for high-impact changes, business representatives.
A common failure: CAB meetings held weekly regardless of urgency. A mature process includes an Emergency CAB mechanism for time-sensitive changes.
Authorisation
The change is formally approved or rejected by the appropriate authority based on risk level. The authorisation level must match the risk level. Standard changes are pre-authorised. Normal changes require CAB sign-off. Emergency changes follow a rapid authorisation path.
Implementation
The change is implemented according to the approved plan, in a defined maintenance window where applicable. Incident Management remains on standby. If the change introduces a disruption, the rollback procedure is triggered immediately without debate.
Post-Implementation
Review (PIR)
Every significant change is reviewed after implementation: did it achieve its objective, did it cause unintended impact, what can be improved? PIRs feed directly into the knowledge base and continuous service improvement.
Change Management KPIs
| KPI | KPI What It Measures | Target |
|---|---|---|
| Change success rate | % of changes implemented without incident | >95% |
| Change-related incident rate | % of total changes classified as emergency | <10% |
| M365 / Teams Integration | % of total changes classified as emergency | <5% |
| CAB cycle time | Average time from RFC submission to authorisation | Defined per SLA |
| Unauthorised change rate | % of changes detected post-implementation without RFC | 0% |
The Most Common Change Management Failures
No RFC discipline. Changes are implemented informally, without a record. When an incident occurs, there is no change log to cross-reference.
It is also distinct from service request management. A request for new software access or a hardware replacement is not an incident. Mixing the two in the same queue degrades the handling quality of both.
Which integrations shorten time to restore service?
Integrations reduce context switching, remove manual duplication, and keep incident work synchronized across teams.
Microsoft Teams
Jira Software
Azure DevOps
What incident
management is not
Incident management is not about finding root causes — that is problem management. Its sole objective is service restoration. Companies that spend resolution time diagnosing why instead of fixing what consistently miss their SLAs.
It is also distinct from service request management. A request for new software access or a hardware replacement is not an incident. Mixing the two in the same queue degrades the handling quality of both.
Frequently asked questions about HaloITSM incident management
What is the difference between incident management and problem management in ITIL 4?
Incident management restores service quickly after an interruption. Problem management identifies root cause and prevents recurrence. Incidents and recurring patterns often become inputs for improvement initiatives and change controls, including change management in HaloITSM.
Is HaloITSM incident management aligned with ITIL 4?
Yes. HaloITSM supports incident categorization, prioritization, SLA management, escalations, and closure controls. SMC aligns configuration to ITIL 4 practices through ITIL v4-certified engineers and your maturity level.
Can users raise and track incidents in Microsoft Teams?
Yes. HaloITSM can support Teams-based intake, notifications, approvals, and self-service access. This improves adoption and reduces context switching for both users and agents.
How does HaloITSM support major incident management?
Major incident workflows can be configured with dedicated priority levels, specialized escalation paths, stakeholder communication templates, and roles. Integrations like PagerDuty can support on-call escalation with synchronized updates.
How does knowledge management reduce incident volume?
A structured knowledge base enables self-service, improves first-contact resolution, and reduces repeated troubleshooting. SMC configures this through HaloITSM knowledge base and self-service and can extend knowledge foundations with Document360
How does incident management connect to change management in HaloITSM?
Incidents that require configuration changes can trigger change management workflows so changes follow approvals and controls instead of being applied informally under pressure.
How long does a HaloITSM incident management setup take?
Typical timelines depend on integrations, maturity, and data readiness. Many incident scopes reach go-live in 4 to 8 weeks, with optimization in the first 90 days.
What does incident management cost in HaloITSM?
Cost depends on licensing and implementation scope. Pricing guidance is available on HaloITSM pricing, and SMC provides a scoped estimate during discovery.
Resolve incidents faster with HaloITSM, with less manual triage
HaloITSM gives your service desk the structure to manage incidents consistently and the automation to reduce repetitive work. SMC Consulting configures incident management so routing, SLAs, knowledge, and integrations work together as one operating system.
