HomeKnowledge CenterImproving a Process vs. Redesigning It

Improving a Process vs. Redesigning It

Not every improvement is a real one. Follow Noura's case to learn when to polish an existing process and when to rebuild it from its purpose.

26 May 2026RAISO Experts Team

Improving a Process vs. Redesigning It

Noura's team gathered one sunny morning around a cake with a line piped on it: “From three days to one.” They had automated the finance review step in purchase requests, and its time had dropped sharply on the tracking board. Everyone applauded, Noura sent a short report to her manager, and she felt that good work had been done. Two months later a message arrived from Khalid, the operations director, asking: why does an order for a box of pens still take twelve days?

This article says something that may sound odd: some improvements make a process worse, or keep it bad in a very polished way. We follow Noura and her purchase requests in this hypothetical organization from that morning to the final decision. You will leave with four questions that tell you when to polish an existing process, when to redesign it from its purpose, and when to combine the two in one cycle. Each section ends with a short exercise to try on a process in your own organization.

Noura celebrates a win

Noura runs the shared services unit. Her job is to make sure every department gets what it needs, in reasonable time. Everyone complained that purchase requests were slow, so she launched an improvement initiative with honest intentions and an eager team.

The team drew the process on a large board. A request passed through seven parties: the requesting department head, then procurement, then budget, then finance review, then compliance, then legal, then the director general. Measurement showed that finance review was the slowest, holding each request for three days.

The team worked on that step. They built an electronic form that fills in data automatically, added automatic checks, and set up an alert for delays. Time fell from three days to one, which truly deserved a celebration.

But the day Khalid's message arrived, Noura decided to trace his request herself. It was an order for a box of pens, low in value, and it had passed through seven parties, waiting at each one. The step she had improved was one day out of twelve. The other eleven were waiting between parties, none of which knew why it was rechecking what another had checked.

“We improved the step everyone pointed at, and never asked why there were seven steps.”

— Noura, to herself

“Noura, Khalid and the numbers in this article are hypothetical, made up for illustration, and refer to no real organization.”

— A hypothetical case
One box of pens: where did the days go? - The step the team improved was a small part of the journey.
Illustrative numbers

At that moment Noura began to reflect. Had the team been negligent? No. Was the work poor? No. The step really was faster. The problem is that the question the team asked was small: how do we make this step faster? The big question was never asked: does a simple request need seven approvals at all?

“The case now: Noura has a real achievement on the board, and an uneasy feeling that her customer, Khalid, noticed nothing. She does not yet know that this feeling is the start of understanding.”

“Try it now: Pick a process your organization improved last year. Trace one request from submission to arrival. How much of the total time did the improved step actually take?”

Why can improvement make things worse?

In everyday speech, “improvement” means any change we believe is for the better. In its precise sense, improvement is a change that brings the process closer to its purpose. That is where the difference we are looking for sits. You can change a step and speed it up while the whole process keeps drifting away from its purpose.

To see why, we need two words. The first is efficiency: doing a thing with the least effort and time. The second is effectiveness: whether the thing you are doing is the right thing in the first place. Noura's team raised the efficiency of the review step. Effectiveness is a different question: do we need this review for a request of this size?

Incremental improvement serves efficiency well, but it does not ask about effectiveness. It asks: how do we do this thing better? It does not ask: is this the right thing? If the process is sound at its foundation, that question is enough. If it is flawed at its foundation, improvement makes us better at doing the wrong thing.

The illusion carries another danger: it calms anxiety. As long as the indicators are moving, everyone assumes the process is being fixed. Nobody feels the need to face the harder question, because the tracking board says things are getting better. So the real decision is postponed month after month.

“An improvement that makes us better at doing the wrong thing is not progress. It is drifting away from the goal at a faster pace.”

“The case now: Noura now knows the difference between efficiency and effectiveness. She looks at her tracking board differently: it measures how fast a step is, and not whether the request reached Khalid in reasonable time.”

