Do You Need Change Management, Process Improvement, or Both?

Most organizations arrive at this question after something has already gone wrong.

A process was redesigned and the improvement never materialized. Or a system was rolled out and people found ways around it. Or the same problem keeps coming back after being solved twice. And somewhere in the post-mortem, someone asks whether the organization needed a different kind of help than it went looking for.

The distinction matters because the two disciplines answer different questions, and buying the wrong one is expensive in a specific way: you get a competent answer to a question you did not have.

The short version

Process improvement asks: is the work designed well?

It looks at how a workflow runs — where the delays are, where the rework happens, which steps add cost without adding value — and redesigns it. Methodologies like Six Sigma bring statistical rigor to identifying and eliminating those inefficiencies. The output is a better process.

Change management asks: will people actually work the new way?

It looks at how the organization adopts, adapts to, and sustains something new — who decides, who influences, where trust sits, what previous initiatives taught people to expect. Frameworks like ADKAR and Prosci structure that work. The output is adoption.

The first improves the design. The second determines whether the design gets used.

Which one do you have?

Some diagnostic questions that usually settle it quickly.

Signs you have a process problem:

• Your people are following the process as designed, and the results are still poor.

• The work takes longer than it should for reasons everyone can point at — handoffs, waiting, duplicate entry, approvals that add no judgment.

• The same defect or error recurs at a consistent rate.

• You can describe the problem in terms of time, cost, or error rate.

• If you asked staff "what's wrong here," they would describe the workflow.

Signs you have a change problem:

• The new process is objectively better and people are not using it.

• Adoption started strong and decayed.

• Staff run the old process in parallel with the new one.

• The last two initiatives were announced and then quietly stopped being mentioned.

• If you asked staff "what's wrong here," they would describe the rollout, the leadership, or a previous initiative.

Signs you have both — which is the most common case:

• A redesign was completed and correct, and the gains never appeared.

• Different units are running noticeably different versions of the same "standard" process.

• Every improvement holds for a few months and then reverts.

That last pattern is the clearest tell. A process that keeps reverting is not a badly designed process. It is a well-designed process that never actually replaced the thing it was meant to replace.

Why the sequence matters

When both are needed, order is not arbitrary.

Doing process improvement alone gets you a redesign that does not stick — the most common and most demoralizing outcome, because the analysis was right and the investment produced nothing. It also spends down the organization's patience: each initiative that visibly fails makes the next one harder to launch, which is what change fatigue actually is.

Doing change management alone gets you enthusiastic, well-supported adoption of a workflow that was inefficient to begin with. Less common, but it happens — usually when a system is procured to solve a problem nobody diagnosed first.

The productive sequence is to assess before choosing. Understand how the work actually runs and how the organization actually decides, then determine which gap is doing more damage. Frequently the honest answer is that the process is 70% of the problem and adoption is 30% — or the reverse — and knowing the ratio changes where the budget goes.

Why we bring both

Idiyanale works across both disciplines deliberately: Six Sigma methodology for the process side, Relational Change Management — our integration of ADKAR and Prosci with Filipino organizational realities — for the adoption side.

That combination exists because separating them creates a predictable failure. The process consultant delivers a redesign and leaves. The change consultant is brought in a year later to rescue an implementation whose design nobody re-examined. Each does competent work, and the organization pays twice for a problem that was one problem.

The relational dimension matters here too. In many Filipino organizations, a process redesign that looks efficient on paper can quietly cut against how work actually gets done — the informal coordination, the relationships that keep things moving when the formal system stalls. A redesign that ignores those does not just fail to get adopted. It removes something that was working.

Where to start

If you are not sure which you have, the question to sit with is this:

If the perfect process were designed for you tomorrow, and handed over fully documented — what is the honest probability that it would be running as designed one year from now?

If the answer is high, you have a process problem, and process improvement will solve it.

If you hesitated, the design was never the binding constraint.

Not sure which you're dealing with? That's a reasonable place to start a conversation — assessment is the first stage of our engagement for exactly this reason. Schedule a Consultation →