Value × Complexity: how we prioritize what to automate

The problem: backlogs ordered by whoever shouts loudest

Almost every operations team has more automation ideas than capacity to build them. Scripts someone promised, repetitive tasks nobody wants to do, audit requests, improvements suggested after an incident. The problem is rarely a lack of candidates. The problem is the order.

Without an explicit criterion, the backlog sorts itself, and almost always badly. Whatever the most senior manager asks for rises to the top, along with whatever caused the last visible incident or whatever an engineer finds interesting to build. Quiet tasks that eat hours every week sink, and so do controls that would reduce a compliance risk nobody raises until the next audit.

The outcome is familiar: automations that took weeks and save little, ambitious projects that stall halfway, and a team that loses credibility with the business. To avoid this we use a simple framework, which we call Value × Complexity, to define, classify and prioritize the automation backlog.

Three steps: define, classify, prioritize

The framework has three steps applied to every candidate, plus one maintenance rule.

1. Define. Each candidate is documented in an intake sheet with the same fields: process, trigger, frequency, volume, systems involved, owner, expected outcome and current risk. No complete sheet, no score.
2. Classify. The candidate is scored on two axes, Value and Complexity, each from 1 to 5. The cut-off between "high" and "low" is 3.
3. Prioritize. The combination of both axes places the candidate in one of four quadrants, and each quadrant has its own handling rule.

On top of that comes the maintenance rule: the backlog is re-scored periodically, for example every quarter, because value and complexity change over time.

The intake sheet may look like bureaucracy, but it does a concrete job. It forces whoever proposes an automation to describe the real process, and it exposes the cases where nobody knows how often a task happens or who owns it. That gap is useful information in itself.

The two axes and their factors

Each axis is the average of several factors, all scored from 1 to 5. Averaging instead of relying on an overall impression forces separate conversations: a task may save few hours and still carry a lot of value because it reduces a serious risk.

Value

The Value axis is the average of four factors:

• Effort saved: hours per month freed.
• Risk and error reduction: how much the probability or impact of a human error goes down.
• Customer or SLA impact: whether the automation shortens response times or prevents service level breaches.
• Compliance or audit contribution: whether it leaves traceable evidence, applies a control consistently or answers a regulatory requirement.

Complexity

The Complexity axis is the average of five factors:

• Number of systems and integrations the automation must touch.
• Process variability: how many exceptions it has in practice.
• Data quality and available access: whether there are APIs, service credentials and reliable data, or everything depends on screens and manual files.
• Risk of the change in production: what happens if the automation fails halfway.
• Third-party dependency: vendors, other departments or platforms you do not control.

Each factor deserves an explicit rubric, calibrated with the organization's own data, so that two people score the same candidate the same way.

The four quadrants

With the cut-off at 3, every candidate lands in one of four quadrants:

	Low complexity	High complexity
High value	Quick wins: done first.	Strategic bets: split into smaller deliveries and planned.
Low value	Opportunistic fixes: when there is spare capacity or as training.	Drop or redesign: not automated as is; simplify the process first.

Each quadrant has its own logic:

• Quick wins (high value, low complexity). They go first because they deliver visible results quickly and fund confidence in the program. A team that shows three quick wins in a quarter finds it easier to get room for a big bet.
• Strategic bets (high value, high complexity). They are worth it, but not as a single project. They are split into smaller deliveries, each with value of its own, and planned with milestones.
• Opportunistic fixes (low value, low complexity). Useful to fill spare capacity or to let a newcomer learn the automation platform without risk.
• Drop or redesign (low value, high complexity). Automating a messy process only produces a faster messy process. Simplify first, then score again.

A complete example

Illustrative example. The candidates and scores below are fictional. They show how the framework works and do not describe any real organization.

Picture the IT operations team of a mid-sized insurer with six candidates in its backlog. Value scores follow the order effort, risk, customer or SLA, compliance. Complexity scores follow the order systems, variability, data and access, change risk, third parties.

Candidate	Value factors	Value	Complexity factors	Complexity	Quadrant
A. Controlled restart of a service on a known alert	3, 4, 4, 2	3.25	2, 2, 2, 3, 1	2.0	Quick wins
B. User joiners and leavers in the directory and six applications	4, 5, 2, 5	4.0	5, 4, 3, 3, 3	3.6	Strategic bets
C. Monthly capacity report built by hand in a spreadsheet	2, 2, 1, 2	1.75	2, 1, 2, 1, 1	1.4	Opportunistic fixes
D. Inventory reconciliation with a vendor that keeps changing its file format	2, 2, 1, 3	2.0	3, 5, 4, 2, 5	3.8	Drop or redesign
E. TLS certificate renewal before expiry	2, 5, 5, 3	3.75	3, 2, 2, 3, 2	2.4	Quick wins
F. Operating system patching on servers	5, 4, 3, 4	4.0	3, 4, 3, 4, 2	3.2	Strategic bets

Within each quadrant we recommend sorting by descending value and, on a tie, by lower complexity. The resulting order is:

1. E. Certificate renewal (quick win, value 3.75). An expired certificate can take a service offline; risk and customer impact outweigh the hours.
2. A. Controlled restart (quick win, value 3.25). It shortens recovery time for a repeated, well understood failure.
3. F. Operating system patching (strategic bet, value 4.0, complexity 3.2). Split into deliveries: first the inventory and patch compliance report, then a pilot group of non-critical servers, then windows by criticality.
4. B. User joiners and leavers (strategic bet, value 4.0, complexity 3.6). It ties with F on value and comes after it on higher complexity. A reasonable first delivery is to automate only leavers in the directory, where the risk of orphaned access concentrates.
5. C. Capacity report (opportunistic fix). A good exercise for someone joining the team.
6. D. Vendor reconciliation (drop or redesign). Not automated in its current form. First agree on a stable format with the vendor and reduce the exceptions.

Notice what the framework made visible. Reconciliation D was probably the loudest request, because it hurts every month. But automating it today would mean building on a format that changes without notice. And certificate renewal, which nobody was urgently asking for, rises to first place because of the risk it prevents.

Re-scoring: the backlog is not a snapshot

Scores age. A vendor publishes an API and an integration becomes simpler. A new audit requirement raises the value of a control. A process is redesigned and leaves the drop quadrant. That is why the framework includes a periodic review; we suggest a quarterly cadence.

In each review it pays to:

• Review new intake sheets and complete the ones left half done.
• Re-score candidates whose context changed: replaced systems, redesigned processes, new compliance requirements.
• Compare the estimated value of automations already built with the observed value, to calibrate how the team scores.
• Move to "Drop or redesign" whatever has gone several quarters without progress, and ask why.

That review needs an owner, defined participants and a few metrics reported the same way every time.

What the framework does not do

Value × Complexity does not replace judgment. It makes that judgment explicit so it can be discussed with data rather than impressions. Two people may score the same factor differently; that difference is exactly the conversation worth having before investing weeks of engineering.

Nor does it pick the tool. A candidate may be solved with an Ansible playbook, a workflow in the service management platform or a scheduled script. The framework only says what to do first and what not to do yet.