How to decide when to automate a task and when to refrain?

Don’t quote me on this, but every other knowledge worker, whether it’s a manager, an office worker, a developer or others wishes it was easier to do things.

“I wish I could automate this.” — Knowledge workers

But seldom does one take the time to ponder, is it even worth it.

You see, there is no such thing as a free lunch in this world.

Automation needs time to be setup, to be tested, and to be maintained. Sometimes, this exceeds the time it would have taken to just perform the task manually. Other times, the complexity of the tasks makes it so that the automation only covers half of the time needed, the other half still being performed by a person.

All these variables makes it hard to intuitively grasp whether it makes sense to try automating a given task.

This is where the concept of “ROI” and “ROI calculation” comes into play.

ROI is a term coming from the investment and business world, and means Return On Investment.

It refers to the amount of time after an investment “pays back its money”, where the profits from the investment are equal to the amount of money that was invested.

It’s a very important concept that extends far further than its origins.

As humans, several activities we do are expected to provide a return. We work to earn money, we cook to eat, we walk or drive to reach a certain place.

It is common sense that in cooking for example, it is not realistic to cook complicated meals on a daily basis. Or to walk a long way to reach a place of limited interest.

But it does make sense in some specific situations. A birthday, or a special occasion, warrants a more elaborate meal. Or a band that comes for the first time in town might justify reaching a remote place.

There’s a pattern at play here, it is a measure of Effort needed to achieve something, and the Value gotten out of it. These two aspects need to be balanced in a certain way, for the activity to make sense.

Similarly, in working situations, this pattern applies as well at different scales.

A large multinational might invest $5B and expects to earn $21B over 5 years.

Or a department in an enterprise might invest $100,000 and expect to save $500,000 in operational expenses each year.

This reasoning goes all the way to the individual worker.

An initiative to create a software solution, or to automate an activity only makes sense economically if it produces more profit or savings than the effort it required to be executed.

I would like you to keep this definition in mind:

ROI = Value / Effort

A project that generates $10 for a cost of $2 has an ROI of 5. Which is good. Let’s move on.

Now a useful factor to keep in mind as well, is the time taken for the project to deliver value, when it is ready to be used productively by its target users.

This duration is the amount of time needed to execute the project, and whatever preparation / training time in addition.

Time to value = Project duration + Preparation time

Now, this time to value only tells you how long until the project is ready. Which means that until then, you’re not able to use it and you’re either personally involved into executing this project, or you are still performing your work activities waiting for it to be ready.

It also means that at this time, the investor (you, the department, the company, whoever pays for it) has put all the time and money needed to make this project happen, so you have a negative balance equivalent to the cost of the project.

Your money = - Cost of the project ( which is < 0, boohoo !)

But you didn’t do this to lose money. You did it to either make more money, save time, or a combination of both.

This is why you should be interested in this:

The Time to Break Even is the time needed until the project generates as much benefits or savings as the amount of time and money that was invested in it.

At this time, you are slowly starting to recover because:

Your money = 0

You’re not in the red anymore! Yippee!

But again, you’re not doing this just to break even. You want to reduce the effort it takes to execute that tedious task we spoke about in the beginning, remember?

This is what ROI calculation is about. I’ll refine the definition of ROI from above in the following way:

Estimated ROI for N months = Estimated value generated in N months / Estimated effort

And when thinking in terms of time:

Estimated ROI for N months = Estimated task time saved in N months / Estimated effort

Depending on how ambitious you are, an ROI of 5 is a good benchmark to determine if a software or an automation project is worth it.

That helps to account for variability in the estimations, and keeps a good buffer for the execution of a given project.

Now those are generic formulas, and depending on the specific domain of automation, a more elaborate model is needed to calculate ROI with greater precision.

I have made this very easy by preparing all those formulas for you, for automation and software engineering projects in a comprehensive spreadsheet.

It also contains an example data set that can be used as a benchmark in different scenarios.

You can download it from here.

Expect more models to be available soon as I’m refining them.