Implementation date estimate starts with one ugly workflow

Why demos distort scope

A demo usually shows the clean path. A sales team creates one tidy record, clicks through a few screens, and everything works on the first try. Real work rarely looks like that.

Customers do not stay on the happy path. They retry failed steps, upload the wrong file, leave fields blank, and send data in formats nobody expected. A polished walkthrough hides that mess, so the implementation date starts to look safer than it is.

Sample data makes the problem worse. In a demo, names match, dates are valid, product codes exist, and every column lines up. In production, imports come from old spreadsheets, shared inboxes, exports from other tools, and hand-edited CSV files. Someone has to clean that data, map fields, reject bad rows, and explain what happens when half the file imports and half does not.

Demos also flatten user roles. One person often clicks through the whole flow, so the process feels simple. Real teams split work across sales, operations, finance, and a manager who only steps in for odd cases. Once you ask who reviews changes, who approves exceptions, and who can reopen a closed item, the workflow grows fast.

Reporting causes the same problem. A demo proves that a task can move from start to finish. The business also needs to know what got stuck, what was rejected, who approved it, and how long each step took. Those questions usually appear right when everyone feels close to a date.

That is why one messy real case tells you more than five polished demos. Oleg Sotnikov sees this often in advisory work: a team thinks it needs a simple build, then one actual workflow exposes approval loops, missing statuses, import cleanup, and manual checks done outside the system. The scope changes in an hour, not because anyone lied, but because the demo never showed the bad day.

A date based only on the clean path is not cautious. It is incomplete. Trouble starts when the first real exception shows up and the team has to design the process while the clock is already running.

What an ugly workflow reveals

The most useful workflow is usually the one people hated dealing with last month. Ask for the case that made staff chase updates, fix mistakes, or stay late to finish it. Fresh pain gives you facts. A polished demo gives you a story.

Start with the raw material from that case. Pull up the real emails, sheets, forms, chat notes, and side comments. If someone copied data from one place to another, keep that step visible instead of smoothing it away.

Then follow one item from the first request to the final report. Do not stop at "the system handled it." Keep going until the team sends the customer update, closes the task, checks the numbers, and files whatever leadership wants to see later. That full path shapes the estimate.

Most ugly workflows reveal the same kinds of hidden work. Someone imports data by hand from a file. An approval happens in email because the form does not fit the exception. A handoff sits in one person’s inbox for half a day. Staff keep a private note so they can fix the record later. Reporting needs fields nobody captured at the start.

These details matter because they create hidden states. A request is not just "open" or "done." It might be waiting for missing data, sitting with finance, sent back for correction, split into two records, or marked complete in one tool but not another.

Workarounds belong on the page too. If a coordinator exports a sheet, edits five rows, and uploads it again, write that down. If a manager approves only after a phone call, keep that in the map. Teams often want to hide these steps because they look messy. The mess is the point.

You also need the side paths, not only the main flow. Returns, edits, late approvals, duplicate requests, and manual report fixes often eat more time than the happy path.

When a team maps the ugly case honestly, missing fields and missing rules show up fast. So do the small jobs that wreck a schedule later: imports, permissions, notifications, exceptions, and end-of-month reporting. That is the workflow you can estimate against.

The work a messy case brings out

A clean demo shows what people hope will happen. A messy case shows what you actually have to build.

The first surprise is usually state changes. In a demo, an order might move from "new" to "approved" to "shipped." Real teams add all the awkward stops in between: on hold, split into two shipments, customer changed the address, item went out of stock, finance blocked release, sales edited the price after approval. Every extra state needs rules. Someone must decide who can move it, what gets logged, and what happens next.

Imports expose another layer. A sample CSV often looks neat. The live file never does. Customer names differ by one character, product codes use old formats, and dates arrive as both 03/04/2025 and 2025-04-03. Then the team has to answer a real product question: what should the system do with bad rows? Skip them, stop the whole import, or create a review queue? That is build work, not trivia.

Approvals stretch the timeline too. One approval step sounds simple until you ask who owns it. Does a sales manager approve discounts? Does finance approve only above a limit? What happens if nobody responds for six hours? If one person rejects the order, can another person edit and resubmit it, or does it start over?

Reporting often breaks the illusion of a finished scope. The demo screen may look complete, but the report needs fields nobody planned to capture: rejection reason, original requested ship date, source channel, account owner, tax status, or a manual override note. If the team never records those fields, the report cannot exist.

Then come exceptions. Teams need admin tools to fix duplicates, rerun failed imports, unlock records, merge customers, and correct mistakes without asking engineering every time. Those back-office screens often take more time than the polished front end.

