Outside CTO for automation: map scope before costs rise

Why automation projects look smaller than they are

Most teams estimate the happy path.

A form gets submitted, a rule checks it, someone approves it, and the task moves on. On paper, that looks clean and cheap.

Real work is messier. People send the wrong file, approve the wrong request, change their mind after approval, or ask for a one off exception for a customer, vendor, or internal policy. Every one of those moments adds another branch. Those branches pile up fast.

A reversal is not a small detail. If a team needs to undo an approval, reopen a record, or fix a bad status, the system often needs extra screens, rules, notifications, audit logs, and tests. One "simple fix" can double the work for that step.

Special cases push scope even harder. A single exception can change the fields a person must fill in, who can approve the request, what happens when data is missing, what the system stores for audit, and what the team has to test before launch.

This is where budgets start to crack. A workflow that looked like six steps turns into six main steps plus ten side paths. Teams often discover those paths in week four instead of week one. By then, design is already done, the build is underway, and every change costs more.

A good outside CTO often spots this sooner because they are less attached to the original diagram. They ask awkward but useful questions. What happens when someone clicks approve by mistake? Who can override the rule? How often do people send work back? What does finance do when the numbers do not match?

Those questions change the estimate from "automate this workflow" to "automate this workflow, its reversals, and its exceptions." That version is less pretty, but it is closer to the truth.

If you count only the normal path, the project looks small. If you count the ways real people break, correct, pause, and reroute that path, you see the real scope before the budget disappears.

What counts as an exception

Teams usually scope automation around the cleanest version of the process. Requests arrive on time, the data is complete, and every item follows one approval route. Real work rarely looks like that.

An exception is any case that breaks the normal flow or needs a different decision. That includes more than dramatic failures. It also includes quiet workarounds that staff use every week without thinking much about them.

Refunds, reversals, and corrections are common examples. They change records that the system may already treat as final. A refund after settlement, a corrected invoice after payment, or a reversed entry at month end often needs extra checks and a clear audit trail.

Approvals that skip the usual path matter too. A manager may approve a rush order by phone. A finance lead may bypass a limit for one urgent vendor. A founder may push a deal through before the paperwork is ready. Teams call these rare cases, but they still shape the build.

Customer specific rules add another layer. One client may require a special billing cycle. Another may allow partial delivery. A third may need its own contract language before payment. If someone says, "only this customer does it that way," count it.

Bad inputs and late changes cause trouble faster than most teams expect. Missing IDs, wrong tax codes, duplicate records, and requests edited after approval all force the system to stop, ask for help, or guess. Guessing usually becomes rework.

Manual handoffs count too. If people keep work moving with spreadsheets, chat messages, side emails, or quick calls to operations, that is part of the process. The handoff may feel informal, but the business depends on it.

A few phrases usually point to hidden exceptions. "We handle that manually" is one. "Only this customer needs it" is another. So is any private checklist that lives outside the main system.

These cases are not sitting at the edge of the process. They are often the process. If even one in ten requests needs a different route, the budget should reflect that before the build starts.

Where hidden scope shows up

Hidden scope rarely sits in the official process map. It usually lives in the places people use to keep work moving when the neat path breaks.

That is why a short interview is rarely enough. Watch the team do the job. Sit with the person handling the task and follow a few real items from start to finish. When they pause, switch tabs, check a message, or ask someone else to decide, you have probably found work the budget does not cover yet.

A polished workflow diagram often shows the standard path because it is easy to explain. The expensive part sits in the exceptions people handle almost without noticing.

Some of the best places to check are boring on purpose: shared inboxes, spreadsheets that track fixes, comment fields, chat threads, CSV exports, and queues where items wait for a person to decide. These are usually the places where manual judgment hides.

Support, finance, and operations often see the hidden cases first. Support hears when the customer cannot fit the normal path. Finance sees mismatched totals, missing fields, and reversals. Operations deals with late changes, odd requests, and records that do not match reality. Ask each team for a few recent examples that needed manual fixes.

Recent cases matter more than old stories. Pull ten or twenty items from the last month that someone had to repair by hand. Look for reversals, overrides, duplicate records, missing approvals, special pricing, or anything that forced a person to stop and choose. Each stop is a scope marker.

