On Efficiency: When can the slowest be the fastest?

I’ve got a neat little tip here on thinking about efficiency.

Here’s a question for you: When can the slowest, be the fastest?

It’s when being “slow” in one area allows you to achieve significant speed gains in another, creating an overall increase in efficiency.

Allow me to explain.

As you may know, I’m currently working as a (slightly pseudo) business analyst. Part of our work involves creating systems or progams to help process reports (including VBA programming, Access queries, Excel spreadsheet manipulation, and others).

Sometimes I come across situations where I have to choose between creating a program that takes the system 10 minutes to process, or one that takes the system 5 minutes to process but requires manual intervention along the way (for example, date changes or the entering of any sort of data).

If you were in my shoes, which would you choose?

I almost always choose the one without manual intervention. Firstly, because manual intervention needlessly introduces the possibility of human error (which when it does happen can take a long time debugging); and secondly, because having the program fully automated buys you time to do other things. It is this second point that I’d like to stress.

Taking the situation I mentioned above as an example, the automatic system effectively gives you 10 minutes of time, as it allows you to be away while the program runs. On the other hand, the manual system takes 5 minutes of time since you have to be present while the program runs. There’s a fifteen minute time difference here.

Always look at the bigger picture when deciding if the “slower” option truly is slower, for it may just allow you to be faster in the greater scheme of things.