The first time I heard the term “unplanned work” it was like a light bulb switched on in my head. I’m not sure my brain even recognised the distinction between different types of work before I heard this term. It was all just work to me.
You’ve probably read the descriptions of the types of work from one methodology or another before, but just to summarise you could break it down to three types:
- External Projects. This is project work done for your customers. Depending on where you work, your customers could be external to the company, or a different department in the company.
- Internal Projects. This is project work done within the team to improve your situation. It could be refactoring stuff, patching, upgrades, improving your tooling and processes, or automation of tasks. You get the idea.
- Unplanned Work. This is stuff that comes out of the blue and forces you to drop what you are doing and look at it. Maybe a priority 1 incident.
Some people add a forth type of work.
- Updates and Changes : I prefer to think of these as part of External or Internal projects, but depending on the size you may break them out to a separate category if it helps you handle them.
The first two are planned work, since they are both projects, where you should have an idea of the resources required and the time they will take. This is true of the updates and changes too. As the name suggests, unplanned work is unplanned. 🙂 You can add some slippage time into your projects to allow for interruptions by unplanned work, but ultimately you never know if it’s going to be enough.
So what’s this got to do with automation? Well to put it bluntly, when you do stuff manually you are going to screw up and have inconsistencies between your environments. Later you will do something that you’ve done “a million times before”, knowing exactly how long it’s going to take, it will fail and you’ll lose a bunch of time trying to figure out what went wrong and how to fix it. While you are doing that, all the work you should have been doing is not happening and the list of people screaming at you is getting longer by the minute.
It can easily get to the point where you are constantly firefighting, bouncing from one problem to the next, and never make any headway with your projects. Welcome to the world on unplanned work, population you!
I’m not trying to make out automation is 100% guaranteed to prevent unplanned work, but there are a whole bunch of cases where it’s going to reduce the incidence of problems, or make resolution of those problems simpler.
Check out the rest of the series here.
Cheers
Tim…
Also, if your planned work is largely automated it ‘could’ just run in the background while you’re dealing with the unplanned crap.
You’ve got to be careful defining “something that you’ve done “a million times before”” and submitting it to automation. Edge cases can bite you !
Unplanned work that arises out of incidents with known causes and fixes could well be avoided or mitigated with automation upfront. Aren’t “threshold alerts” a form of automation ?
Also, imho, there is always unplanned work that doesn’t have a “ready script” that you or your automation-engine can take and run.
Hemant: Agreed. Nothing is ever perfect and it will need someone for the edge cases. A few edge cases isn’t a reason not to do it it though. I know you understand this, but there are plenty of people that will have use this as a diversion, so it’s important to understand how this couple be interpreted.
Anything that automates a task, like checking backups and space, is still automation. Completing the picture would obviously be to take action on that, but even if you don’t, you’ve still saved a human checking manually. 🙂
Cheers
Tim…