What’s the Difference Between an Unsuccessful Change and a Failed Change?

15 Dec, 2016

Check out our Resources Page and Analytical Reporting Knowledge Base for exciting new IT Operations & Support content every month!

Lee Cullom, 10/7/2011

What’s the difference between a Failed Change and Unsuccessful Change?

While this month presents another simple 2 metrics, which are also KPIs for many IT orgs, we figured that it gives us time to focus on an important first principle of any successful business intelligence, data science & analytics implementations in general. nomenclature.

We can all agree that metrics (useful or not) bring a new level of visibility of the performance of an organization. With this increased visibility comes a need for increased communication about the effectiveness (or lack thereof) associated with the new information at one’s fingertips. So… what do we mean when we say emergency change, failed change or expedited change? Are we speaking the same language?  Frankly, It’s highly unlikely in a large department or business unit.

Now, this might remind you of the famous Clintonism around the definition of “is”, back in the day, but …

There is this real issue of nomenclature that needs to addressed in terms of communication around newly established metrics and KPIs with agreement on nomenclature intentionally. Establishing proper nomenclature is a primary objective, when using the formal language of ITIL. So, what happens when you start sharing your unsuccessful change metric without a shared, precise understanding of meaning? Potentially, a meeting that goes sideways, at length, with everyone’s previous experiences at different IT organizations in an attempt to prove themselvs right, or simply gain sanity.  What’s worse, no one may understand, or ever get to the topic about what the metric means or how it was calculated. This could be compounded by the fact that you might have bonuses or MBOs tied to performance around these metrics. So, the stakes can be high.  If possible, agree on nomenclature early in the discussion, or perhaps even better, present your definition and ask for alternate interpretations.

None of this is to say the increased communication and visibility is harmful. In fact, the flip side of these sometimes contentious discussions is that we can see that people really do care about the performance of the company, their department and more specific goals, which might helps leadership consume ideas that benefit your organization which hadn’t been considered.

Bottom Line:

Understand what you are calculating (from the data model, because it is a limiting factor), what it means (nomenclature – Failed Change vs. Unsuccessful) and why you are calculating it (Business/IT methodology), along with a communication plan.  This will help you foster ideas and build consensus.

Metric(s) of the Month for September and October, Change Management for BMC Remedy ITSM:

Failed Change Request – “Change Requests with a Status Reason of ‘Unsuccessful’ or ‘Backed Out’, a Status of ‘Completed’ or ‘Closed'” and a Change Type of ‘Change'”

Unsuccessful Changes – “Change Requests with a Status Reason of ‘Successful with Issues’, ‘Backed Out’, a Status of ‘Completed’, ‘Closed’, or ‘Cancelled’, and has a Change Type of ‘Change'”

Again, keep in mind that the metrics above are Remedy ITSM 7.X (and above) specific metrics. In our metrics catalog, we define over 4,000 metrics and KPIs across 15 process areas (subject matter). Of course, they’re nicely organized so as not to overwhelm you with metric nausea (check out the knowledge base for examples). Our ServiceNow solution will be released in February, 2011. We currently support Remedy ITSM, custom Remedy and any relational back-end with services.

Of course, it always depends on your processes, people and ITSM configuration!