When an incident is caused by a defect, how should IT teams respond? It’s a question we’ve been answering for years, and it’s still just as relevant, especially in today’s complex, fast-moving environments where software, infrastructure, and services are deeply interconnected. In ITIL 4 , an incident is defined as an unplanned interruption to a service or reduction in the quality of a service . That hasn’t changed. But what happens when the root cause of that interruption is a defect -  an underlying flaw in software, hardware, or configuration? Here's the Modern Approach: Log the incident : The user is experiencing an interruption that needs immediate attention. Document known defect links : If the defect is known (e.g., “already logged with Dev”), link the incident to the problem record , known error , or defect backlog in your tracking system (Jira, Azure DevOps, etc.). Communicate expectations : While the defect may not have a quick fix, the incident response sh...

There are some misconceptions about ITIL ® 4 and its use of the term ‘practice’ vs. ‘process’ as a component of its recently introduced service value system. One misconception is that processes aren’t important anymore. Another is that organizations think they must completely redesign their tools in order to accommodate this change. Neither is true. Let’s begin by taking a look at how ITIL 4 defines these terms. Process: a set of interrelated or interacting activities that transform inputs into outputs [to accomplish an objective]. Processes define the sequence of actions and their dependencies. Practice: a set of organizational resources designed for performing work or accomplishing an objective. Practices include resources based on the four dimensions of service management which include: organizations and people, information and technology, partners and suppliers, and value streams and – wait for it – processes.   Both processes and practices focus on achi...