A partner brings forward a problem.
It is easy to recognize: the work is cumbersome, something takes too long, or a process has been frustrating people for years.
Nobody particularly doubts them. If a partner raises a problem, the business need is generally assumed to be real. That trust is built into the conversation.
The pushback usually happens on the solution side — the gap between what's asked for and what's actually needed. Much less often do we challenge the problem itself.
Not whether it exists.
But:
How much of a problem is it actually?
Can we express it in hours?
In dollars?
That question sounds straightforward.
And yet, the normal dynamics of getting a project moving make it surprisingly easy not to ask.
Someone brings forward a real problem. Everyone recognizes it. The conversation naturally shifts toward what could fix it.
Stopping to quantify the problem can feel like slowing down a conversation that already has momentum.
There is also a more practical complication: the answer is genuinely hard to extract. Pricing and finance systems are very good at showing revenue, hours billed, realization, and the performance of matters or practice groups in aggregate.
They were not designed to answer:
What does this particular internal process cost us?
Isolating one workflow may require assumptions about frequency, time, overhead, and write-offs. That number rarely falls neatly out of a standard report.
So what does this cost us? is much easier to ask than to answer.
The solution is not to avoid the question.
It is to ask something different first.
Ask the Questions That Don't Need a Number
The following three intake questions usually help to get you much closer to a useful answer:
- What do you want to do?
- Why now?
- What's currently in the way?
None of them asks the partner for a dollar figure.
Each asks the partner to describe what is happening.
And that matters because the person closest to the problem usually knows things the systems do not capture cleanly:
how often it happens;
when it tends to happen;
who gets involved;
how long it roughly takes;
what happens when it goes wrong;
and where the delay or frustration actually shows up.
Those answers give pricing, finance, or the project team enough input to estimate a magnitude: frequency, duration, and whose time is involved.
That is often enough to sketch the rough size of the problem without pretending you have performed a full activity-based costing exercise.
That does not make the exercise effortless.
Turning "this is worst right before trial" into a usable estimate may still require chasing data across systems that do not talk to each other, or discovering that the task was never tracked separately in the first place.
It helps to move the baseline from unknowable to obtainable. Not from unknowable to obvious.
Five Minutes Now, or Guesswork Later
Suppose a task takes somewhere between 30 and 60 minutes.
It happens roughly 20 times a week.
It generally involves an associate.
That alone tells you the process consumes somewhere around 500 to 1,000 hours a year.
The figure is not exact.
It does not need to be.
What matters is that you now know the order of magnitude.
You are no longer dealing with this takes a lot of time. You have something concrete enough to test, compare, and refine.
Capturing that estimate early is usually much easier because the people closest to the work are still doing it. They remember how often it happens and what the current process looks like.
Turning it into a rough dollar figure does not require a perfect costing model.
The goal is simply to distinguish between a $10,000 problem, a $100,000 problem, and a $1 million problem.
That rough baseline becomes useful twice.
The First Time: Choosing What Comes First
Most firms have a pipeline filled with legitimate problems that AI could help address:
This is incredibly manual.
It takes forever.
Everyone hates this.
This would save us so much time.
None of those statements has to be exaggerated.
But none helps much when you have twenty opportunities and capacity to pursue five.
A $50,000 problem and a $500,000 problem can sound remarkably similar when both are described as a major pain point.
Once you attach even a rough magnitude, they become more comparable.
That changes the conversation.
Not always comfortably.
There is an advantage to remaining a big problem. A big problem can compete on urgency, visibility, sponsorship, and the credibility of the person bringing it forward.
A $100,000 problem has become more specific.
And specificity means it may sit ahead of a $50,000 problem and behind a $500,000 one.
I do not think people deliberately avoid numbers for this reason.
But an innovation process that never asks for them makes it much easier for conviction to substitute for comparison.
That is where the baseline earns its keep for the first time. It does not automatically tell you which project should win. Cost is only one factor. Strategic importance, risk, client impact, feasibility, and urgency matter too.
But at least you now know more about what you are comparing — and roughly how much effort it may be sensible to put into finding a solution.
Good Enough Is the Point
This is also where the language of measurement can work against us.
Say baseline, and the exercise suddenly sounds formal:
data pulls;
time studies;
process maps;
a spreadsheet someone has to maintain.
If that is the bar, it is easy to understand why teams skip it.
But at this stage, precision is often the enemy. The question is not:
Can we prove this process costs exactly $187,430 a year?
The useful question is:
Is this approximately a $20,000 problem, a $200,000 problem or a $2 million problem?
That difference matters.
A firm probably should not spend $100,000 solving a $10,000 problem simply because the problem is urgent and visible.
But without some attempt to quantify the current state, it can be surprisingly difficult to tell the difference.
For prioritization, you often need only enough accuracy to know what neighborhood you are in.
The Second Time: After the Problem Has Disappeared
Then the project happens.
A new tool is introduced. A workflow changes. The tedious step becomes easier or disappears altogether.
The attorneys involved are happy.
That is not trivial evidence.
They had a problem. Now they do not.
From their perspective, the project worked.
And that creates a subtle shift in motivation. Before the project, everyone had a reason to talk about the problem.
Afterwards, almost nobody has a reason to reconstruct it. The users want to get on with their work. The project team wants to move on to the next opportunity.
The old process is no longer front of mind — and may no longer exist.
If this is the first point at which someone asks what changed, the exercise becomes archaeological.
How long did this use to take?
How often did we do it?
Who was involved?
What did the workaround look like?
People remember differently. Volumes have changed. Steps have been forgotten.
And because the result is already visible, reconstructing the old process can feel strangely pointless:
We know it worked. Why are we spending time proving it now?
That helps explain why anecdotes often feel sufficient after a successful project.
The attorneys are satisfied. The problem has gone away. The project team can point to adoption and positive feedback.
For the people closest to the work, that can be enough.
But over time, relying only on anecdotes to demonstrate the effectiveness of AI creates a different problem.
If every project ends with people loved it, the firm learns very little about which investments produced modest improvements and which fundamentally changed the economics, capacity, or quality of the work.
And that makes the next round of AI investments and project prioritization harder.
The Baseline Creates a Valuable Feedback Loop
This is the part we miss when we treat a baseline purely as a measurement exercise.
The number captured before one project helps determine whether that project deserves attention.
What happens afterwards helps the firm understand whether its original assumptions were reasonable.
That learning should then improve the next decision.
Without that loop, AI prioritization remains heavily dependent on stories:
Someone had a painful problem.
We built something.
They liked it.
Now let's find the next painful problem.
There is nothing wrong with any individual step.
But over time, the firm learns remarkably little about which kinds of problems are worth pursuing, how accurate its initial estimates are, which interventions create meaningful change, and where its limited implementation capacity creates the most value.
A rough baseline starts to change that.
Not by turning every AI idea into a financial model.
Simply by asking, while the answer is still relatively easy to obtain:
What do you want to do? / Why now? / What's currently in the way?
Five minutes may be enough.
Because long after everyone has forgotten how the old process worked, that rough estimate can still tell you something important about whether you chose the right problem to solve.
Rise Above AI Chaos: A Business Fable About Leading Organizations Through the AI Revolution