Skip to content
Queensferry

Module 4 · Lesson 4.2

Should this be automated?

The calculation nobody does, and the reason automating a bad process makes it worse.

Why this matters

Automation is nearly always justified by 'it will save time' and nearly never by a calculation. Sometimes it does save time. Sometimes it costs three days to save twenty minutes, and the twenty minutes was going to be spent by somebody who now has to learn a tool instead.

This lesson makes the argument arithmetic, and then makes the more important point that the arithmetic is not the whole decision.

The terms

Development time. Honestly estimated, which means roughly double your first instinct. Include the time to make it usable by somebody else.

Frequency. How often the task recurs, over what period. A task done once is not a candidate however tedious it is.

Users. One person, a team, or the office. Ten users multiply the benefit — and multiply the cost of getting it wrong.

Time saved per run. Including the checking that no longer has to happen manually, which is often the larger share.

Checking effort. A tool needs verifying once, thoroughly. That is a cost, and it is a cost that recurs every time the tool changes.

Maintenance. Software rots. Section catalogues are updated, file formats change, the person who wrote it leaves. Budget for it or the tool becomes a liability the year after it was written.

Risk. What happens if it is wrong and nobody notices? A tool that drafts a schedule is low risk. A tool that sizes members is not, and the checking effort has to be proportionate.

The calculation

Benefit over the period is (runs × users × time saved). Cost is (development + verification + maintenance). The tool is worth building when the first comfortably exceeds the second — comfortably, because the estimate on the left is optimistic and the one on the right is not.

But the arithmetic is only the first gate, and there is a second.

Automating a bad process

Automating a flawed process does not fix it. It produces flawed results faster, in greater volume, and with the authority that comes from a computer having produced them.

The worst outcome is not a tool that fails. It is a tool that works exactly as built, embedding a mistaken assumption, applied two hundred times before anyone looks closely. The manual version made the assumption too — but the manual version was slow enough that somebody noticed.

So the question before 'can this be automated' is 'is this process right'. Automating a check that omits a load case gives you a fast, consistent, thoroughly documented omission.

Try it

Should this be automated?

Enter the real numbers, including the ones people leave out. The verdict is withheld until the risk question is answered.

days
days
days

Catalogues change, formats change, people leave. Zero is rarely honest.

h

Include the checking that no longer has to happen by hand.

If it is wrong and nobody notices, what happens?

Build cost
53 h

development plus verification

Maintenance
15 h/year
Gross benefit
40 h/year
Net benefit
25 h/year

gross benefit less maintenance

Payback
2.1 years
Break-even runs per year
13.5

runs needed in year one to cover build plus maintenance

No verdict yet. The arithmetic above is only half the decision — answer the risk question, because it sets how much verification is proportionate, and verification is a cost you have already entered.

The question this calculator cannot answer

  • Is the process you are about to automate correct? Automating a check that omits a load case gives you a fast, consistent, thoroughly documented omission — applied to every project, with the authority of having come from a tool.
  • Who will own it when its author leaves? An unowned tool becomes an unmaintained tool, and an unmaintained tool becomes a liability the year after it was written.

What this shows: Automation pays back development, verification AND maintenance — and the arithmetic is the second question, not the first.

Worked example

A connection-schedule tool

Given

  • Producing a connection schedule by hand takes 6 hours per project
  • The tool would take an estimated 5 days to build and 2 days to verify
  • The office does 8 such projects a year
  • The tool would reduce the task to 1 hour, including checking its output
  • Maintenance is estimated at 2 days a year

Find

Whether the tool pays back, and over what period

    Practice

    A script takes 12 hours to write and verify, saves 15 minutes per run, and is used by 4 engineers. How many runs per engineer are needed to break even? Give the number of runs per engineer.

    Practice

    A task takes 6 minutes and is done 40 times. Automating it takes 5 hours to write and 2 hours to verify. How many minutes are saved, net?

    Check yourself

    Which cost is most often left out of a decision to automate?

    Check yourself

    A repetitive task is a candidate for automation. What question should come before 'how do I automate this?'

    Summary

    • Count development, verification and maintenance, not just development
    • Frequency and number of users are what make automation pay
    • Risk sets how much verification is proportionate
    • Ask whether the process is right before asking whether it can be automated
    • A fast, consistent, well-documented omission is still an omission
    Progress is kept in this browser only.

    This is educational material. It uses simplified examples to teach principles, and must not be relied on for real design or safety-critical decisions. Module overview and checkpoint