Knowledge library
Every article on the Exchange, newest first. Articles marked Members open with a free preview; join free to read them in full.
Guiding PrinciplesMembers
Collaborate and Promote Visibility
Collaboration improves decisions when work, constraints, evidence and ownership are visible to the people who depend on one another.
Guiding PrinciplesMembers
Optimise Before You Automate
Automation amplifies the design it is given, so the flow, controls, data and exception handling should be simplified first.
People and SkillsMembers
Building a Practical Skills Matrix
A skills matrix makes required capability, current coverage and development priorities visible without reducing people to simplistic scores.
People and SkillsMembers
Using SFIA to Structure Capability Development
A recognised skills framework can give consistent language for responsibility, autonomy, influence and professional capability across service roles.
People and SkillsMembers
Using Team Roles to Improve Collaboration
Team-role profiling helps leaders balance contribution styles and design collaboration around strengths, provided labels do not become limits.
Incident ManagementMembers
Incident Management as Service Restoration
Incident management exists to restore normal service and minimise business impact, not to complete administrative records.
Incident ManagementMembers
Maintaining Ownership Through the Incident Lifecycle
Visible ownership ensures coordination, communication and follow-through even when investigation moves between specialist groups.
Incident ManagementMembers
Logging Incidents for Action and Learning
Good incident records capture enough structured and narrative information to restore service, communicate effectively and support later analysis.
Incident ManagementMembers
Prioritising Incidents by Impact and Urgency
Priority should reflect business impact and time sensitivity through agreed rules, not status, seniority or pressure alone.
Incident ManagementMembers
Managing Major Incidents as Business Events
Major incidents require rapid authority, coordinated technical work, business communication and explicit decisions about risk and recovery.
Problem ManagementMembers
Problem Management for Permanent Improvement
Problem management reduces the likelihood and impact of incidents by identifying causes, managing known errors and driving preventive change.
Problem ManagementMembers
When an Incident Should Become a Problem Record
A problem record is justified when deeper investigation or coordinated prevention is needed beyond restoring one incident.
Problem ManagementMembers
Managing Known Errors and Workarounds
A known error record converts learning into faster restoration and controlled risk until a permanent resolution is delivered.
Problem ManagementMembers
Using Five Whys Without Oversimplifying Causes
Five Whys is a prompt for deeper causal inquiry, not proof that a complex failure has one linear root cause.
Problem ManagementMembers
Using Pareto Analysis to Focus Improvement
Pareto analysis helps teams concentrate on the categories that contribute most to impact, while preserving awareness of rare high-risk events.
Problem ManagementMembers
Building an Ishikawa Diagram for Complex Problems
A fishbone diagram broadens investigation across people, process, technology, information, environment and suppliers before hypotheses are tested.
Problem ManagementMembers
Identifying Single Points of Failure
Single-point-of-failure analysis reveals components, roles, information or suppliers whose loss can break a service without a viable alternative.
Change and Release ManagementMembers
The Purpose of Operational Change Management
Operational change management enables beneficial change while balancing value, risk, readiness, scheduling and service stability.
Change and Release ManagementMembers
Standard Normal and Emergency Changes
Change types should determine proportionate controls, evidence and authority so governance is both fast and safe.
Change and Release ManagementMembers
Making the Change Advisory Board Effective
A CAB should improve risk and scheduling decisions for relevant changes, not act as a universal approval meeting.
Change and Release ManagementMembers
Using a Change Schedule to Protect Services
A shared change schedule exposes collisions, resource constraints, business events and cumulative risk before implementation.
Change and Release ManagementMembers
Designing an Effective Release Policy
A release policy provides consistent rules for scope, packaging, frequency, evidence, authority, traceability and early-life support.
Change and Release ManagementMembers
Release Versus Deployment
Release makes a service or feature available for use; deployment moves components into an environment, and the two moments may differ.
Change and Release ManagementMembers
Choosing a Deployment Strategy
Deployment strategy should reflect risk, reversibility, architecture, user impact, support capacity and the evidence needed to proceed.