That is why one ugly workflow changes an implementation date so quickly. It turns hidden rules, wait time, cleanup work, and reporting gaps into visible scope.

How to map one real case in a single session

A useful session starts with one real case, not a clean sample. Pick something from the last 30 days that had at least one wrinkle: a missing field, a late approval, a spreadsheet fix, or a customer complaint. Fresh examples beat old stories because people still remember the awkward parts.

Bring in one person from each team that touched the work. Keep the group small enough to move, but broad enough that no handoff gets skipped. For many companies that means sales, operations, finance, support, and whoever owns the current tool.

Put the case on a screen and walk it from the first trigger to the final result. Ask people to show the actual steps if they can. Summaries hide too much. You want the clicks, copied text, uploaded files, chat messages, email approvals, and side notes in someone’s inbox.

At every handoff, pause and ask five plain questions: who takes over next, what file or record moves with it, what usually breaks, how people fix it today, and how they know the step is finished. Those questions surface scope fast. They expose the work that stretches a date: exception states, manual imports, missing permissions, duplicate data entry, and reports someone still builds by hand.

Write the workflow where everyone can see it. A whiteboard works. A shared document works too. Keep two simple side columns: "known gaps" and "open questions." When a debate starts, do not let it take over the session. Park the question, name an owner, and keep moving.

One rule matters more than it seems: stay with one case until the end. Teams often jump to "usually" after ten minutes, and that is where details disappear. A single ugly case gives you a truer map than a broad discussion of normal work.

If the group leaves after 60 to 90 minutes with a step-by-step flow, a short list of failure points, and owners for open questions, the session worked. That is enough to turn messy reality into scope you can price and schedule.

A simple order team example

A team asks for an implementation date after showing a clean demo. In the demo, a customer picks a standard product, pays, and the order moves through the system with no surprises. It looks small. It might even look like a week of work.

Then someone brings up the order they all try to avoid.

A sales rep gets a custom order by email. The customer wants special terms, a changed price, and a few line items that do not match the normal catalog. Ops keeps those line items in a spreadsheet, so someone copies them into the system by hand. Finance does not let the order move until a manager approves the terms. Weeks later, support needs a report that shows who changed what, when they changed it, and why.

That one case changes the scope fast. The team now needs more than an order screen. It needs states for draft, review, approved, blocked, and changed after approval. It needs a way to import or retype spreadsheet rows without breaking totals. It needs approval rules, manager alerts, and a record of every edit.

The work also spreads into places the demo never touched: custom line item handling, manual import checks, approval and rejection paths, change history for support and finance, and reports that match real operations.

None of this is rare. It is normal work that polished demos hide.

Now picture what happens without those details. Sales enters the order. Ops copies ten rows and misses one. Finance blocks the order because the payment terms changed. A manager approves by email, but the system does not store that approval. Support gets a complaint later and cannot prove when the price changed. The team then asks for a report, but no one captured the history in the first place.

That is why one ugly workflow beats ten neat screens. The clean demo shows the story people want. The messy case shows the system they actually need.

How to turn the workflow into a date

Start by breaking the workflow into small units you can price in days, not feelings. Most messy processes contain three kinds of work: build work, cleanup work, and decision work. If you mix them together, the date will look neat on paper and slip in real life.

Build work is the obvious part: screens, rules, imports, exports, notifications, and reports. Cleanup work is where teams quietly lose time. That includes bad source data, duplicate records, odd file formats, half-used fields, and manual fixes people forgot to mention. Decision work is the human delay: who approves, who can override, what happens when someone is out, and what the team does when two systems disagree.

Map each step in the workflow and mark where you need something new. A new screen, validation rule, approval path, or report each adds its own chunk of work. Small items add up fast, especially reports, because teams often ask for filters, export formats, and edge cases after they see the first draft.

Then count the unknowns before anyone writes code. If the team says, "we need to check with finance," or "the CSV files are all a bit different," that is not a note for later. It belongs in the estimate now. Unknowns need their own time box for discovery, samples, and decisions.

A simple estimate usually works best when it does four things. It lists the workflow steps in order, tags each one as build, cleanup, or decision work, marks anything that needs a new screen or rule, and adds time for messy test data and slow approvals.

The final estimate should be a range with named assumptions. For example: 3 to 5 weeks, assuming one approver per stage, sample import files arrive this week, and reporting stays limited to two views. If those assumptions change, the date changes too. That is not hedging. It is honest planning.

This is where experienced CTOs usually help most. They price the waiting, the cleanup, and the rework before the team trips over them.

