Prepnicalities is a horrific portmanteau that I’ve created just for the purposes of this blog post.

It’s such an awful combination, that I’m hoping it’s memorable. Or at least, that it sticks in your craw long enough for me to illustrate the concept I’m outlining in this post.

The thing is, considering Changes isn’t usually about technicalities. It’s about practicalities. It’s about how prepared we are… both for the things we expect and, to an extent, for the things we don’t expect.

Prepared by Nick Youngson CC BY-SA 3.0 Alpha Stock Images

The word “technicality” can be interpreted in a couple of ways… frankly, both of which can apply to the popular perception of Change Management.

Firstly, technicalities can refer plainly to the (over)use of technical terms or methods.

Secondly, and the more common meaning, technicalities can refer to the small print, the fine details around of a set of rules, particularly when contrasted with the intent or purpose of those rules

And that’s the perception of Change & Release Management that I’d like to be able to move away from, in a nutshell. The idea that it’s about extracting a series of dry technical facts, and then saying “no” on the basis of an uncrossed “t” in the rollback plan.

In fact both the facts about the Change, and the decision to proceed or otherwise, should be supremely relevant to the services we are running, and the way in which they support the business.

Firstly, a lot of changes have little or no technical component to consider. Take for example a change to the hours of availability of a service, or expanding the availability of a study space to a new set of users. It’s possible that you may have to consider some technical matters along the way – door access scanners and so forth – but ultimately these are non-technical changes. There are plenty such changes, the practical effects of which we should still be trying to consider.

But further; when we review Changes, we’re almost not interested in the technical side of them.

I try to be as clear as possible when running CAB that we’re not asking for technical details about how a change will be conducted, but rather the practical information about what this means for the services we run, and for the people who use them.

The problem is, I’m really not asking for something simpler, when I ask for that information. I’m usually asking for something much, much harder to provide.

It sounds unintuitive that “technicalities” could be the simple way to answer. But the truth is that it’s people that aren’t simple, and it’s people to whom we provide services.

Put another way, even relatively non-technically-minded people will very quickly tend to find that it’s a lot easier to explain what’s going to happen to a piece of technology, than it is to explain what is going to happen to the people using it.

Plus, while we might blithely state that we’re not interested in technical matters, but only the impact on services, the truth is that in order to understand the impact on services, you will often need to weigh in the technical considerations, so what we can be properly be understood to be asking for is the condensed output of that kind of work, rather than its absence.

So how do we handle this? Well, we simplify it as much as we reasonably can. That’s where the Prepnicalities portmanteau comes in.

In a sense, we do need to break down our consideration of changes into small sets of digestible information. We need it to be repeatable for consistency, and we need it to be understandable, too. In a sense, we do need “technicalities”, but we don’t want them to be technical, we want them to be about preparedness. Hence, prepnicalities. Finally, we want them to align as completely as possible with the intent or purpose of, for example, Release Management, so that we can align our process more in sync with the spirit of the process.

As I’ve said before, a great part of Change & Release Management is about information curation. This is more of that.

In the case of Go CAB, we need to know that we’re prepared,  that work which is being planned is safe, that it doesn’t conflict with other planned releases or events, and that there are no reasons why it shouldn’t go ahead as planned.

The “prepnicalities” we’re interested in therefore include knowing what doing the work will mean for our services (and their users), that what we’re planning is likely to work/low risk (testing helps with this), and confidence that we would know what our next steps should be if something were to go wrong (usually a rollback plan, but not always).

These chunks of information are the kind of fine detail we’re asking for, neatly packaged. But they don’t meet the standard view of what constitutes “technicalities”, because they’re usually not inherently technical, nor are they just mindless busywork, at odds with the function of Release Management.

There you have it. Prepnicalities. Let’s hope it doesn’t catch on. Like I said, it’s a terrible word. But, perhaps, a useful illustration.

Prepnicalities / ITIL Tattle by blogadmin is licensed under a Creative Commons Attribution CC BY 3.0