Control: Making the Gain Stay

The pilot worked, the numbers moved, the sponsor was pleased and the project closed on schedule. Six months later the process has drifted back to where it started, and nobody can say when it slipped. The engineer who knew why there was a Monday slot has moved teams, a new coordinator was never told about it, and nobody was watching the one number that would have shown the slide. This is the most common ending for improvement projects that otherwise did everything right, and it is the reason Control is a full phase of DMAIC. Improvements do not hold by themselves. A process drifts toward whatever its people, habits and incentives support, so a gain that is not deliberately anchored is a gain on loan.

Control is a plan, not a hope

A control plan is short, and it answers five questions in writing. Who owns the result after the project team leaves? Which measure will they watch, and how often? What counts as a signal that the process is slipping? What do they do when that signal appears? And how will new people learn the changed way of working? For the fit-out example the answers fit on a page. The owner is a named property operations manager. The measure is the share of requests decided later than five working days, plotted weekly on a run chart. The trigger is a late share above 15 percent for two consecutive weeks. The response is a review of the previous fortnight's late cases within five working days. And the updated procedure, including the Monday slot, goes into the induction pack for every new coordinator.

Not all control measures are equally strong, and it helps to rank them. At the top is building the change into the process so that the wrong path becomes hard or impossible: an intake form that automatically flags a request needing engineer review and books the next available slot removes the need for anyone to remember. Below that sit checklists, then training, then reminders, and at the bottom is simply hoping people will recall the new rule. Wherever a gain depends on memory it will eventually be lost, so push each control as far up that ranking as the budget allows.

Finally, schedule the handover and the follow-ups. Review the measure at 30, 60 and 90 days, then hand the monitoring to the owner as ordinary business. The first reviews catch fast drift while the project team still remembers the intent, and the handover makes it clear that the process now belongs to the people who run it, with their own signal and their own response.

One habit makes every control stronger: write down what the process would look like if the change were quietly undone. For the fit-out example, that picture is engineer-review requests piling up on Wednesdays and the late share creeping back toward 25 percent. Writing it down turns a vague worry into a specific warning sign, and it gives the owner something concrete to watch for on the run chart rather than a general instruction to keep an eye on things.

Mapping DMAIC onto the BA lifecycle you already run

Step back and the week's shape becomes clear. Define is the problem statement, business case and scope you already write. Measure is the current state analysis you already do, with a defined measure and a baseline. Analyse is gap analysis and root cause, with the data split to show where failures concentrate. Improve is solution design, with an added step of trial before rollout. Control is implementation and benefits realisation, with an owner and a trigger attached. You do not need to adopt a new methodology. You need to add five habits to the one you already run:

• Define the defect in the customer's terms, and write the clock's start and stop points down.
• Take the baseline before changing anything, and report the share that fails, not only the average.
• Split the data by the factors you recorded, and look for the small group producing most of the failures.
• Pilot with success criteria agreed in advance, and check for side effects before scaling.
• Name an owner, a measure and a trigger before the project closes.

None of those needs a belt, a statistics package or a dedicated improvement team. Any one of them, added to a project that currently lacks it, makes the work more credible, and together they change how an analyst's results are received, because every claim arrives with a before-number, a method and an owner.

When full Lean Six Sigma is more than you need

A fair view of the discipline includes its limits. Re-timing one engineer review slot did not need a Black Belt, or even a Green Belt. It needed a clear defect, a spreadsheet, a split of the data and a pilot. The heavier statistical machinery, including hypothesis testing, regression and designed experiments, pays for itself when volumes are large, when many factors interact, or when small differences carry a high cost, as in manufacturing, healthcare or financial processing. If you cannot separate the effect of one change from another, or if a one percent shift moves real money, you have likely reached the ceiling of the habits above, and it is time to bring in someone with the full toolkit or to build it yourself.

If the second path appeals, treat the decision the way the certifications week suggested: ask whether the roles you want require it, whether your real gap is knowledge or evidence, and whether you can afford the study time. For analysts aiming at continuous improvement or process excellence roles, a Green Belt is the sensible first step. For most BA roles, the five habits come first, because they travel into every project you touch without an exam in between.

This is one of the areas I coach analysts on through the process improvement track at Flotog BA Insights, usually by taking a live problem from the analyst's own work and running it through these five phases together. The sequence is simple to learn and surprisingly hard to apply on your own the first time, because it asks you to slow down at exactly the moments when everyone around you wants to move fast.

Go out and be successful.

Oluwatosin Ogunkoya · Flotog BA Insights · 1:1 mentoring and coaching for BAs at every career stage · www.flotogbainsights.com

NEXT WEEK

API Literacy - What an API actually is, and the questions a BA can ask engineers without pretending to code.