How to Choose Which Operations Problem to Fix First

Jeff Lontoc September 15, 2026

When several parts of the business are under strain, choosing the first operations project can become its own bottleneck.

The quote process needs attention. Invoices are going out late. Branch managers use different reports. New hires are learning from old documents and chat threads. The owner is still answering routine questions because the team cannot tell which exceptions they can handle.

All of these problems may be real. They are not equally useful starting points.

The first project should not be the loudest complaint, the easiest automation, or the system with the most frustrated users. It should be a bounded operating problem where a fix can change a meaningful business consequence, be tested with evidence, and be owned by the team after the project ends.

Five gates help separate a strong first project from a long list of legitimate concerns.

Gate 1: Name the operating consequence

“Communication is messy” is not yet a project. Neither is “we need a better CRM” or “our reporting is too manual.” These statements describe discomfort or a proposed tool. They do not define what the business needs to change.

Start with the consequence.

Qualified leads wait too long for a next action.
Completed work does not become an accurate invoice on time.
Schedule changes require owner intervention before the customer can receive an answer.
Location leaders prepare reports differently, so central operations cannot compare performance.
New employees reach the job before required workflow training is complete.

A useful consequence has an observable result. Someone can see that work waited, moved backward, required rework, reached the wrong person, or produced an inconsistent outcome.

This matters because teams often begin with the visible frustration and fix around it. They add a status meeting because leaders lack visibility. They buy software because information is scattered. They hire a coordinator because nobody knows who owns the handoff.

Those actions may help. They may also preserve the condition that created the problem.

Before considering a solution, write one sentence:

When this workflow fails, the business experiences ______ because ______.

If the second blank cannot be completed without guessing, the problem needs diagnosis before it needs a project.

Gate 2: Find a problem that repeats

A strong first project addresses a recurring operating condition, not an unusual event that consumed leadership attention last week.

Recurrence does not mean the problem happens every day. It means the same operating weakness appears whenever a recognizable trigger occurs.

A pricing exception reaches the owner whenever a job falls outside the standard package. A missing field stalls every unusual quote. A branch manager builds a separate spreadsheet at the end of each month because the shared system does not provide the required view. A new employee asks the same question because the approved instructions are difficult to find.

These are repeatable conditions. A fix can improve the next occurrence, then the one after it.

Look back over the prior four weeks and ask:

What type of work repeatedly waited or came back?
Which questions repeatedly moved to the same senior person?
Where did people recreate status because the current system could not show it?
Which exceptions appeared often enough to be part of normal operations?

Do not require perfect volume data. A short record of dates, requests, handoffs, delays, and outcomes is usually enough to distinguish a pattern from an isolated event.

Gate 3: Draw a boundary around the work

“Fix sales operations” is too broad for a first project. So is “standardize our locations” or “use AI across the business.” These goals contain several workflows, owners, systems, and decisions. Progress becomes difficult to define because almost any improvement can be counted and almost any remaining problem can keep the project open.

A workable project has a visible trigger and finish line.

For example:

from a qualified lead entering the pipeline to a confirmed next action
from a completed job to an approved invoice
from a customer requesting a schedule change to a confirmed resolution
from a new hire accepting an offer to completing required workflow training
from a location closing the month to central leadership receiving a comparable operating snapshot

The boundary should be narrow enough to map, change, and test. It should also be wide enough to include the handoffs that produce the consequence.

That second requirement is easy to miss. If an invoice is late because the field record arrives incomplete, a project limited to accounting will optimize the queue after the real failure. If a quote stalls because pricing authority is unclear, replacing the quote template will not move the decision.

A bounded project follows the work across the departments and systems it actually touches. It does not stop at an organizational line simply because that line is easier to manage.

Gate 4: Confirm that the result can be proved

The first project needs a baseline and a small set of operating measures. Otherwise, the team may finish with a cleaner process and no reliable way to tell whether the business improved.

Choose measures tied to the consequence, not activity inside the project.

Useful measures might include:

time from trigger to completion
number of items waiting beyond an agreed threshold
percentage of requests returned for missing information
number of routine decisions still reaching the owner
number of manual transfers between systems
variation in how locations complete the same operating step
time a manager spends reconstructing status for review

Avoid using meetings held, documents created, workflows mapped, or automations launched as the primary evidence of success. Those are project outputs. They do not show that work now moves better.

The baseline does not need months of clean historical data. A two-week sample can be enough to understand the current condition and establish what the team will watch during a pilot.

This follows a basic improvement discipline: define the problem, identify the cause, rank potential improvements, and test before treating the answer as permanent. The NIST Manufacturing Extension Partnership describes a similar sequence, including temporary solutions or staged rollouts before full implementation.

Gate 5: Identify who will own the new way of working

A project is a weak first choice when its success depends on the founder personally maintaining it.

This does not mean the owner should stay out of the work. The owner may need to clarify priorities, transfer authority, approve standards, or remove a cross-functional obstacle. The question is who will run the workflow once it becomes normal.

Name that person before implementation begins. Then test whether they have:

authority to make the routine decisions inside the workflow
access to the information required to manage it
time to review exceptions and performance
a clear escalation path when the standard does not fit
responsibility for keeping instructions, rules, and measures current

If no one can own the result, the project is not ready. The business may first need to resolve role clarity or management capacity.

This is also where an attractive automation idea can fail the test. A tool may be able to summarize requests, update records, or recommend next actions. Someone still needs to own the underlying standard, decide what the tool may do, review the exceptions, and respond when the workflow drifts.

AI can support a well-defined operating lane. It cannot supply missing ownership.

Rank the candidates before choosing

Once several problems pass the five gates, compare them on one page. Score each candidate from 1 to 5 on:

Consequence: How meaningful is the delay, error, risk, margin loss, or owner dependence?
Recurrence: How often does the operating condition appear?
Boundary: Can the workflow be changed without redesigning the whole company?
Evidence: Can the current state and the result be measured with available information?
Ownership: Is there a person who can run and improve the new workflow?

The highest total is not automatically the answer. Look for a project with a strong consequence and no fatal weakness in the other four gates.

A high-impact problem with no usable boundary can expand indefinitely. A measurable problem with no owner may improve during the project and slide back afterward. An easy automation with a weak consequence can consume attention while more important work continues to wait.

The best first project is often not the biggest problem in the company. It is the most important problem the team can fix completely enough to create evidence, capacity, and confidence for the next one.

Use a short proof period

Before committing to a full redesign, run a small proof period on the selected workflow.

For two weeks:

Record the trigger, handoffs, wait points, exceptions, and finish line.
Establish the baseline measures tied to the operating consequence.
Confirm the suspected cause with the people closest to the work.
Test one changed rule, handoff, decision boundary, or information requirement.
Review what improved, what moved elsewhere, and what the team learned.

A proof period protects the business from solving the wrong problem at full scale. It also reveals whether the issue is primarily process, ownership, capacity, system design, training, or a combination.

If the team can name the consequence, show the recurring pattern, draw the boundary, measure the result, and assign an owner, the project is ready to scope.

If those answers remain tangled, the next step is not a larger project plan. It is a clearer diagnosis. A Daloy Operations Review maps one operating lane, identifies the bottlenecks and broken handoffs, and produces a prioritized fix list before an implementation project is defined.