The time for improvement

Jan 25, 2022 · 5 min read ·

A recent exchange on Twitter started me thinking about when do I take the opportunity to introduce something new, or better, into the projects I’m working on. How do we balance a project deadline against the longer-term benefits of improving and automating?

Is the incentive the lower ongoing maintenance? This is my push when that sort of choice comes up- we can do this on-prem/IaaS, but we then are dealing with the upkeep. A PaaS/SaaS route *should* make less work for us to keep it running + secure beyond day 2.
— Chris Bradshaw (@aldershotchris) January 24, 2022

When presented with a problem/task/challenge you have conquered before it is common sense to use that previous experience and use the solution you know how to implement, leveraging your existing skills. This often gets the work completed in the shortest amount of time, but perhaps misses an opportunity to improve the solution or maybe automate it’s implementation so that time is saved in the future.

When there’s a discussion around investing time now to save time in the future, someone will often refer to this comic from xkcd.com.

We can use this handy chart to work out how much time is saved by making regular tasks more efficient. If we have to provide a solution that does X once a month, and we can spend less than a day now writing some PowerShell that makes it 30 minutes quicker to deploy that same solution next time then we’ve saved time over the next 5 years.

If we take the example brought up by Keith Townsend (@CTOAdvisor) in the Twitter discussion that started my train of thought- he was discussing the choice of deploying a Windows DHCP server, a quick and easy task with his skills and experience, or spending time learning the skills to make an equivalent service using new cloud technologies. In my opinion, the incentive to do the latter is the longer term benefits and the future time-savings they generate. A “cloud” (and by that I infer PaaS/ SaaS) solution should reduce the amount of ongoing work to keep it running and secure- no managing Windows Updates for example.

If we refer back to the xkcd.com comic above, we can see that if we deploy our solution to X, but can spend a day now taking 30 minutes off the monthly maintenance time we’ve made savings over five years. Perhaps switching to that SaaS solution took an afternoon to learn how to implement, but the operations team no longer have to spend time dealing with patching schedules, antivirus updates, and annual upgrades.

Keith quite rightly points out in his reply that spending this extra time may not work with his deadline and this is the crux of this decision. We sadly don’t live in an ideal world where deadlines can be ignored and it can be a challenge to explain to the customer that something is going to take longer to provide because you’re learning something new, or you’re putting in a better solution because it will save you (but not necessarily them) time in the future. This is particularly the case when that extra work is around a supporting system (such as this DHCP server) rather than a component which is seen as delivering real value to the customer.

Some great things can be made when deadlines are ignored:

“I love deadlines. I love the whooshing noise they make as they go by.”

Douglas Adams

But assuming that the deadline has to be met, how do we make this decision when to invest time improving something?

Being able to estimate how long it will take to learn/ develop / implement the new improvement would be a useful skill- can you fit this into your project timeline or not? If an estimate is not forthcoming, is it possible to allocate some time to investigating or attempting anyway? Being disciplined with your time here and working in a similar mentality to a Sprint can work. You could say something like.

“I’m going to spend 1 hour looking at this, and if it isn’t working (or achieved this predetermined milestone) in that time I’m going to shelve the improvement and proceed with the known solution.”

By doing this you’ve allowed time to investigate the feasibility of making the improvement, but not allowed that to overrun and impact your project delivery. If you do run out of time, make a note of the idea and any progress made and try and revisit it after the project has been delivered. Of course, you might not have that spare hour if the deadline is really tight. Again, this is where it’s important to record that idea so that it can be investigated later.

Allocating time between projects for improvement work is a good idea. It can be difficult in a small operation where resources are limited, and perhaps easier in a large team where the time spent not directly working on a particular project can be absorbed whilst the deadlines are still being met and solutions delivered. Scale helps, but so does recognising what the improvement can give to you.

Reporting back the benefits after the fact is important. It’s vital to be able to show to your management, board, or even just yourself that you spent hours working on improvements or automation, but that has reduced the delivery time/ maintenance work/ overheads of future projects by days. Being able to quantify it like that is ideal, and being able to show that the activity was worthwhile will open the doors for more improvements to be made in the future.

To summarise; your project deadlines will always be important, that’s why you’re at work! But try and make the time to focus on the improvements as well- be they modernisation, automation, or personal development - and try to do so in a way that you can show the benefits that investing that time and effort has made. Finally, don’t forget that new skills you pick up on the journey will almost certainly come in handy in the future.

Signpost thumbnail image by Gerd Altmann from Pixabay. Douglas Adams quote from “Hitchhiker: A Biography of Douglas Adams”, M.J. Simpson. Stopwatch image by AbsolutVision from Pixabay.