Leading an Improvement Initiative: From Discovery to Implementation

Analysis is the part of process improvement that most BAs are comfortable with. The workshops, the mapping, the root cause investigation, the future state design. These are activities that sit squarely in the BA's core competency. They are structured, analytical, and produce tangible outputs. Implementation is the part where most improvement initiatives quietly die. Not dramatically. Not with a visible failure that everyone acknowledges, but quietly. The recommendations get filed. The future state map gets presented and approved in principle. The immediate pressures of day-to-day operations take over. Six months later, nothing has changed. The BA who wants to lead process improvement rather than just contribute to it needs to own the full arc of the initiative, from the first conversation about what is not working to the measurement of whether the implemented change actually delivered its intended outcome. Today we look at how to do that.

Structuring the Initiative

A process improvement initiative has six stages. Each one builds on the last, and skipping any of them creates a gap that tends to surface at the worst possible moment.

The first stage is problem definition. Before any analysis begins, the problem needs to be stated precisely. Not as a general complaint, such as the process is slow, but as a specific, measurable statement: the average end-to-end time for a new customer onboarding is fourteen days against a target of five, and the business is losing an estimated fifteen per cent of new customers to a competitor with a faster process. A well-defined problem statement does three things. It creates a shared understanding of what is being addressed. It sets a baseline that success can be measured against. And it makes the business case for the improvement work without requiring a separate justification document.
The second stage is current state analysis. This is the process mapping, root cause analysis, and waste identification work covered in the previous three days. The output is a clear, evidence-based picture of why the process is not performing as it should.
The third stage is future state design. This is where the improvement is designed. Not as a wish list, but as a specific, achievable process design with defined changes, named owners, and a realistic assessment of what it will take to implement. The future state should be co-designed with the people who run the process, not presented to them as a finished proposal.
The fourth stage is implementation planning. This is where most improvement initiatives underinvest. A future state design without an implementation plan is a presentation, not a project. The implementation plan covers what changes, in what order, who is responsible for each change, what the dependencies are, what the risks are, how progress will be tracked, and what the rollback approach is if something does not work.
The fifth stage is implementation. The changes are made, the new process is adopted, and the people running it are supported through the transition. The BA's role during implementation is not to disappear into the next assignment. It is to be available for questions, to monitor for early signs that the implementation is not working as planned, and to manage any adjustments that are needed without losing sight of the target.
The sixth stage is measurement and review. After implementation, the process is measured against the baseline established in the problem definition. Did the change produce the expected improvement? If not, why not? What needs to be adjusted? This stage closes the loop and is the stage most often skipped, which is why improvement initiatives are so often described as successful without anyone being certain whether they actually were.

Engaging Stakeholders in Improvement Work

Process improvement is change. And change affects people. The people who run the process, the people who manage it, and the people who depend on its output all have a stake in whether the improvement succeeds. Their engagement is not a nice-to-have. It is a delivery dependency. The most important engagement principle in improvement work is this: involve the people closest to the process in designing the solution, not just in describing the problem. There are two reasons this matters.

The first is quality. The people who run a process every day know things about it that no amount of observation or documentation will capture. Their knowledge of the workarounds, the undocumented steps, the informal rules that keep things moving is the most valuable input available to the improvement design. A future state designed without that knowledge will have gaps.
The second is ownership. People support solutions they helped create. A process change that was designed in a meeting room and presented to the people who will implement it is a change that will be met with varying degrees of enthusiasm. A process change that the team helped design is one that they have already bought into before it is formally approved.

Practically, this means running co-design workshops rather than validation workshops. The difference is significant. A validation workshop says: here is what we have designed, please tell us what is wrong with it. A co-design workshop says: here is the problem we are trying to solve and the principles we are working to, help us design the solution. The second produces better designs and more engaged implementers.

Managing Resistance

Resistance to process improvement is not irrational. People resist change for reasons that make sense from their perspective, and the BA who treats resistance as an obstacle to be overcome rather than information to be understood will generate more of it. Most resistance to improvement initiatives comes from one of four places.

Fear that the change will make the work harder, or that it will eliminate the need for the person doing it.
Scepticism based on previous improvement initiatives that were announced with enthusiasm and then quietly abandoned.
Concern that the analysis missed something important, and that the proposed solution will not work.
Genuine disagreement about whether the identified problem is actually a priority compared to other things competing for the team's attention.

Each of these requires a different response. Fear requires honest conversation about the implications of the change and, where possible, concrete reassurance. Scepticism requires evidence that this initiative is being managed differently from previous ones, which usually means visible senior commitment and a realistic implementation timeline. Concerns about the analysis require taking those concerns seriously, checking whether they reveal a gap, and either addressing the gap or explaining clearly why the concern does not affect the proposed solution. Genuine priority disagreement requires an honest conversation at the appropriate level, not a communication exercise designed to bring people round.

The BA who listens to resistance, processes it analytically, and responds specifically to what they hear is the one who converts resistors into contributors. The BA who dismisses resistance as people being difficult is the one who implements changes that quietly fail to stick because the people responsible for running the new process never fully adopted it.

Measuring Whether the Change Worked

Measurement is the discipline that separates improvement from activity. An improvement initiative without measurement produces a story about change. An improvement initiative with measurement produces evidence of change. These are different things, and in organisations where resources for improvement work are limited, the BAs who can demonstrate measured outcomes are the ones who get the next improvement project.

Effective measurement in process improvement requires four things.

A baseline, established at the problem definition stage, that captures the current performance level before any change is made.
A target, defined in the future state design, that states what the process should perform like after the change.
A measurement mechanism, identified before implementation begins, that captures process performance data in a consistent and reliable way.
And a review point, scheduled at a defined interval after implementation, where the actual outcome is compared to the target.

The most common measurement failure in improvement work is defining success after implementation rather than before. When the baseline and target are not set in advance, the review conversation tends to focus on activity rather than outcome. The process was changed. People were trained. The new procedure was documented. Whether the change actually addressed the problem that motivated the initiative is harder to determine. Define success before you start. Measure it after you finish. Report the evidence honestly, including where the outcome fell short of the target. That honesty is what builds the credibility to lead the next initiative.

The BA as Improvement Leader

Leading a process improvement initiative is different from participating in one. The BA who leads takes responsibility for the full arc of the work, not just the analytical stages.

They hold the problem definition clearly throughout. They keep the stakeholder engagement live even when the immediate pressure to deliver tempts everyone to skip the co-design conversations.
They plan the implementation with the same rigour they bring to the analysis.
And they measure the outcome with the same honesty they bring to the diagnosis.

That combination of analytical rigour and delivery discipline is what distinguishes a BA who leads improvement from a BA who contributes to it. And it is the combination that makes improvement work stick rather than fade.

Go out and be successful.

Oluwatosin Ogunkoya | Flotog BA Insights | www.flotogbainsights.com

Tomorrow: The Process Improvement Toolkit. A practical reference guide to every tool from this week, with a free downloadable resource to use on your next improvement project.