By Donna Knapp   At one point in my career, I was a change manager. I ran my company’s change advisory board (CAB), and I spent endless hours trying to convince project managers to submit requests for change (RFCs). Despite my best efforts, I invariably had to explain, fairly often, that ‘poor planning on your part does not constitute an emergency change on mine.’ At that time, the change manager role was one of the many hats that I wore. My ‘real’ job was service desk manager. We called it a ‘hotline’ then and so yes… it was many, many years ago. In that role, I and my team saw the impact of poorly executed and failed changes. We dealt every Monday morning with the chaos that came out of the massive changes made over the weekend. That was then. Since then, much has changed. But it was through that lens that, more than 10 years ago, I first started researching a movement in the IT industry called DevOps. At the time, it was early days for DevOps and individuals and organizations were s

By Donna Knapp It’s interesting to see how members of different communities can view a practice so differently. That is currently the case with problem management, the practice of identifying, removing, or mitigating the cause or contributing factors to service disruptions. For the most part, the IT service management (ITSM) community recognizes the value of problem management. They may admittedly struggle to find the time or resources needed to perform the practice. Or they may find it difficult to justify the actions needed to introduce permanent solutions identified as a result of the practice. But they, for the most part, value the practice. Conversely, some members of the DevOps community view problem management, or more specifically, root cause analysis, as a complete waste of time. We’ve found that there are a few common reasons that on the surface make sense, but that have counterpoints worth considering. One reason for the pushback is that the practice of root cause analysis i

By Donna Knapp Have you ever done business with an organization that liked to brag about all the extras that it provides, but doesn’t get the basics right? To some extent, the accelerated innovation that was sparked by the pandemic fueled this need to focus on the new and shiny. And for some organizations, it is what’s needed to stand out in the crowd, or to compete, or simply to survive. But here is what we know. All the new and shiny in the world can’t make up for a poor customer experience. You cannot sacrifice quality for speed. And a perk here and there can’t overcome the lack of trust that builds up when an organization fails to get the basics right day in and day out. So, what we’ve got to do is strike a balance. A feat that is easier said than done. According to the 2022 State of CIO report, 76% of CIOs say that it’s challenging to find the right balance between business innovation and operational excellence. And yet it is exactly what organizations today need to do… C. All of

The ITIL 4 Best Practice Guidance defines a “Service Offering” as a description of one or more services designed to address the needs of a target customer or group.   As a service provider, we can’t stop there!   We must know what the contracts of our service offering are and be able to put them into context as required by the customer.     Let’s explore the three elements that comprise a Service Offering. A “Service Offering” may include:     Goods, Access to Resources, and Service Actions 1. Goods – When we think of “Goods” within a service offering these are the items where ownership is transferred to the consumer and the consumer takes responsibility for the future use of these goods.   Example of goods that are being provided in the offering – If this is a hotel service then toiletries or chocolates are yours to take with you.   You the consumer own these and they are yours to take with you.               Note: Goods may not always be provided for every Service