Building the Business Case

Most automation proposals are rejected for the same reason: they are written as engineering preferences rather than as business arguments. “This deployment is manual and it should not be” is true, but it does not tell a budget owner what changes if they fund it.

The four value channels link

Automation creates value through four distinct channels. Strong proposals name which one they are pulling, because each is measured differently.

Labour displacement is the easiest to calculate and the weakest to argue, because the saved hours are diffuse and rarely appear on any budget line. Cycle time and defect reduction are harder to compute and far more persuasive, because they map directly onto revenue timing and customer-visible failure.

A defensible cost model link

The honest cost of an automation is not the build. It is build plus maintenance plus the cost of its own failures.

flowchart LR
    A[Build cost] --> D[Total cost of ownership]
    B[Annual maintenance<br/>typically 15-30% of build] --> D
    C[Failure cost<br/>automation breaks, silently or loudly] --> D
    D --> E{Compare against}
    E --> F[Manual cost:<br/>frequency x duration x rate]
    E --> G[Risk cost:<br/>error rate x blast radius]

A workable formula for the first-pass estimate:

  annual_manual_cost   = runs_per_year × minutes_per_run / 60 × loaded_hourly_rate
annual_error_cost    = runs_per_year × error_rate × average_incident_cost
annual_automation_cost = build_hours × rate / amortisation_years
                       + maintenance_fraction × build_hours × rate

payback_years = build_cost / (annual_manual_cost + annual_error_cost
                              − annual_automation_cost)
  

Two rules keep this honest:

• Use loaded cost, not salary. Loaded cost — salary plus benefits, tooling, and overhead — is typically 1.3–1.5× base salary. Using base salary understates the case, which is a strange way to lose an argument you are right about.
• Include the failure mode. Automation that fails silently is more expensive than the manual process it replaced, because the failure is discovered late. Budget for detection, not just execution.

The frequency threshold link

There is a well-known rule of thumb — automate anything you do more than three times — and it is wrong often enough to be dangerous. Frequency is only one input. A task that runs twice a year but takes two days and causes an outage when done wrong is a far better candidate than a daily two-minute task that has never gone wrong.

The usable version weighs three factors:

quadrantChart
    title Automation candidate screening
    x-axis "Low frequency" --> "High frequency"
    y-axis "Low risk if done wrong" --> "High risk if done wrong"
    quadrant-1 "Automate first"
    quadrant-2 "Automate for safety, not speed"
    quadrant-3 "Leave manual, document well"
    quadrant-4 "Automate for throughput"
    "Nightly batch job": [0.8, 0.35]
    "Production deploy": [0.75, 0.85]
    "DR failover": [0.12, 0.95]
    "Quarterly access review": [0.2, 0.7]
    "Ad-hoc data pull": [0.6, 0.15]
    "Certificate renewal": [0.35, 0.9]

The upper-left quadrant — rare but dangerous — is where most organizations under-invest. Disaster recovery failover, certificate rotation, and privileged access review all live there. They are automated not to save time but to make the outcome repeatable when it matters and nobody has recent practice.

Framing the proposal link

A proposal that gets funded generally has this shape, and fits on one page:

1. The current state, quantified. “Deploys take 90 minutes of engineer time, happen 40 times a month, and three of the last twenty caused a rollback.”
2. The specific change. Not “we will automate deployments” but “a pipeline stage that promotes an already-built artifact after automated smoke tests, with one-click rollback.”
3. What improves, in the language of the channel you chose. “Lead time from merge to production drops from 4 hours to 20 minutes; rollback drops from 45 minutes to 3.”
4. Cost and payback, with maintenance included.
5. What you will not do. Explicit scope limits are the strongest signal that the estimate is real.

Where the argument usually breaks link

• Claiming headcount reduction. It is almost never delivered, and promising it makes every other number suspect. Automation redirects capacity; say that.
• Ignoring the transition period. For a while, the team runs both the manual and automated path. Budget for that overlap explicitly.
• Automating a process nobody has fixed. Encoding a broken process makes it faster and harder to change. See Anti-Patterns and Failure Modes.
• No measurement plan. If you cannot state the metric you expect to move before you start, you will not be able to defend the investment afterward. DORA Metrics and Beyond covers the standard baseline.

Adoption checklist link

• The proposal names one primary value channel and measures it.
• Cost model includes maintenance and failure-detection cost.
• Candidates were screened on risk as well as frequency.
• A baseline measurement exists before work begins.
• Scope explicitly states what is out of scope.
• The proposal does not promise headcount reduction.