Mistakes that make the date useless

An implementation date falls apart when a team dates the demo instead of the real work. The polished path is usually the smallest part of the job. The missed effort lives in the odd cases: manual imports, stalled approvals, missing status values, and reports that nobody mentioned in the meeting.

The first mistake is the easiest to spot. Someone sees a smooth happy-path demo and says, "We can ship this in three weeks." That demo usually skips the parts that slow teams down every day. It does not show what happens when a customer record is incomplete, when two systems disagree, or when finance needs a correction after the order already moved forward.

The second mistake is ignoring the spreadsheet or shared inbox people still use today. Those tools look like clutter, so teams treat them like temporary noise. They are often the real process. If five people still copy data from email into a sheet, that sheet probably handles exceptions, handoffs, or checks the new system does not cover yet.

Approvals cause the next bad estimate. People describe them as one click because that is how they want them to work. In practice, approvals sit in queues. A manager waits for more details. Someone delegates during vacation. Finance rejects a request and sends it back. Each step adds states, notifications, reminders, and audit history. Skip that queue logic and the date will look fast but turn false.

Reporting gets pushed late, and that gets expensive. When a team asks for weekly numbers right before launch, they often discover the app never stored the fields they need. Now they have to add reason codes, timestamps, owner names, and export rules after the workflow already looked "done."

Another pattern ruins estimates: letting the loudest stakeholder describe the whole process. That person often explains the version they expect, not the one staff follow at 4:45 p.m. on a busy Friday. The person who cleans the data, watches the inbox, or fixes failed approvals usually gives the better picture.

A date gets better when it accounts for the things people hide by accident: the unofficial spreadsheet, the approval queue, the report someone checks every week, and the quiet workaround nobody mentions in a demo. If those are missing, the date is just a guess with a calendar attached.

A quick check before you commit

A date is still a guess if the team cannot walk one real case from start to finish without stopping to debate basic rules. The ugly case shows where the work is.

Pull in the people who do the work each week for one short review. Use a real example with edits, delays, missing data, and one awkward exception. If the process only works when everyone tells the story in the nicest possible way, the date will slip.

Before anyone promises a calendar date, make sure the team can answer a few basic questions. Can they name every state in the process, including hold, reject, reopen, cancel, and done? Do they know where each piece of data comes from, whether from user input, import, another system, or a manual correction? Is it clear who approves each step, who can override a rule, and where that override is recorded? Do they know which report people actually read each week, and which numbers must match for them to trust it? Have they listed the exceptions that happen often enough to build for instead of handling them by email or chat?

If one answer is vague, the estimate has a hole in it. Teams often wave this away and say they will sort it out during the build. Then they lose days on simple questions: can a canceled order return to draft, can finance change imported totals, does a manager see the same numbers as operations, who fixes bad records after approval?

The weekly report is often the fastest test. It forces people to name statuses, timing, ownership, and data sources. If nobody can explain how the Monday report gets its numbers, you do not have enough scope detail yet.

You do not need perfect documents. You need clear answers that one owner can confirm. If that owner hesitates, move the date conversation back a step and keep mapping. That is much cheaper than missing the promise later.

If the workflow keeps growing

When a workflow keeps changing, the date should stop moving in private chats and start moving through a simple review. A 20 to 30 minute session is often enough. Put the people who do the work, approve the work, and report on the work in the same call. Walk through the mess again and ask one question at each step: "Did we miss anything that changes the build?"

Small details usually cause the slip. A new import format, one extra approval, a different exception path, or a monthly report nobody mentioned on day one can add days fast. That is why customer workflow mapping works better than another polished demo when you need a real implementation date.

Keep the evidence together in one place so the team stops arguing from memory. A shared folder or project page is enough if everyone can find it. Save screenshots of the current steps, sample CSVs or forms, approval rules with owners, report examples people already send to managers, and the open questions that still block scope.

Do not wait for perfect documentation. One blurry screenshot and a real file from the customer often tell you more than a neat flowchart.

Then turn every open question into a decision with an owner and a date. "Need finance to confirm refund approval" is not a decision. "Maria confirms refund approval by Thursday" is. If nobody owns the answer, scope drifts and the estimate turns into fiction.

If the list keeps growing after two review rounds, pause the promise. Split the work into a first release and later changes, or get a short outside review before the team commits. That is usually cheaper than missing the date and rebuilding the wrong thing.

If a team wants that second opinion, Oleg Sotnikov does this kind of review in his Fractional CTO work. His site, oleg.is, is a useful reference point for teams that need help turning messy operations into a plan they can actually defend.