80% of a Kuwait bank's procurement cycle time lived in 3 approval queues. The full cycle averaged 139 days. After a gate-by-gate DMAIC project, it dropped to 57 days—a 59% reduction. This post walks through how they got there.
Published Lean Six Sigma case studies from APAC banking with actual numbers barely exist. You find frameworks described in general terms, success claimed in percentages with no baseline, and consultants citing studies they cannot link to. This case study is different. Every gate was measured. Every decision was documented.
If you work in banking process improvement, this is the anatomy of a project that worked.
Why Banking LSS Case Studies Are So Rare
Lean Six Sigma has a credibility problem in financial services. Research from major consulting firms estimates that 70% of large operational transformation programs fail to sustain results. That failure rate is not primarily a methodology problem. It is a documentation problem. The people who ran the project leave. The SLAs they negotiated stop being enforced. The SPC charts stop being reviewed. The institutional knowledge walks out with them.
Industry analysts estimate that operational inefficiency costs global banking $3 trillion annually. Yet the banks that do achieve meaningful Lean results (something close to 30% revenue improvement from process optimization) almost never publish what they did. Competitive sensitivity is part of it. The more honest reason is that most process improvement lives in individual heads rather than institutional systems. When the project champion moves on, so does the methodology.
That is the specific problem this Kuwait bank case study addresses. They did not just run DMAIC. They documented every gate in a form that could survive the departure of the people who built it.
Project Background: Procurement as a Diagnostic
The bank selected its procurement cycle as the pilot project deliberately. Procurement touches every department. It produces measurable cycle time data, has a clear internal customer, and generates enough transaction volume to support statistical analysis.
The baseline state before the project began:
- Mean cycle time: 139 days per procurement request
- Standard deviation: 18 days (moderate variation, not chaotic)
- Number of process steps: 23
- Approval layers: 8 sequential sign-offs
- Sample transactions analyzed: 87 over 6 weeks of measurement
Eighty percent of the elapsed time was concentrated in three approval queues: department head review (18 days average wait), finance review (22 days average wait), and vendor approval (31 days average wait). The remaining 20% was distributed across 20 other steps.
When 80% of cycle time lives in 3 of 23 steps, you have a targeting problem before you have a process problem.
DEFINE Gate: Bounding the Problem
The team opened with a SIPOC analysis (Suppliers, Inputs, Process, Outputs, Customers) to establish scope before touching any solution. The SIPOC revealed something easy to miss in procurement improvement projects: the actual customer of the procurement process is not the vendor. It is the internal department head waiting for budget release and purchase authorization.
Voice of Customer findings came from structured interviews with 14 department heads across the bank. The consistent theme: "We lose weeks waiting for approvals we don't understand." Not weeks waiting for decisions that required deliberation. Weeks waiting in queues with no visibility into where the request sat, who owned it, or when it would move.
The problem statement was refined after the SIPOC and VoC work:
The procurement approval cycle averages 139 days, with 80% of elapsed time concentrated in three approval queues. Department heads report no visibility into queue status and no mechanism to escalate stalled approvals. Current process design contains no SLA, ownership assignment, or escalation trigger.
That final sentence became the anchor for the entire Analyze gate. Scope was deliberately bounded to the approval workflow only, excluding vendor contracting, finance budgeting, and IT procurement. That boundary is one reason this project produced a result rather than a committee.
For a deeper grounding in DMAIC methodology applied to banking, see What Is DMAIC in Banking.
MEASURE Gate: Six Weeks of Real Data
Measurement ran for six weeks and covered 87 procurement transactions. The team tracked each transaction at the gate level, recording entry time, exit time, and whether the step required active decision-making or was simply waiting in a queue.
Key findings from the Measure gate:
- Mean cycle time confirmed at 139 days; median was 127 days, indicating right-skewed distribution from a subset of unusually long approvals
- Standard deviation of 18 days suggested the process was somewhat controlled but not capable of meeting any reasonable SLA
- Value-added ratio calculated at approximately 5%: of 139 days, roughly 7 days involved active work. The remaining 132 days were queue, wait, or re-work
- The three congested approval queues accounted for 71 of the 132 non-value-added days
The 5% value-added ratio is the number that changes conversations with leadership. If you present a 139-day cycle time, the natural response is that procurement is genuinely complex. If you present a 5% value-added ratio, the natural response is that complexity is not the issue. The queue structure is.
The measurement phase also identified that 80% of the documentation submitted with procurement requests was incomplete on first submission, triggering re-work loops before approvals could even begin. That finding informed the Control gate SOP design.
ANALYZE Gate: Fishbone to Root Cause
The team ran a full Ishikawa (fishbone) analysis across five cause categories: Method, Man, Machine, Measurement, and Environment.
The fishbone produced causes in each branch worth noting:
- Method: No SLA defined for approval steps; no escalation rule; sequential routing with no parallel path option
- Man: Approvers treated the queue as a secondary task; no performance metric tied to cycle time; no training on what "approvable" documentation looked like
- Machine: The digitized workflow replicated the paper approval sequence without adding automated alerts or deadline tracking
- Measurement: Procurement cycle time was not tracked as a KPI; no dashboard existed at department or finance level
- Environment: Culture of approval as a formality rather than a decision; approvers signed off without reviewing, or deferred without declining
The fishbone produced a long list of potential causes. The 5-Why drill on approval queue delays produced a direct path to root cause:
- Why are approval queues averaging 18–31 days? No deadline exists for approver response.
- Why is there no deadline? The approval workflow was designed without SLAs.
- Why was it designed without SLAs? Process design inherited from a paper-based system; digital automation replicated the paper flow without adding controls.
- Why were controls not added during digitization? No single owner was assigned responsibility for cycle time as a performance metric.
- Why was no owner assigned? Procurement cycle time was not tracked as a KPI at any level of the organization.
Root cause: The approval chain was designed without SLA, ownership, or escalation mechanism. Queue length, re-work loops, and department head frustration were symptoms of one structural gap—not three separate problems.
The digitization finding is worth pausing on. The bank had already moved from paper to a digital approval workflow before this project began. The digital system was faster at routing requests. It was not faster at approving them, because it preserved the structural flaws of the paper-based predecessor. Digitizing a broken process does not fix the process. It sometimes makes the queue more visible, which is not the same as shorter.
IMPROVE Gate: Reducing Approvals from 8 to 3
The improvement design had three components:
1. Risk-matched approval consolidation
The team mapped each of the 8 approval layers against the actual risk profile it was intended to manage. 3 of the 8 layers were redundant, reviewing information already reviewed upstream. 2 were informational only—the approver could not actually block the request. 1 was legacy compliance superseded by a newer regulatory framework.
Result: 8 approval layers reduced to 3, covering department head authorization, finance budget confirmation, and compliance sign-off for above-threshold purchases.
2. 48-hour SLA with auto-escalation
Each of the three remaining approval steps received a 48-hour SLA. Requests not actioned within 48 hours triggered automatic escalation to the approver's line manager. The escalation was visible to the requesting department head, ending the visibility gap that was the primary VoC complaint.
3. Parallel-path processing below threshold
For purchase orders below KWD 5,000 (approximately 68% of the 87 transactions measured in the baseline), finance review and department authorization were redesigned to run in parallel rather than sequentially. Above-threshold purchases retained sequential review for risk management reasons. The parallel path alone eliminated up to 18 days from the median cycle. Finance and department sign-off had previously been sequential even when neither step had a dependency on the other.
Pilot results: 30 transactions were run through the redesigned process over 6 weeks. Mean cycle time: 57 days. That is a 59% reduction against the 139-day baseline.
The pilot sample is small enough to note the limitation: 30 transactions cannot confirm the improvement holds across the full distribution, particularly for high-complexity or above-threshold requests. The 90-day post-deployment check addressed this.
CONTROL Gate: Making the Improvement Stay
Most LSS projects fail at this gate. The Improve gate produces a result. The Control gate determines whether that result still exists in 18 months—or was quietly abandoned six weeks after go-live.
The Kuwait bank's Control gate had three elements:
SOP deployment via ESSAM WhatsApp
Standard Operating Procedures for the redesigned approval process were distributed and acknowledged through the ESSAM platform's WhatsApp-integrated workflow. Week 1 acknowledgment rate: 78% of relevant staff. By week 3, that figure had reached 96% after the process owner followed up individually with the 22% who had not yet confirmed. The WhatsApp channel provided a documented record of who had received, read, and confirmed understanding of the new SOP, a requirement for the bank's internal audit trail.
This matters in banking more than in other industries. An unacknowledged SOP is an audit liability. A 78% acknowledgment rate in week 1, rising to 96% by week 3 with a documented follow-up trail, is a defensible compliance posture. That documentation did not require a separate compliance system. It was a byproduct of the WhatsApp-first deployment channel.
Statistical Process Control chart
An SPC chart was established for procurement cycle time, with control limits derived from the post-improvement pilot data. This gave the assigned process owner a weekly signal for whether the process was operating within expected parameters or drifting. The chart distinguished between common-cause variation (acceptable) and special-cause variation (requiring investigation).
Process owner with review cadence
A single named individual was assigned as process owner, with accountability for 30-day and 90-day review checkpoints. Both checkpoints were built into the process owner's performance objectives, not left as discretionary reviews.
The 90-day check confirmed the improvement was holding. Mean cycle time remained below 65 days. No significant special-cause variation had been flagged.
What Made This Project Work
Three decisions mattered most.
SIPOC bounded the scope before opinions could expand it. Improvement projects almost always have a scope problem. The SIPOC created a hard boundary around the approval workflow. The team could move from Define to Control without months of negotiation over scope.
The Measure gate concentrated effort on 3 of 23 steps. Without measurement, the instinct is to distribute effort broadly. The data made it obvious where to focus, and the 5-Why work confirmed the root cause was structural, not behavioral.
The control system ran during the pilot. The SOP, the SPC chart, and the process owner assignment were in place before the Improve gate closed. By the time the project formally ended, the control infrastructure had six weeks of operational data behind it.
The Institutional Memory Problem in Banking
Lean Six Sigma competence is built in individuals. The Black Belt who runs the project, the champion who sponsors it, the department head who cooperates with measurement: when those people leave, the improvement typically leaves with them. That is the mechanism behind the 70% failure rate for operational transformation programs. The methodology did not fail. It was stored in a person rather than a system—and when that person left, it left with them.
The Kuwait bank case is notable because the methodology was documented at every gate in a form that is not person-dependent. The SIPOC, the measurement logs, the fishbone, the SOP, the SPC chart parameters, and the process owner's review cadence: all of it exists as institutional knowledge. None of it is expertise carried in one person's head.
ESSAM's WhatsApp-first deployment model is designed around this constraint. Process SOPs distributed through a channel staff already use daily are more durable than training sessions and email attachments. The read-receipt audit trail is accessible to the compliance team without a separate report request. The improvement stays because the control system is embedded in tools people already use, not filed in a document management system that requires login credentials most staff have never set.
For analysis of how process automation ROI is measured across APAC banking, see Process Automation ROI in Banking APAC. For additional verified case material, see ESSAM Case Studies.
Applying This to Your Institution
The Kuwait bank procurement project is replicable. What it requires is discipline at each gate and a decision to treat documentation as a deliverable, not an admin task.
A few questions worth testing against your own procurement or approval workflows:
- What is your current mean cycle time, and do you have 6 weeks of transaction-level data to confirm it?
- What percentage of your cycle time is value-added versus queue wait?
- Does each approval layer have an owner, an SLA, and an escalation path?
- If the person who manages this process left tomorrow, what would remain?
If the answer is "not much," the methodology exists to change that. The Kuwait bank case shows what it looks like when documentation is a project deliverable, not an afterthought. And when the control system is deployed before the improvement is declared complete.
If you want to discuss how a gate-by-gate DMAIC project could work for a specific approval workflow at your institution, the ESSAM team works with banking operations teams across APAC. Contact them at apac.essam.ai/contact.
Frequently Asked Questions
What does Lean Six Sigma mean in a banking context?
Lean Six Sigma (LSS) in banking applies Lean waste-reduction principles and Six Sigma statistical rigor to financial services processes. It means identifying which steps add value, measuring the current state with transaction-level data, finding root causes of delays or defects, redesigning the process, and building controls that hold the improvement. Banking applications typically target approval workflows, onboarding cycles, compliance reporting, and loan processing.
How long does a DMAIC project typically take in banking?
Project duration varies significantly by scope and data availability. A bounded project focused on a specific workflow with existing transaction data can move from Define to Control in 16–24 weeks. The Kuwait bank procurement project ran approximately 20 weeks from project charter to 30-day control check. Projects with unclear scope, limited data, or high organizational complexity take longer and produce less reliable results.
Why do most banking LSS programs fail to sustain results?
The most common cause is a Control gate that exists on paper but not in practice. An SOP filed in a document management system is not a control mechanism. Neither is a dashboard that nobody reviews. Sustained improvement requires a named process owner, a measurement system that generates regular signals, and an escalation path when the process drifts. The Kuwait bank case is instructive because all three were built and tested during the pilot, not added after the project closed.
What is the E-S-S-A-M platform's role in an LSS project?
ESSAM functions as the deployment and control layer for process improvement. Where DMAIC generates redesigned workflows and SOPs, ESSAM handles acknowledgment, compliance documentation, and ongoing process monitoring through WhatsApp-integrated workflows that reach staff on the tools they already use. In the Kuwait bank case, ESSAM was used specifically for SOP deployment and read-receipt tracking during the Control gate, producing the 78% week-1 acknowledgment rate required for audit compliance.
Can this approach work for processes other than procurement?
Yes. The DMAIC structure applies to any process with measurable cycle time, a defined customer, and enough transaction volume to support statistical analysis. In banking, strong candidates include account opening, credit approval, compliance exception handling, and interbank settlement queries. The Kuwait bank chose procurement as a pilot specifically because it met all three criteria and could demonstrate results quickly enough to build organizational confidence for larger projects.