Lean Six Sigma Without the Belts

I hold a Lean Six Sigma Black Belt and a Green Belt, and in more than a decade of requirements work, nobody has ever asked to see either of them. What gets used every week is something much smaller: two questions that took me far longer to learn than they take to explain. What does the customer count as a defect? And how much does this process vary from one case to the next? Those two questions are the working core of Lean Six Sigma, and neither needs a belt, a statistics package, or permission from a continuous improvement team. Yet many analysts quietly rule the whole discipline out. It sounds like something that belongs to factory floors and operations departments, with its own vocabulary, its own certificates and its own gatekeepers. So the useful parts never get applied where analysts actually work, which is a real loss, because those parts fix some of the most common weaknesses in BA output: vague problem statements, claims of improvement with no baseline behind them, and fixes that fade within a month of the project closing.

Two ideas under all the vocabulary

Lean is about waste, and the useful definition of waste is narrow: work or waiting that the customer would refuse to pay for if they could see it. A request that sits unopened in an inbox for three days is not being worked on. It is waiting, and the customer experiences that wait as part of the service. Handoffs between teams, rework caused by missing information, approvals that add no judgment, data typed by hand into a second system: these are the usual sources. Lean asks you to look at a process through the customer's eyes and sort every step into the ones they would recognise as value and the ones they are quietly paying for in time.

Six Sigma is about variation. Every process produces results that differ from case to case, and a customer almost never experiences the average. They experience their own case. A process that delivers in three days half the time and in twelve days the other half has an average of seven and a half days, and so does a process that delivers in seven and a half days every time, yet the customers of those two processes will describe their service in completely different terms. Six Sigma is a disciplined way of measuring that spread and then shrinking it. The name comes from a statistical target of roughly 3.4 defects per million opportunities, but the number matters far less to an analyst than the habit behind it: say what counts as a defect, count it, and look at how results are distributed instead of only at their average.

Put the two together and the division of labour is easy to remember. Lean makes a process faster and leaner. Six Sigma makes it predictable. Most complaints that sound like speed problems turn out to be predictability problems, because a customer can plan around a process that always takes five days far more easily than around one that usually takes three and occasionally takes fourteen.

What the belts are, and what they are not

The belt system is a credentialing structure built on top of those two ideas. A Yellow Belt understands the vocabulary and supports a project. A Green Belt leads improvement projects alongside a normal job, using the core toolset. A Black Belt leads larger and more statistically demanding projects and coaches others, usually in a dedicated improvement role. Master Black Belts sit above that, mostly shaping an organisation's whole programme. Training for the higher belts includes statistical methods such as hypothesis testing and regression, and a real project that has to show measured results before the certificate is awarded.

That structure exists for sensible reasons. Organisations running large improvement programmes need a shared language, a way to know who can lead what, and a way to keep project quality consistent across hundreds of projects. If the job you want is a continuous improvement or process excellence role, a belt is a recognised signal and, in some sectors, close to a requirement. For a BA role it is rarely asked for, and analyst candidates are not screened out for lacking one. As with any certification, the belt is a signal and the skill is something else. A Green Belt holder who never defines the defect before changing a process has a certificate and no habit. An analyst with no belt who always takes a baseline has the habit and no certificate. When a real outcome is at stake, the habit is what protects it.

There is a fair caution to add. The full statistical toolkit matters in some work. Where a problem involves heavy data volumes, many interacting factors, or errors that are expensive or dangerous, the Black Belt's tools earn their place, and a BA who reaches that ceiling should bring in someone who has them. Knowing where your own toolkit stops is part of the skill, and it is covered on Friday.

Where it already lives in BA work

Lean Six Sigma projects follow five phases, usually shortened to DMAIC: Define, Measure, Analyse, Improve, Control. Read those against the BA lifecycle and the overlap is large. Define is the problem statement, business case and scope. Measure is current state analysis. Analyse is gap analysis and root cause. Improve is solution options, design and trial. Control is implementation, handover and benefits tracking. The labels differ, and most of the activities are the same.

What the Lean Six Sigma versions add is rigour at three specific points, and these are exactly the points where BA work most often goes soft. First, the defect is defined in measurable terms before anyone proposes a fix. Second, a baseline is taken before anything changes, so that "it worked" is a comparison and not a feeling. Third, someone checks that the gain holds after the project team has moved on. Those three habits are the spine of this week.

To keep it concrete, one example runs through all five days: a property management team handling tenant fit-out requests, where tenants are promised a decision within five working days. The scenario is illustrative and the numbers are built to show the method, not drawn from a real client, but the pattern in them is one analysts meet constantly. Tomorrow starts where every project should start, with the question of what the customer actually counts as a defect.

Go out and be successful.

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

TOMORROW

Define: What Does the Customer Count as a Defect? - Turning "the process is slow" into a problem you can measure, and fitting the whole project on one page.