Write those decision points down in plain language. For example, someone checks whether a customer can skip approval, whether an amount is close enough to accept, or whether a bad address can still ship. Small decisions like these pile up fast. They turn a simple automation plan into a larger project with rules, fallback paths, alerts, and human review.

If the team cannot show where those choices happen, the estimate is probably too low.

How to map the real scope

Start with a plain map of the normal process. Keep it to one page. If the team cannot explain the happy path in a few steps, they are not ready to price the exceptions.

Write each step in order, from trigger to final result. Include the system action, the person involved, and the rule that moves the work forward. Simple boxes and arrows are enough. Fancy diagrams often hide more than they reveal.

Once the normal path is clear, mark every place where the flow can split. Count reversals, pauses, manual checks, missing data, policy exceptions, and urgent approvals. These branches are where budget slips away.

A few questions usually expose the real scope:

• Where does someone stop the automation and make a judgment call?
• Where can data be incomplete, wrong, or late?
• Where does work go backward for correction or reapproval?
• Where do special customers, contracts, or regions follow different rules?
• Where does a manager override the default path?

Do not treat all exceptions the same. Group them by type first, then by frequency. A daily pricing override deserves more attention than a rare legal hold. One creates steady support work. The other may be unusual, but it still needs careful testing because it can block the whole process.

For each branch, note who approves it and why. Roles matter more than names. "Finance manager approves orders above $10,000" is useful. "Management checks large orders" is too vague to estimate. The reason matters too, because it tells you whether the rule is fixed, political, or likely to change soon.

Then estimate effort branch by branch instead of making one big guess. Every branch creates work in at least three places: build work for rules, screens, alerts, and logs; test work for normal, error, and override cases; and support work for training, exceptions, and future rule changes.

A branch that fires only 5 percent of the time can still double the test cases. That is why mapping exceptions is not paperwork. It is scope control.

How to judge budget risk

Budget risk shows up when the team prices the happy path and ignores everything around it. A cheap automation plan can turn expensive fast if rare cases need extra data, extra approvals, or manual cleanup after every run.

You do not need perfect math to judge that risk. A simple scorecard is enough.

Start with frequency. Count how often each exception happens in a normal week or month, not how memorable it feels. Pull numbers from support tickets, approval logs, spreadsheets, and inbox threads. One case that happens 40 times a month deserves more attention than an odd edge case that shows up twice a year.

Then look at impact. Mark which cases can block revenue, delay billing, create refund problems, or cause compliance trouble. A low volume exception can still rank near the top if it touches contracts, taxes, payroll, or customer data.

Manual effort matters just as much. Measure how long each workaround takes in real life. If a finance manager spends 12 minutes fixing one broken handoff and it happens 25 times a month, that is five hours gone before anyone improves the process.

The next warning sign is build complexity. Flag every exception that needs custom fields, a new integration, or another approval step. These cases raise delivery cost because the team has more branches to build, test, and maintain.

A simple sort keeps the budget honest. Build now when the case is frequent, costly, or tied to compliance. Push it to a later phase when the case is real but rare or still poorly defined. Keep it manual when it needs human judgment and shows up infrequently.

That sort often cuts scope without hiding risk. A small business might find that only six exceptions deserve automation now, while nine others can stay manual for another quarter. That is usually a safer budget than trying to automate every corner case on day one.

A simple example from invoice approvals

Invoice approval looks simple until the first exception appears.

A team often starts with one neat path: an invoice arrives, the system checks the amount, and one manager approves it. That version feels cheap to automate because it has one decision and one outcome.

Real work does not stay that clean. A credit note reversal does not follow the same route as a normal invoice. Finance needs to match it to the original record, confirm the amount, and make sure the reversal does not create a duplicate adjustment. That is a separate branch with its own checks and its own audit trail.

Rush orders create another branch. The company may allow staff to skip one standard check so payment moves faster, but then it adds a tighter approval from a department lead or finance manager. The software does less in one spot and more in another. It still takes time to build.

Missing purchase orders cause even more trouble. The system cannot finish the flow on its own, so it sends the invoice to manual review. Now the team needs a queue, a status change, notes, reassignment rules, and a way to return the case to the normal path after someone fixes the record.

These are not footnotes. Each branch needs business rules, status handling, notifications, test cases, and error handling.

That is why a workflow that looked like "one approval flow" turns into four or five real paths. A first estimate might cover 40 hours. Once the team counts reversals, overrides, and manual review, the same job can reach 90 or 120 hours.

The cost did not rise because the developers changed their minds. It rose because the company finally counted the work it already had.

Mistakes that hide scope

Teams often scope automation by copying the current screen. They list fields, buttons, and status labels, then assume they captured the work. They did not.

The real work usually spills outside the screen. People check old emails, ask a manager in chat, open a spreadsheet, or call a supplier to confirm a detail. If the plan ignores those steps, the budget starts low and grows the moment real users test it.

Another common mistake is dismissing rare cases because they happen "only sometimes." That logic breaks fast when one unusual payment, refund, or contract change blocks money from moving. A case that appears twice a month can still stop the whole flow.

Vague grouping causes trouble too. A spec might say "manager override" as if every override means the same thing. In practice, one override may cover a price mismatch, a missing purchase order, an urgent exception, or a blocked vendor. Those are different rules, different data, and often different approvers.

Testing gets less attention than it should. Teams prepare clean sample records for the happy path, then forget duplicate invoices, partial approvals, reversed decisions, or missing tax details. When nobody builds test data for those cases, the team finds them late, usually when finance or operations is already under pressure.

Written policy can fool people as well. The handbook says one thing, but the team may do another because customers are waiting, a supplier is trusted, or someone senior asked for a rush job. If nobody watches the day to day work, the build follows the document and misses the real behavior.

That is why direct observation matters more than a slide deck. Ask where staff leave the system, which exceptions happened last month, and who can override a rule without opening a ticket. That small audit often changes the scope more than any feature list.

Before budget approval, ask three plain questions:

• Which cases still need a human decision?
• Which rare cases can block revenue, payments, or compliance?
• Which rules exist in practice but not in the written policy?

If the team cannot answer those clearly, the scope is still hiding.

Checks before you approve the budget

A budget can look fine on paper and still break a month later. That usually happens when the team priced the happy path and left the messy parts vague.

First, ask the team to name the biggest exceptions from memory. They should answer quickly and give plain examples such as reversed approvals, rushed requests, missing documents, duplicate records, or customer specific rules. If they pause, debate, or say "we will discover that later," the estimate is still soft.

Next, ask for monthly volume for each branch, not just total volume. Ten rare cases a day can cost more than one common path with 5,000 clean records. Volume by branch tells you where testing time and support time will go.

Then ask approval owners to confirm the rules in writing. The people doing the work often know shortcuts that never made it into a flowchart. If finance, operations, or sales has not reviewed the rules, the build will drift.

Also check that the estimate includes testing, fixes, and rework. Build time is only part of the cost. Teams need time to test odd cases, update rules, rerun failed jobs, and handle exceptions that appear only after launch.

Finally, decide what stays manual for now. That is healthy, not a failure. A narrow first release often costs less and works better than a broad one that tries to cover every edge case at once.

One simple standard helps: if a team cannot tie each exception to a named owner, a rough monthly count, and a handling rule, they are not ready to lock the budget. They may still be ready to start discovery, but that is a different decision and it should have a different price.

What to do next

Before anyone builds a workflow or buys another tool, sit down with the people who do the work every day. Ask them to walk through the normal path, then pause every time they say "except when" or "sometimes we have to." Those side paths are where scope grows fast.

Turn the exception list into phases instead of one large project. Give the stable path its own estimate, timeline, and owner. Price the messy cases separately. That makes the first release easier to finish, and it stops rare edge cases from eating the whole budget before the team ships anything useful.

A practical next step is simple. Write down each reversal, override, and special case. Group them by frequency and by cost when they go wrong. Automate the stable path first. Keep rare or risky cases manual for now. Review the estimate before any build starts.

That last review can save a lot of money. Fixing scope on paper might take a day. Fixing it after half the build is done can take months.

If the scope still feels suspiciously small, get a second review before development starts. Oleg Sotnikov at oleg.is does this kind of work for startups and smaller companies as a fractional CTO and advisor, especially when automation, AI based workflows, or custom software can expand far beyond the first draft. The goal is simple: find the hidden branches early, price them honestly, and start with the part that will hold up in daily work.