“Try it now: Write down one indicator your organization tracks for a process. Then ask: does it measure the speed of one step, or the result of the whole process as the beneficiary sees it?”

What are improvement and redesign?

Before judging Noura's team, let us be fair to improvement. It is a valuable tool in its place. Its best-known form is kaizen, a Japanese word for continuous improvement through small accumulated steps. The idea rests on a clear assumption: the process is sound in its purpose and design, and all it needs is removing waste, reducing errors and polishing performance inside the existing frame.

Improvement has five defining traits. Its scope is limited to the process. Its risk is low, because the changes are small and reversible. Its horizon is short and repeated. It is led by the people who do the work, since they know its obstacles best. And it keeps the process running while it is being improved. When these conditions hold, improvement is the smartest and cheapest choice.

Redesign differs in kind, not in degree. It does not ask: how do we make this process better? It asks: if this process did not exist and we wanted to achieve its purpose from zero today, how would we build it? It starts from the purpose, not from an inherited map. This approach became known as business process reengineering.

Improvement vs redesign: a difference in kind - Both are useful, but each asks a different question.
Comparison drawn from the article

The traits of redesign mirror those of improvement, point by point:

  • Its scope is wide: it redefines the whole process, and may remove it or merge it with others.
  • Its risk is high: the change is radical and hard to reverse.
  • Its horizon is longer: the result is delayed and needs investment.
  • Leadership drives it, because it crosses the borders between departments.
  • It breaks continuity for a while during the transition.

Look at Noura's process from both angles. The improvement approach asks: how do we speed up the legal review? How do we reduce budget errors? All legitimate questions. The redesign approach asks: why does an order for a box of pens pass through a legal department? Why not approve a catalogue of routine supplies once, so that ordering from it becomes a single step?

The results differ widely. Improvement might cut the time by twenty or thirty percent, a real success in its place. Redesign may cut it far more, because it did not polish the steps but removed most of them. That is the difference between “faster” and “different.”

“The case now: Noura now has two questions instead of one: how do we speed up the step, and do we need the step at all? She does not yet know which one fits her process.”

“Try it now: Take one process in your organization and write two questions for it, an improvement question and a redesign question. Notice how the range of possible answers differs.”

When does a process outgrow polishing?

Insisting on improving a process that has outgrown polishing is understandable. Improvement is easier, cheaper and less threatening, and it does not require admitting that the process is flawed at its core. But there are signs that it is time to think of something else. Noura found most of them in purchase requests.

The first sign is diminishing returns. When improvement cycles repeat on a process and yield only small gains, you are nearing the ceiling of what the existing process can offer. In Noura's case, the second cycle saved only a few hours.

Checklist: has your process outgrown polishing?
#SignWhat it looks like in practiceMatchesPartly matchesDoes not match
Performance signs
1Diminishing returnsImprovement cycles repeat and yield only small gains
2The root lies in the designThe slowness is built into the structure, not the steps
Structural signs
3Exceptions outnumber the ruleThe process no longer describes reality
4Layers piled up after incidentsThe process lost its original logic
5Purpose or context has changedNew beneficiary, new technology or new regulation
6Beneficiaries work around itPeople bypass it to get what they are owed
7Survival costs more than rebuildingKeeping it alive costs more than a new process

Rate one process against each sign.

The second sign is that the root of the problem lies in the design, not the execution. A process designed to pass through seven parties will stay slow however much you polish each party, because the slowness is built into the structure. You cannot polish a structural flaw. You must rebuild it.

Other signs deserve your attention:

  • Exceptions outnumber the rule, so the process no longer describes reality.
  • Layers have piled up over the years as reactions to incidents, until the process lost its original logic.
  • The purpose or context has changed: a new beneficiary, a new technology, a new regulation.
  • Beneficiaries have to work around the process to get what they are owed.
  • Keeping the process alive costs more than building a new one.

Noura traced the history of the seven approvals and found that each party was added after an incident. A legal approval came after an old contract went wrong, and a compliance approval after an audit remark. Nobody asked at the time whether these layers suit small requests. And nobody remembered anymore why they had been put there.

“The case now: Noura saw that her process carries four of the five signs. In her eyes, insisting on improvement alone had become a form of denial.”

“Try it now: Tick every sign that applies to a process you know. If you find three or more, set aside time for a serious discussion.”

Four questions: when to improve, when to redesign
#QuestionImprovement is enough ifRedesign is needed if
1How far is the process from what is required?The gap is within reasonable polishingIt needs a leap that polishing cannot reach
2Where is the root of the problem?In execution: waste, errors, a slow stepIn design: flawed sequence or wrong borders
3Is the purpose alive and the context stable?Yes, the purpose is alive and context steadyNo, purpose, context or technology has changed
4What risk can we carry?The process is critical and cannot stopThe cost of standing still exceeds the risk

Answer with those who run the process and receive its output.

Four questions that settle the path

No mathematical formula gives you the answer. But four questions, asked honestly of the process, reveal the direction clearly. Noura tried them on purchase requests with her team and wrote the answers on the same board.

  1. How far is the process from what is required?

    If the gap is within reasonable improvement, improvement is enough. If it needs a leap no cumulative polishing can reach, such as cutting time to a fraction, the existing process is structurally unable to get there. In Noura's case the gap was large: a few days were required, and the reality was twelve.

  2. Where is the root of the problem?

    If it is in execution, such as waste, errors or slowness in a given step, improvement handles it. If it is in the design, such as a flawed sequence, wrong borders between departments or a purpose that no longer exists, polishing execution is pointless. The root of Noura's problem was in the design of the seven parties.

  3. Is the purpose alive and the context stable?

    If the purpose is alive and the context steady, the process deserves polishing. If the purpose or context has changed, through a different beneficiary, a new enabling technology or a new strategic direction, the process was designed for a world that has passed. In Noura's case both volume and technology had changed: an electronic catalogue did not exist when the process was born.

  4. What risk can we carry?

    Redesign brings disruption, cost and the chance of failure. If the process is critical and cannot tolerate interruption, improvement may be wiser, or redesign can be staged as pilots. But when the cost of standing still exceeds the risk of change, hesitation itself becomes the riskiest option.

Combine the answers into one judgment. If the gap is limited, the flaw is in execution, the purpose is alive and the context stable, improve. If the gap needs a leap, the flaw is in the design, the purpose or context has changed and the cost of standing still is higher, redesign. The answer is rarely clear-cut on every question, but clear questions prevent the automatic slide toward improvement just because it is easier.

“The case now: Noura's answers pointed to redesign on three questions and to caution on the risk question. So she decided to redesign small requests only, and to leave large requests on their current path.”

“Try it now: Answer the four questions in one sentence each for a process you are thinking of changing, then write your judgment in one line: improve or redesign?”

Noura redesigns from the purpose

How do you begin a redesign without turning it into a gamble? Noura began with one question on a blank sheet: what is the purpose of this process? The team wrote the answer: that the supplies a department needs arrive quickly, at a fair price, with enough control to prevent waste and misuse.

Noura's path: design, then polish - From purpose to continuous improvement on a sound base.
Hypothetical case for illustration

Then they asked: if we started from zero today, how would we achieve this purpose? The new design came out simple. Procurement, budget and legal approve a catalogue of routine supplies and their prices once each quarter. An order from the catalogue, under a set financial ceiling, needs only the approval of the requesting department head. Anything beyond the catalogue or the ceiling goes through the full path as before.

Notice what they did. They did not automate the seven approvals. They removed six of them for small requests, and moved control from every request to the catalogue itself. This shows the common mistake that redesign warns against: automating a flawed process as it is. That does not give you a better process, only a faster mess.

Because the risk was real, Noura piloted the new design in two departments for a month. She watched for what might break: did prices rise? Did requests outside the catalogue appear? When it was clear that control had not weakened, she extended the pilot to the other departments.

“The case now: Khalid's next order for a box of pens arrived in two days instead of twelve. Nothing changed in the step Noura's team had automated earlier. It simply disappeared from this path.”

“Try it now: Write the purpose of your chosen process in one sentence. Then, on a blank sheet and without its old map, draw the shortest path you can imagine to achieve that purpose.”

The third way: design, then polish

Reality is rarely a pure either-or. And here begins the smartest stage in Noura's story. Three months after the new design, the small improvement cycles returned to work, but this time on a process with a sound foundation. The team added product photos to the catalogue, reduced quantity errors, and improved the alert sent to the manager.

This is the wiser pattern: redesign, then improve. You gain the leap of redesign first, then protect it and build gains of polishing on top. The mistake is settling for either one. Whoever only improves stays trapped in a flawed design. Whoever redesigns and then leaves it unpolished watches the new design age gradually.

There is another striking benefit: continuous improvement is an excellent detector of the need for redesign. Had Noura's team applied kaizen honestly to the old path, it would have reached the ceiling of diminishing returns, and gained evidence from reality, not intuition, that the process had exhausted its capacity. In this sense the two paths do not conflict. Each serves the other.

An outstanding organization runs both engines together: a continuous improvement engine working in the background on every sound process, and a redesign capability called on for processes that have outgrown polishing. The first keeps daily agility. The second makes leaps when they are needed.

“The case now: Noura no longer asks: improvement or redesign? She asks: which process needs either one today? And she gave her team the authority to request a redesign when improvement cycles reach their ceiling.”

“Try it now: Sort five processes in your organization: sound and needing polish, flawed and needing redesign, or not yet known. Start with the ones you do not know.”

The cost of choosing wrongly

Why does this distinction deserve so much attention? Because a wrong choice is costly in both directions, though the nature of the cost differs. A leader must understand it before deciding.

The first error is to redesign a process that needed only polishing. This error is loud. You spend large resources, disrupt a process that was working, and push people into a change that was not necessary. But it is visible, and usually discovered quickly because its noise gives it away. That is why over-redesigning is less common.

The second error is to polish a process that is structurally flawed. This error is silent. There is no disruption and no visible cost, only a slow bleed: resources spent year after year on what cannot be polished, and small gains celebrated while the gap remains. This is exactly what happened to Noura in the first two months. It disguises itself as progress, and can last for years undiscovered.

“Over-redesigning is a loud mistake found quickly. Over-improving is a silent bleed disguised as progress.”

That is why this judgment is not fully delegated to an operations team. It requires a view of the whole purpose, of the strategic context and of the risk we can bear, an angle seen only from sufficient height. A leader who judges well saves the organization both costs of error.

“The case now: Noura presented the full lesson to her manager. She did not say: we erred by improving. She said: we gave a good answer to a question that was not the right one.”

“Try it now: Ask yourself: which kind of error is closer to my organization's habit, over-demolishing or over-polishing? Write at least one example.”

What you take with you

Go back to the cake that read “From three days to one.” The celebration was not the mistake. The mistake was stopping there. When your next flawed process comes, the comfortable instinct will arrive at once: improve it, add a tracking board, shorten a step. At that moment you decide whether you will make a real improvement or an illusion.

Take five ideas with you from this article:

  • Real improvement brings the process closer to its purpose. It is more than speeding up a step.
  • Efficiency without effectiveness deceives: doing a thing well does not help if the thing itself is wrong.
  • Improvement polishes the existing process, while redesign asks why the process exists in this form.
  • Four questions settle the path: the gap, the root of the problem, the purpose and context, and the risk.
  • Often the smartest course is to redesign and then polish, and to let continuous improvement show you when a redesign is due.

Start this week with one small step. Before launching a new improvement initiative, ask first: does this process deserve to exist in this form? And if you want to learn how to assess processes, choose between polishing and rebuilding, and lead the change with a clear method, explore RAISO's process management practice and the courses that train your team on these questions and apply them to its real processes.