Improving a Process That Was Never Designed

A process that was never designed is a process that grew. It accumulated one decision at a time, one workaround at a time, one exception at a time, until it became the way things are done.

Improving such a process is not a design exercise. It is an archaeology exercise, and the first step is accepting that the current state is not a plan gone wrong. It is a history gone unexamined.

Most companies approach process improvement as if they are optimizing a designed system. They are not. They are optimizing an emergent system, and emergent systems resist optimization because every part exists for a reason that made sense to someone at some point.

Those reasons may no longer apply, but they are not random. They are historical.

The anti-pattern is the redesign fantasy

A recognizable pattern runs through improvement initiatives. A team decides the current process is broken, sketches an ideal future state, and attempts to jump from one to the other. The jump fails because the current state contains adaptations to constraints that the redesigners never saw.

The fantasy has a signature. Workshops produce elegant flowcharts. Stakeholders sign off. Implementation begins, and within weeks the new process is circumvented by the same workarounds that existed before.

The redesign did not fail on its merits. It failed because it treated symptoms as architecture.

Underneath sits a category error. Improvement has been confused with replacement. A process that grew organically contains knowledge about the business that no workshop can surface. That knowledge is embedded in the exceptions, the informal handoffs, and the quiet agreements that keep the work moving.

Ignoring that knowledge is not improvement. It is damage.

Do not redesign, understand

The reflex when facing a grown process is to impose order. A new system arrives, a new method is adopted, and the hope is that structure will replace chaos. That hope produces resistance, because the people inside the process know things the redesigners do not.

A calmer approach begins with observation rather than prescription. Follow the work as it happens. Note where it slows, where it forks, and where it relies on personal judgment rather than documented rules.

Those three observations, taken together, map the real process. The real process is almost always different from the described process.

This is where value stream mapping earns its place. It does not require a clean starting point. It requires only honesty about what currently happens, including the rework loops and the waits that consume time without adding value.

Theory of constraints offers the complementary discipline, showing which step in the grown sequence limits throughput for the whole system.

The systemic fix is guided evolution

Anyone building a serious position on process improvement starts from the assumption that the current process contains necessary adaptations. The goal is not to replace it. The goal is to evolve it, one constraint at a time, while preserving the knowledge embedded in its shape.

Step one is current state mapping. A facilitator follows the work, records each step, and asks why it exists. Not why it should exist. Why it does exist.

The answer is usually a constraint that was solved informally and never documented.

Step two is constraint identification. Among the steps that exist for real reasons, which one limits throughput. That is the only place where an intervention changes the output of the system rather than the appearance of the system.

Step three is the smallest change that removes the constraint, not the most elegant change. The smallest one. Small changes are adopted. Large changes are resisted, because they threaten the informal knowledge that keeps the process alive.

Step four is measurement. The change is tracked against the throughput measure agreed in step one. If throughput does not move, the change did not touch the constraint, and the team returns to step two with better data.

A balanced scorecard is useful here, not as a reporting ritual but as a forcing function. It requires the company to state what improvement means in measurable terms before claiming any change delivered it.

Where grown processes resist, function by function

Finance processes resist improvement because they are already constrained by regulation. The inputs are structured, the outputs are checkable, and the exceptions are few. The growth in finance is not in the process itself. It is in the workarounds around reporting deadlines and reconciliation timing.

Operations processes resist improvement because they are where most of the growth happened. Scheduling, routing, and fulfillment all accumulated exceptions for good reasons. Customers needed flexibility, suppliers were unreliable, and demand was unpredictable.

Each exception made sense at the time. Together they create a process that nobody would design and everybody depends on.

Sales processes resist improvement because stages are often informal. A pipeline definition that lives in one person's head is not a process. It is a judgment, and judgments do not transfer.

Improving sales requires documenting what each stage means before any sequence can be standardized.

People operations resist improvement most of all, because those processes are the least documented and the most emotionally loaded. Hiring, onboarding, and performance management carry the highest human consequence. Errors in these processes damage trust in ways that are slow to repair.

Why this is a leadership question

Process improvement is not a technical exercise. It is a statement about how a company treats the knowledge of the people inside it. A grown process is a record of accumulated problem solving. Dismissing that record as chaos is dismissive of the people who created it.

Guided evolution before replacement produces two outcomes. The process improves, and the people who hold its informal knowledge become participants rather than obstacles.

That second outcome is the difference between an improvement that sticks and an improvement that is circumvented within weeks.

Discipline of this kind is a form of care. A leader who insists on understanding before changing is not slowing improvement down. That leader is refusing to destroy knowledge that the company spent years accumulating.

What the sequence looks like in practice

Consider a mid-market distributor whose order fulfillment process grew over a decade. It started with one person and one warehouse. It now involves three locations, a mix of direct and drop-ship orders, and a routing logic that lives entirely in the head of the operations manager.

Improvement mapping reveals that most of the delay accumulates at a single handoff. The drop-ship orders sit in a queue because the operations manager personally approves each one, a practice that began when drop-ship was rare and mistakes were expensive.

Drop-ship is now common, and the approval is a bottleneck rather than a safeguard.

The smallest change is a documented criteria list for auto-approval. Orders meeting the criteria flow without stopping. Exceptions still route to the manager.

Throughput moves, the safeguard remains, and the manager's time is freed for the judgments that truly require a human.

Firms that improve this way tend to accumulate trust as they accumulate efficiency. Organizations that replace processes wholesale tend to lose both.

What compounds

Each constraint removed makes the next constraint easier to see, because noise around it has been reduced. Each small change that sticks makes the next small change easier to propose, because the team has learned that improvement does not mean replacement.

That accumulation is the asset. The process will continue to grow and change. The capability to map it honestly, to identify its true constraint, and to evolve it without destroying its embedded knowledge, will remain.

A RACI grid is useful at this stage, not as documentation but as a forcing function. It exposes the roles where responsibility is unclear and the handoffs where accountability is missing. Most process improvement failures trace to one of those two gaps.

Porter's value chain offers a complementary view for companies seeking shared alignment across departments. It separates primary activities that create output from support activities that make output possible, building confidence that each function understands its role.

Every process a company can describe accurately is a process that can be improved. Every process that is too messy to describe will be replaced by someone who does not understand it, and that replacement will contain the same problems wearing a new costume.

Frequently Asked Questions

Why map a grown process before improving it?

Because a grown process contains adaptations to real constraints. Ignoring those adaptations produces redesigns that fail on contact with reality. Mapping surfaces the constraints so they can be addressed rather than repeated.

What is the smallest viable improvement?

The smallest change that removes the largest bottleneck, not the most elegant change. The smallest one. Small changes are adopted. Large changes are resisted because they threaten the informal knowledge that keeps the process alive.

Which processes should be improved first?

The ones that constrain throughput, have visible failure modes, or touch a customer directly. Improving everything at once spreads effort too thin and produces changes that are not maintained.

How should informal knowledge be preserved?

By involving the people who hold it in the mapping and the change design. Their knowledge is not an obstacle. It is data, and improvement that ignores available data is not improvement. It is guesswork.

What is the most common improvement mistake?

Replacing before understanding. Redesigns that look elegant on paper fail because they treat the current process as broken rather than as adapted. The adaptations matter, and they must be understood before they can be replaced.

When does outside help make sense for this work?

When the people inside the process have normalized the friction to the point that they cannot see it. An outside facilitator carries no memory of how the process is supposed to work, which is exactly what makes the observation honest.