Any views expressed within media held on this service are those of the contributors, should not be taken as approved or endorsed by the University, and do not necessarily reflect the views of the University in respect of any particular issue.

ITIL Tattle

ITIL Tattle

Blog posts on ITIL and ITSM news and best practice from the ISG ITIL Team

Making an Impact

Both Robert and I have recently talked about Risk, which is one of the key factors we use to categorise Changes into Minor, Significant or Major types. The other factor that plays into this categorisation is Impact.

How we categorise Changes is important, because it affects how they can be authorised for Release, as well as the type of oversight we apply. So to that end, in today’s blog I want to talk about what “Impact” means to us.

In the context of planning to make Changes, Impact is really shorthand for “expected impact”. When descriping an expected impact, you should be able to be pretty specific about what’s going to happen.

We do care about the possibility of other outcomes other than the impact that we expect, but reviewing the potential for those other outcomes is once again more in the preserve of risk.

Think of it like this – Impact is what we expect to happen. Risk is more about whether it’s correct to expect that. The lower our confidence in our expected impact, the higher our perception of risk.

Likewise, the more we are certain of the impact, the lower our perception of the risk – even if the impact is serious. There is always some comfort to be taken from certainty.


The Barringer crater

Well, almost always.


Although there’s a definite relationship between impact and risk, it’s not really quite that proportional, because lots of  factors affect risk. However, to the extent that we talk about planned outages being risky, we’re usually not thinking about the “risk” that the service will be unavailable. That’s not a risk… we already know the service will be unavailable; it’s part of the plan. At that point something has gone wrong if the service isn’t unavailable.

No, the risks around planned outages that we’re usually thinking about are things like reputational risk, risk to the business, risk that we will later not be able to recover when or how we say, and so on.

So that’s some of the interplay between risk and impact. The real takeaway is that confidence in our expected impact lowers risk, and some of the everyday things we do such as testing our releases make up a huge part of gaining that confidence.

The other big steer on impact, is that we should think in terms of the services we offer, and not just the technology or resources that support the service.

So if a bit of our service infrastructure, such as a virtual server, or a physical study space, is affected by a change, we should really be thinking about what that means for the services we offer (and by extension for users of our services).

If a change means that a popular study area will be completely unavailable for six hours that could be unacceptable to our users.  However, if the building that the space is in is normally closed during the time the work is scheduled… then there is no change in the level of service we are offering.

It makes no odds to customers if for some reason we are periodically unable to offer a service, so long as that happens during a time at which we already don’t offer that service (or, more accuately, where there is no demand for it).

But that logic cuts both ways – our users won’t be impressed if we nominally continue to offer a service, but they can’t access it for some reason. That means that generating approval for a Release is not necessarily going to be as simple as describing how the thing we’re working on responds directly to the work we’re doing.

It is much more about how users of our services feel the effects of our work.

For example, if users can’t log into their email, it doesn’t matter if behind the scenes it is working perfectly.

Well, it probably matters to us. But it doesn’t matter to our users, and they’ll find it frankly insulting if we tell them there’s nothing wrong with a service they can’t access.

For that reason, we want to consider Impact in terms of its effect on service levels.

For mature services, we might already have very tight definitions of what service levels are to be expected, hopefully even levels which not just stated, but even agreed with stakeholders. In some cases, we might just have to go by slightly more by rule of thumb.

It’s very helpful if we can agree those levels, because without a mutual agreement our users are probably more likely to tell us what is acceptable to them, than we are to be able to tell them what to accept.

Either way, in the final analysis, it is deviations from the expected level of service that we think of as impact.

Leave a reply


Report this page

To report inappropriate content on this page, please use the form below. Upon receiving your report, we will be in touch as per the Take Down Policy of the service.

Please note that personal data collected through this form is used and stored for the purposes of processing this report and communication with you.

If you are unable to report a concern about content via this form please contact the Service Owner.

Please enter an email address you wish to be contacted on. Please describe the unacceptable content in sufficient detail to allow us to locate it, and why you consider it to be unacceptable.
By submitting this report, you accept that it is accurate and that fraudulent or nuisance complaints may result in action by the University.