Reducing unplanned work

Through the duration of my career, projects have brought about some of my most stressful days.
 
Earlier this year I read The Phoenix Project ( http://itrevolution.com/books/phoenix-project-devops-book/ ). This book has been mentioned at pretty much every DevOps event I've attended. One part of the book that resonated with me was the discussions around "unplanned work".  The past ten years of my life would have been so different if I had never had to deal with unplanned work.
 
Sometimes things go wrong – which leads to unplanned work. Some unplanned work is hard to avoid, such as power failures, hardware failure, connectivity failure, earthquakes. You get my drift. We all do our best to avoid this sort of unplanned work. But then we have unplanned work as a result of something we have done.
 
At science lessons in school I remember bring taught, every action has an equal and opposite reaction… or something along those lines! Work we carry out that is planned is often part of a larger project. Almost every project I have ever been involved in has resulted in unplanned work of some sort – this being the reaction to our actions.
 
Projects that I have been involved in have nearly always had major milestones, resulting in D-Day – the day that the switch gets flicked. And some projects have multiple D-Days – each one often bringing fear to those involved. I'm thinking back to times I have been involved in projects such as application deployments and upgrades, email migrations, hardware upgrades etc…
 
It's making me shake. Why have I spent my career working on projects with major milestones? Not just one project at a time, but often 10 projects simultaneously. Some have gone well, which is great, but not much needs to be said about these. Others have had their issues. I still have projects I hate to think about because of something that went wrong. I'm sure many of you have nightmare projects that you just wish you could forget.
 
But as IT Professionals/SysAdmins/Developers (whatever our role) we have to work on projects – don't we? If we could eliminate projects, could we not vastly reduce or even eliminate unplanned work? Perhaps we can't eliminate projects, but can we make them smaller?
 
If we reduce the number of major changes, then the risk of unplanned work decreases. Yes, we might still have some unplanned work but if we implement small changes then the impact of any resulting issues that need resolving should be reduced. We will know exactly what's changed, and how to resolve or roll back the change.
 
The whole DevOps mantra around continuous delivery makes sense. I believe this is true for the majority of projects, not just software development. 
 
I am asking myself why have I been involved in so many projects lasting months if not years?
 
Next time you need to deliver a project, it might be time to think about delivering it continuously…
 
 
To find out more about DevOps practices such as continous delivery watch the DevOps Fundementals series on Channel9 .
 
 

2 Comments

  1. Andrew Bettany

    I see where you are coming from, but have we also been taught to dream big, win big, so to play it small sounds somehow wrong. Can you give a real world example? Building a bridge or buidling a new datacenter is a project – how would this be delivered in a continuous fashion?

    Reply
    1. Marcus (Post author)

      You can still dream big, but need to do it in small steps. Otherwise it’s a lot harder to get to the destination. It’s the concept of creating a Minimal Viable Product, rather than waiting until you have a full featured solution, by which time you have missed the boat. With a datacentre migration for example, dont move everything over one weekend. Do a few services a week over a number of months. It takes longer, but service levels are improved as a result.

      Reply

Leave a Comment

Your email address will not be published. Required fields are marked *