30% of annual revenue. That is what broken processes cost a mid-size bank every year. For a $500M institution, that number is $150M disappearing into rework, waiting time, and approval chains that exist because someone added them in 2014 and nobody questioned the decision since.
You built the spreadsheet. The numbers were solid. Management still said no.
I have watched this happen in three separate banks across GCC procurement and loan origination functions between 2024 and 2026. The ROI calculation was never the problem. The framing was.
Why ROI Presentations Get Rejected
Management does not walk into ROI presentations looking for new information. They walk in looking to confirm what they already believe. A senior Lean Six Sigma practitioner with 20 years of consulting across financial services described it after watching dozens of these meetings end the same way: "They are not looking at you to uncover the cause. They are looking at you to prove them right."
This means the standard approach (hours saved multiplied by hourly rate) fails before you open the slide deck. The conclusion does not match what leadership already decided.
The rejection pattern I have observed follows a predictable sequence:
- You present efficiency gains (hours saved, steps removed)
- Finance asks how you will measure the savings
- You explain the before-and-after methodology
- Someone asks whether the savings are "hard" or "soft"
- The conversation stalls on attribution
80% of Black Belt time goes to documentation rather than improvement. That documentation overhead means by the time you finish building the ROI case, 3 months have passed and leadership's attention has moved to the next budget cycle.
Hard Savings vs Soft Savings: What CFOs Accept
CFOs split process improvement claims into two categories. Only one gets budget.
Hard savings appear in the general ledger within 12 months. Examples: headcount not replaced after attrition, vendor contracts renegotiated downward, penalty fees eliminated, cycle time reduction that directly reduces overtime or temporary staffing. These are auditable. They survive scrutiny because the finance team can trace them in the P&L.
Soft savings are capacity releases: "we freed up 400 hours per month." Finance hears this as theoretical redistribution. In a 2024 procurement transformation project I worked on, the operations team presented 2,100 hours of annual capacity release. The CFO's response: "Show me which line item decreases." The project was deferred for 6 months until the team reframed it as constraint-cost reduction.
The distinction matters because constraint-cost language converts soft savings into hard numbers. The same 2,100 hours, expressed as "$567K in annual process consumption cost that reduces to $232K," gets approved. The math is identical. The frame is different.
The Constraint-Cost Formula
This is the formula that gets projects approved:
Annual constraint cost = (Cycle time in days) x (Daily transaction volume) x (Loaded cost rate per day)
Each variable is measurable before the project starts, during the DMAIC Measure phase:
- Cycle time: End-to-end elapsed time from trigger to completion, including all waiting. Measured by timestamping 30+ process executions from system logs or manual observation.
- Daily transaction volume: How many times this process executes per business day. For a procurement cycle, that might be 4 purchase orders per day. For loan origination in a mid-size bank, 15-40 applications per day depending on product type.
- Loaded cost rate per day: Fully loaded labor cost divided by working days. Include base salary, benefits, facilities allocation, and IT cost per seat. The multiplier over base salary is typically 1.3x for lean teams and 1.5x for heavily facilitated environments. For a procurement team of 3 at $85K loaded salary each: ($255K / 250 working days) = $1,020 per day the process runs.
The formula produces a number finance recognizes immediately: this process is consuming $X per year in its current state. The improvement case becomes: we reduce that consumption by Y%, saving $Z annually in hard, auditable constraint-cost reduction.
Setting a Baseline in the DMAIC Measure Phase
Without a baseline, your ROI number is a projection. With one, it is an audit that finance can verify against source systems.
Baseline data collection in practice:
- Process mapping: Document every step from trigger to completion. Not the official process flow from the 2019 policy document, but the actual process as it runs today, including workarounds staff have invented. ESSAM captures this through structured conversation in approximately 40 minutes by asking process owners to describe what actually happens, step by step.
- Cycle time measurement: Timestamp the start and end of 30+ process executions. Calculate mean, median, and P90. In the Kuwait bank procurement case, the mean was 139 days but P90 was 187 days. One in ten purchase orders took over 6 months. The gap between mean and P90 reveals your worst-case constraint and is often the number that gets executive attention.
- Cost allocation: Assign loaded labor cost to each step. Use the 1.3x to 1.5x multiplier on base salary. The gap between base and loaded cost matters when presenting to a CFO. A team that appears to cost $180K at base salary actually costs $255K fully loaded. That is the number the CFO uses when evaluating headcount decisions.
- Waste identification: Tag each step as value-adding, necessary non-value-adding, or pure waste. The E-S-S-A-M framework classifies each step: Eliminate (pure waste), Simplify (reduce complexity), Standardize (remove variation), Automate (remove manual effort), Migrate (move to lower-cost execution). In the Kuwait bank case, 11 of 23 steps were tagged as overprocessing: approval layers that did not match the risk level of the transaction.
The Kuwait Bank Worked Example
A mid-size bank in Kuwait ran procurement through a 23-step approval chain. The process took 139 days from requisition to purchase order completion. The procurement team had flagged cycle time as a problem for 2 years before the DMAIC project was approved.
Baseline measurement (collected over 6 weeks, 34 procurement transactions sampled):
- Cycle time: 139 days mean, 187 days P90
- Steps: 23 (mapped via process owner interviews + system timestamp analysis)
- Approval layers: 8 (3 of which approved the same risk threshold)
- Daily transaction volume: 4 purchase orders
- Team: 3 procurement specialists at $85K loaded annual cost each
- Loaded daily cost: $1,020/day
Annual constraint cost calculation: 139 days x 4 POs/day x $1,020 = $567,120 per year consumed by a single procurement cycle class
After process improvement (DMAIC applied over 14 weeks):
- Cycle time: 57 days (59% reduction)
- Steps: 12 (11 steps eliminated, primarily duplicate approvals and manual re-keying between systems)
- Approval layers: 4 (consolidated from 8; risk-appropriate thresholds maintained)
Post-improvement annual cost: 57 days x 4 POs/day x $1,020 = $232,560
Annual hard saving: $334,560 in constraint-cost reduction.
This number survived CFO review because every input was documented during the Measure phase. The cycle time was timestamped from the ERP system. The cost rate came from HR's loaded-cost model. The transaction volume came from procurement system records. No assumptions required.
When the Constraint-Cost Frame Does Not Work
The reframe is not universal. It fails in two specific conditions:
-
When the constraint is already acknowledged but deprioritized. In a GCC retail bank in 2025, the operations team presented a $410K constraint-cost calculation for their KYC onboarding process (67 days, should be 21). Leadership acknowledged the number, then chose to allocate capital to a regulatory compliance project instead. The constraint was real. The competing priority was bigger. In this case, the failure was not framing. It was timing against a regulatory deadline.
-
When the process owner lacks authority over the constraint. If the 139-day cycle time exists because 4 of the 8 approval layers belong to a different department, the constraint-cost number is correct but the improvement path requires cross-functional sponsorship. Present the number to the person who owns the constraint, not the person who suffers from it.
These cases do not invalidate the formula. They clarify that the right number still requires the right audience and the right timing.
The Presentation Sequence That Gets Approval
The presentation that works follows this structure:
- Name the constraint leadership already acknowledges ("Our procurement cycle takes 139 days. Industry benchmark for similar transaction complexity is 45-60 days.")
- Quantify the constraint cost using the formula ($567K/year for a single process class)
- Show the improvement path: DMAIC phases, 14-week timeline, team of 3 plus one Black Belt
- State the projected outcome based on waste identification (11 overprocessing steps identified)
- Close with the annual hard saving and 12-month payback period
This works because it asks management to act on something they already acknowledge, with a dollar figure attached.
Run Your Process Through the Calculator
ESSAM's free process cost calculator generates the constraint-cost number that opens this conversation. Input your cycle time, transaction volume, and team size. The output is the annual constraint cost, which belongs on slide one of your ROI presentation.
Use it here: /tools/process-cost-calculator
The presentation that gets rejected leads with "we can save hours." The one that gets approved leads with "this process is consuming $567K per year, here is the measured path to $334K in annual reduction, payback within 8 months."
Frequently Asked Questions
What is a "hard saving" vs a "soft saving" in process improvement ROI?
A hard saving appears in the general ledger within 12 months: headcount not replaced, contracts renegotiated, penalties eliminated, and overtime reduced. A soft saving is released capacity ("we freed 400 hours") that does not reduce actual spend. CFOs fund hard savings because they can trace them in the P&L. They question soft savings because the line item does not change.
How do I calculate ROI before the project starts (before I have baseline data)?
You estimate using the constraint-cost formula with available data: current cycle time (ask the team or pull from system timestamps), daily volume (from transaction records), and loaded cost (from HR/finance). The estimate gets the project approved. The DMAIC Measure phase then produces the auditable baseline that validates or corrects the estimate. In the Kuwait bank case, the pre-project estimate was $520K; the measured baseline was $567K—within 9% of the estimate.
What ROI timeframe should I present to management?
12-month payback is the safest primary metric. Finance teams trust it because it avoids compounding assumptions and matches annual budget cycles. Include 3-year NPV as a supporting exhibit for projects requiring upfront platform investment, using your organization's weighted average cost of capital (typically 8-12% for banks) as the discount rate.
How do I isolate process improvement impact from other changes?
Use the DMAIC Control phase methodology: measure the same KPIs post-improvement that you measured during the baseline. The Kuwait bank team measured cycle time weekly for 12 weeks post-implementation to confirm the 57-day average held. If other changes occurred simultaneously, use time-series analysis showing the step-change at implementation date. The discontinuity is the attribution evidence.
What ROI should I expect from a process improvement project?
The Kuwait bank procurement case delivered 59% cycle time reduction and $334K annual constraint-cost saving on a 14-week project. Across banking process improvement projects with significant waiting waste and overprocessing, cycle time reductions of 40-70% are typical. The constraint-cost saving scales linearly with transaction volume. Higher-volume processes produce larger absolute savings from the same percentage reduction.
Related reading: