There’s a natural tendency when improving an IT process to add things.
Add another check. Add another approval. Add another step. Add another bit of information.
It makes sense. If something is missing, you add it.
But sometimes the better improvement is to remove something.
I’ve recently reviewed and cleaned up a fair bit of documentation, comparing how the documented process actually reflected the process in place. One of the documents that stood out to me was a Joiner, Mover and Leaver process, and how much old information can build up over time.
Not because anyone has done anything wrong.
The environment just changes.
The process can change without the document changing#
IT environments don’t stand still. Systems get replaced, platforms get retired, responsibilities move between teams and the way people access services changes. Things that were once essential can eventually become irrelevant.
The problem is that documentation doesn’t always change at the same speed.
You can end up with a process containing instructions for systems or actions that haven’t been relevant for a long time. The document still exists and it still looks reasonably complete, but parts of it no longer describe what actually happens.
That’s what I found when reviewing the JML documentation. There were legacy steps relating to systems and administration that were no longer relevant to the current environment.
They didn’t need improving.
They needed removing.
“Just ignore that step” isn’t really a solution#
One option when you find old documentation is to leave the step there and add a note.
Something like:
This step is no longer required.
That technically tells the reader what to do. But it still leaves the old instruction sitting in the middle of the process.
Now someone has to read it, understand that it doesn’t apply, and remember to ignore it. That’s not really simplifying the process. It’s just adding another decision for the person following it.
If a step genuinely isn’t required anymore, I’d rather remove it.
The person following the process shouldn’t have to know the history of the environment to understand what they’re supposed to do today.
JML is a good example#
Joiner, Mover and Leaver processes can involve multiple systems, teams and types of access. A new starter needs the right accounts and equipment. Someone changing roles may need their existing access reviewed. Someone leaving will need their access removed and equipment dealt with appropriately.
There are already enough moving parts without adding instructions that no longer apply.
If an engineer is working through a leaver process and the documentation tells them to perform an action in a system that isn’t used anymore, that’s unnecessary friction.
They might know to ignore it. Someone new to the environment might not. They might spend time looking for the system, asking someone else, or wondering whether they’ve missed something.
None of that is a major incident, but it’s wasted time. Repeated often enough, small amounts of friction start to matter.
Sometimes removing something is the improvement#
This is something I’ve started to appreciate more as I’ve gained experience.
Improvement doesn’t always have to be visible as something new. Sometimes the improvement is that something unnecessary isn’t there anymore.
There’s a natural instinct to make documentation more detailed when we’re trying to make it better. But a useful question when reviewing a process is:
What can we remove?
Does this step still exist because it is needed, or because it has always been there?
If it’s needed, keep it. If it’s changed, update it. If it isn’t needed anymore, remove it.
That doesn’t mean removing things just to make a process shorter. You still need to understand why something exists before deciding it can go.
A step might look unnecessary but have a good reason behind it. That’s why reviewing the process itself matters, rather than simply editing the document.
There’s a service impact too#
It’s easy to think of JML as an internal administrative process, but there’s a service behind it.
A joiner needs to be ready to work. A mover needs the right access for their role. A leaver needs their access dealt with appropriately.
The people affected by those changes don’t particularly care what the internal process looks like. They just need the outcome to happen properly.
That means the process supporting it needs to be clear, accurate and usable by the people carrying it out, especially in a support environment where different engineers may handle the same type of request.
Sometimes improvement is smaller than you think#
I think this is something I’ve started to appreciate more as I’ve gained experience in IT support.
When you hear “improvement”, it’s easy to imagine a big project, a new system or a complete redesign of how something works.
It doesn’t always have to be that.
Sometimes you notice that something isn’t quite right, work out why, make a sensible change and leave things a little better than you found them.
That’s essentially what this piece of work felt like. There wasn’t a need to reinvent the JML process. It just needed some of the history taken out of it.
It’s another example of how my view of support has changed#
Earlier in my IT career, I probably would have looked at a process and thought about whether I could follow it to complete the task.
Now I’m more interested in the process itself.
Does it make sense? Does it reflect the environment? Is there anything unnecessary? Would someone else know what to do?
And perhaps most importantly:
Are we doing something because it is actually needed, or because we’ve always done it that way?
I don’t think every process needs constant attention. But environments change, and processes need to keep up with them.
Sometimes that means adding something. Sometimes it means changing something. And sometimes, the best improvement is simply removing something that no longer belongs there.
A few old steps disappear. The process becomes a little clearer. The next engineer has less to work out.
It might not look like a big change, but if it makes the work easier and more consistent, I’d count that as a worthwhile improvement.
Sometimes good IT service management isn’t about doing more.
Sometimes it’s about making sure we’re only doing what still needs to be done.