Errors, Bugs, Incidents, Defects, Oh My!

IT service management (ITSM) has always been about end-to-end service – a means of co-creating value to customers by facilitating outcomes that customers want without ownership of specific costs and risks.

In theory.

In theory, ITSM has always been about translating business requirements into the right mix of people, process, and technology that results in business value. ITSM has always been about building, implementing, delivering, and managing IT services from end-to-end – from point of origin to point of consumption. This means that, in theory, ITSM encompasses all parts of the IT organization – from operations to security to development to quality assurance.

In theory.

But in actual use… for many organizations, ITSM is only about the operational aspects of IT. Managing incidents, problems, changes, contacts to the service desk. Not services. Not quality. Not development. Not that those other things are not being done… they’re just…. ignored.

But often this approach has had some benefit to the IT organization… or more precisely, the IT operations team. These organizations used what they called “ITSM” to build a wall around the infrastructure in an effort to ensure stability and reliability. But taking an ‘operations only’ approach to ITSM only helped… IT operations.  In actuality, it’s not really “ITSM.”

Taking an ‘operations only’ approach to #ITSM only helps… IT operations. In actuality, it’s not really “ITSM.” - @DougTedder #ITSM Share on X

What about IT development?

Meanwhile, the IT development team is also working hard and faced with its own set of challenges.

IT development is typically reacting to ever-changing business demands and changes in marketspaces by writing code to drive and enable new functionality, and ultimately, business value. But as is the nature of IT development, what is valued today, may no longer have the same value in a few months. As a result, there’s a constant demand for new code, new functionality, and new features in apps and software to address those ever-changing business demands.

Traditionally, IT development threw all of the new stuff they produced “over the wall” to the IT operations team to run and support, because there was always the next new thing to develop. Admittedly, DevOps thinking has changed that attitude in some organizations. But for other organizations, the move of new code from a development to the productive environments amounts to little more than a “dump and run.”

You don’t speak my language!

So, each team has developed its own sets of tools and vocabulary to manage its specific kinds of work.

For example, look at how IT organizations talk about ‘things that are wrong.’

IT operations calls them “incidents” or “problems.” An incident is an event that interrupts or degrades a service. A problem is the unknown cause of an incident. But an incident can be a problem if the interruption or degradation is of sufficient severity. Take it one step further – a problem can be raised without having had an incident.

IT developmentuses terms like “bugs,” “defects,” and “errors.” According to this Medium.com article, a mistake in code is called “error.” A “defect” is any variance between the actual and expected result. And a “bug” is a defect that is accepted by the development team.

Now here is where it really gets fun.

From an IT operations perspective, a bug is a “known error.” That same bug could result in an incident for an IT consumer. To fix the situation, the IT operations organization would send that incident to the IT development group to be addressed. What should the IT development team do? How should this incident be handled in the face of the constant demand for new functionality? What is most important? Not an easy answer.

Finding the balance

Neither extreme is sustainable. But it’s not as simple as just “meeting in the middle” or investing in a tool that doesn’t really work for either IT development or IT operations.

How do we really share knowledge from development into operations and vice versa? 

How do we leverage the knowledge and experience gained from either team across the entire team? 

How do we work on the right things that are most important or critical to the organization without ignoring what must be done to maintain what is currently running the business?

It takes both parts to deliver end-to-end value in the form of services. But it’s not just making one end fit to the other. It’s not as simple as just “adopting DevOps” or adopting and adapting more ITIL practices.

It is about ITSM. It is about understanding your business, your market and the competition, your capabilities, and how the use of people, process, and technology helps your organization have success and achieve its vision and goals.

But too many organizations go for only the technology play. The reality is that technology alone will not help. But it is also reality that many organizations invest in technology without having a good understanding of their business capabilities, environment, resources, or requirements… then blame that technology when those underlying problems remain unresolved.

@DougTedder discusses how too many organizations go for only the technology play. When the reality is that technology alone will not help. Share on X

Overcoming ourselves

Somehow, we need to create the space we need to do the things that’s needed from us without getting in each other’s way, yet work in a way that we don’t step on what each other is trying to do. We have to work holistically. If your ITSM implementation isn’t facilitating a holistic approach, here are some things to do.

Collaborate – really

Do the development and operations teams share the same goals? Are those goals defined, documented, measured, and regularly reviewed jointly by both teams to identify and implement improvements?

It’s one thing to say that teams collaborate; it’s completely another thing to actually collaborate. True collaboration means that both teams work together with each team looking out for the other.

Rethink your CAB

When’s the last time that your organization objectively looked at the function of the CAB? Are you doing a CAB because “that’s how you’ve only done things”? Nothing is more frustrating than to have to have a change request reviewed “just because.”

Perhaps the need and function of the CAB as the reviewers of change requests made sense at one time, but it’s likely that both the business environment and technical capabilities have evolved dramatically since the CAB was founded. I think the role of the modern CAB is governance and resolution of conflicting change requests – not reviewing every flipping RfC.

Leverage CI/CD

The benefits of a continuous integration/continuous deployment approach are well known. First, it leverages a defined set of operations services based on a standardized infrastructure. Changes to code can only be committed if those changes pass integration testing. And the development team can quickly and effectively respond to those ever-changing business needs, while at the same time, ensuring that those changes will not negatively impact the productive environment, which is a good thing for IT operations.

If your #ITSM implementation isn’t facilitating a holistic approach, check out this advice from @DougTedder. Share on X

Good ITSM is about enabling, not restricting

ITSM, done well, empowers both the development and operations teams to do the work they’re being asked to do within a shared, defined approach. This means that good ITSM enables both teams by using the right tools from the toolbox.

Recognize that to build your ITSM house, you need carpenters. And plumbers. And electricians. And painters. And landscapers. And a homeowner. But everyone works towards the same goal – a house that meets the owner’s wants as well as the owner’s requirements – at the price the owner is willing to pay.

The same with good ITSM.  Leverage what works for your organization from a combination of approaches, including ITIL, DevOps, Agile, Lean, and more.

[su_note note_color=”#ebebeb”]The meeting of DevOps and ITSM can be felt with SysAid’s latest integration of Jira software, which streamlines collaboration between the service desk, DevOps, and operations. Check it out in their marketplace.[/su_note]