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.

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.

Making an Impact / ITIL Tattle by blogadmin is licensed under a Creative Commons Attribution CC BY 3.0