Moving Beyond Basic Define
In the Yellow Belt course, you learned to write a problem statement, create a SIPOC diagram, and draft a basic project charter. At the Green Belt level, the Define phase becomes significantly more sophisticated. You are now dealing with problems that span multiple teams, involve several competing quality requirements, and require formal financial justification before leadership will commit resources.
The Advanced Define phase is where Green Belt projects succeed or fail. A poorly scoped project will either collapse under its own complexity or deliver results that no one cares about. A well-scoped project has a clear, bounded problem, measurable targets tied to business outcomes, and aligned stakeholders who understand exactly what will be delivered and by when.
Complex Problem Statements with Multiple CTQs
At the Yellow Belt level, your problem statement typically had a single Critical-to-Quality (CTQ) requirement — for example, "trade settlement failures exceed 500 per month against a target of less than 200." At the Green Belt level, real problems rarely have a single dimension.
Consider the KYC remediation challenge. The bank needs to:
- CTQ 1 (Speed): Complete remediation of 85,000 customer records within 10 months
- CTQ 2 (Quality): Achieve a first-time-right rate of at least 95% (cases that pass quality assurance review without rework)
- CTQ 3 (Risk Coverage): Prioritize high-risk customers (PEPs, high-value accounts, correspondent banking relationships) for early remediation
- CTQ 4 (Cost): Deliver within the allocated budget of $4.2M (covering temporary staff, technology tools, and overtime)
These CTQs can conflict. Pushing for speed (CTQ 1) may reduce quality (CTQ 2). Prioritizing high-risk customers first (CTQ 3) may slow down the overall throughput because these cases are more complex. Adding temporary staff to increase throughput impacts cost (CTQ 4).
Structuring Multi-CTQ Problem Statements
A Green Belt problem statement for a multi-CTQ project should follow this structure:
Problem: [What is happening, quantified with current performance data]
Impact: [Why it matters — financial, regulatory, customer, operational]
CTQs: [List each measurable quality requirement with current baseline and target]
Scope: [What is included and excluded]
Constraints: [What cannot be changed — regulatory requirements, technology freezes, budget limits]
Example:
Problem: The bank's KYC remediation program for retail banking is completing an average of 350 cases per week against a required run-rate of 520 cases per week to meet the regulatory deadline. First-time-right rate is currently 72%, generating significant rework that further reduces effective throughput.
Impact: At the current rate, the retail division will miss the regulatory deadline by approximately 14 weeks, exposing the bank to potential enforcement action. The rework loop is consuming an estimated 35% of analyst capacity.
CTQ 1: Throughput — increase from 350 to 520+ cases per week
CTQ 2: First-time-right rate — increase from 72% to 95%+
CTQ 3: High-risk prioritization — 100% of high-risk cases completed within first 4 months
CTQ 4: Cost — deliver within the $1.8M retail allocation
Scope: Retail banking KYC remediation only. Corporate and private banking are out of scope.
Constraints: Regulatory standard is fixed (cannot renegotiate requirements). Core KYC system cannot be changed within the project timeline. Temporary staff budget capped at 15 FTEs.
CTQ Prioritization
When CTQs conflict, you need a clear priority hierarchy. In banking, the default priority is:
- Regulatory compliance — non-negotiable requirements from regulators
- Risk management — controls, coverage, and accuracy
- Customer experience — service quality and timeliness
- Cost efficiency — within budget, minimizing waste
Document this hierarchy explicitly in your project charter and confirm it with your sponsor. When you face a trade-off decision during the project (and you will), you can reference this agreed hierarchy rather than relitigating priorities.
Multi-Stream SIPOC for Cross-Functional Processes
A basic SIPOC (Suppliers, Inputs, Process, Outputs, Customers) captures a single process flow. Cross-functional banking processes require a multi-stream SIPOC that shows how parallel workstreams interact, where handoffs occur, and what dependencies exist between them.
Building a Multi-Stream SIPOC
For the KYC remediation program, the multi-stream SIPOC might look like this:
Stream 1 — Case Identification & Prioritization
| Element | Detail |
|---|---|
| Suppliers | Risk scoring system, customer master database, previous KYC records |
| Inputs | Customer risk scores, existing documentation, remediation criteria matrix |
| Process | Extract customer population → Apply risk scoring → Prioritize cases → Assign to remediation queues |
| Outputs | Prioritized case list, queue assignments, daily allocation reports |
| Customers | Stream 2 (Analyst Remediation), management reporting |
Stream 2 — Analyst Remediation
| Element | Detail |
|---|---|
| Suppliers | Stream 1 (prioritized cases), customer relationship managers, external data providers |
| Inputs | Case assignments, customer documentation, screening results, risk assessment templates |
| Process | Review existing documentation → Identify gaps → Request missing information → Complete risk assessment → Submit for QA |
| Outputs | Completed remediation cases, documentation packages, risk assessments |
| Customers | Stream 3 (Quality Assurance), regulatory reporting |
Stream 3 — Quality Assurance
| Element | Detail |
|---|---|
| Suppliers | Stream 2 (completed cases), QA framework, regulatory standards |
| Inputs | Completed cases, QA checklists, sampling methodology |
| Process | Sample cases for review → Assess against quality standards → Approve or return for rework → Track QA metrics |
| Outputs | Approved cases, rework queue, QA pass rate metrics, defect categorization |
| Customers | Stream 2 (rework loop), regulatory reporting, senior management |
The critical insight from this multi-stream SIPOC is that Stream 3 creates a feedback loop to Stream 2. Every case that fails QA re-enters the analyst remediation queue, consuming capacity that should be used for new cases. This is why improving first-time-right rate (CTQ 2) is essential to achieving throughput targets (CTQ 1) — the two CTQs are interdependent, not independent.
Advanced Project Charters with Financial Quantification
A Green Belt project charter goes beyond the basic charter format to include rigorous financial quantification and explicit success criteria. This is the document that secures executive buy-in and resource allocation.
Charter Components
1. Business Case
The business case answers "why should we invest in this project?" It includes:
- Current state pain point — quantified with data, not anecdotes
- Strategic connection — which organizational priority does this address?
- Cost of inaction — what happens if we do nothing? (In banking, this is often regulatory penalty, operational loss, or customer attrition)
- Projected benefits — conservative estimate of financial and non-financial improvements
2. Financial Quantification
Work with your finance business partner to establish:
- Benefit categories: Hard savings (FTE reduction, vendor cost reduction), soft savings (productivity improvement, capacity creation), cost avoidance (penalties avoided, losses prevented), revenue impact (faster time-to-market, reduced customer attrition)
- Calculation methodology: How will you calculate FTE savings? (Fully loaded cost including salary, benefits, overhead, typically $75-120K per FTE in banking operations depending on location and seniority)
- Baseline measurement: What is the current cost that you will improve against?
- Conservative projection: Use the low end of your estimated improvement range
- Benefits realization timeline: When will savings begin to flow? (Often 1-3 months after implementation)
Example Financial Quantification:
| Benefit Category | Calculation | Annual Value |
|---|---|---|
| Rework reduction | 28% of analyst time spent on rework × 45 FTEs × $90K avg cost = 12.6 FTEs freed | $1,134,000 |
| Overtime elimination | Current overtime: $18K/month × 12 months | $216,000 |
| Temporary staff reduction | Faster completion allows 5 temps to finish 2 months early × $6K/month | $60,000 |
| Penalty avoidance | Meeting regulatory deadline avoids potential fine (not quantified as hard saving) | Risk mitigation |
| Total quantified annual benefit | $1,410,000 |
3. Scope Statement
Be ruthlessly specific about what is in scope and out of scope:
- In scope: Retail banking KYC remediation process (case allocation, analyst remediation workflow, quality assurance loop)
- Out of scope: Corporate banking, private banking, new-to-bank KYC onboarding, core system replacement, regulatory standard changes
- Interfaces: Customer contact process (in scope only where it affects case cycle time), IT system performance (in scope only for data extraction)
4. Success Criteria
Define quantitative success criteria that will be measured at project closure:
- Weekly throughput sustained at 520+ cases/week for 4 consecutive weeks
- First-time-right rate of 95%+ sustained for 4 consecutive weeks
- 100% of high-risk cases completed by month 4
- Delivered within $1.8M retail allocation
Risk Assessment for Improvement Projects
Every project has risks. In banking, the consequences of overlooked risks can include regulatory penalties, operational losses, reputational damage, and customer harm. A Green Belt should conduct a formal risk assessment during Define and update it throughout the project.
Risk Identification
Common risk categories for banking improvement projects:
Data Risks
- Required data does not exist or is unreliable
- Data extraction takes longer than planned
- Historical data contains inconsistencies due to system migrations
Stakeholder Risks
- Sponsor changes role during the project
- Process owner is resistant to change
- Competing priorities divert team members' attention
Scope Risks
- Regulatory requirements change mid-project
- Root cause analysis reveals the problem is larger than initially thought
- Solution requires technology changes that extend the timeline
Implementation Risks
- IT change request is delayed or deprioritized
- New process creates unintended downstream impacts
- Staff training takes longer than planned
Operational Risks
- Process changes inadvertently weaken controls
- Volume spikes during implementation overwhelm the new process
- Parallel running of old and new processes causes confusion
Risk Assessment Matrix
For each identified risk, assess:
- Probability (1-5): How likely is it to occur?
- Impact (1-5): How severely would it affect the project?
- Risk Score: Probability × Impact
- Mitigation: What actions will reduce probability or impact?
- Owner: Who is responsible for monitoring and mitigating?
| Risk | Prob | Impact | Score | Mitigation | Owner |
|---|---|---|---|---|---|
| Data quality issues in legacy KYC records | 4 | 4 | 16 | Conduct data quality assessment in first 2 weeks; build data cleansing into process | Green Belt |
| Sponsor reorg during project | 2 | 5 | 10 | Identify backup sponsor; document project business case for continuity | Green Belt |
| Regulatory standard update mid-project | 3 | 4 | 12 | Monitor regulatory pipeline; build flexibility into solution design | Compliance SME |
| IT system change delayed | 3 | 3 | 9 | Design process improvements that do not depend on IT changes for Phase 1 | Technology lead |
| Analyst resistance to standardized workflow | 3 | 3 | 9 | Involve senior analysts in solution design; run pilot with volunteer team | Process Owner |
Risks scoring 12 or above should be actively managed with specific mitigation actions. Risks scoring 6-11 should be monitored regularly. Risks scoring 5 or below can be accepted and reviewed at tollgates.
Project Risk Assessment Matrix
| Probability | Impact | Risk Score | |
|---|---|---|---|
| Data quality issues | 4 | 4 | 16 |
| Regulatory change | 3 | 4 | 12 |
| Sponsor reorganisation | 2 | 5 | 10 |
| IT system delay | 3 | 3 | 9 |
| Analyst resistance | 3 | 3 | 9 |
Banking Example: KYC Remediation Program — Define Phase
Let us walk through the complete Advanced Define output for the retail banking KYC remediation project.
Situation
A major bank received a regulatory enforcement notice requiring the remediation of all existing customer KYC records to a new, enhanced standard. The total population across all divisions is 85,000 customers. The retail banking division accounts for 52,000 of these records. The bank has been given 10 months to complete the remediation.
After 2 months of effort, the retail team has completed only 2,800 cases (350/week average). At this rate, they will need an additional 35 months — missing the deadline by approximately 25 months. The QA team is rejecting 28% of submitted cases, creating a rework loop that consumes roughly one-third of analyst capacity.
Define Phase Outputs
The Green Belt on this project would produce the following Define deliverables:
1. Validated Problem Statement: As documented above in the multi-CTQ format.
2. Multi-Stream SIPOC: As documented above, revealing the critical rework loop between QA and analyst remediation.
3. Stakeholder Map: Identifying the Head of Retail Ops (sponsor), KYC Remediation Program Lead (key stakeholder, potential conflict due to defensiveness about current approach), Compliance (regulatory liaison), IT (data extraction support), Finance (benefits validation), and the analyst team (frontline users).
4. Project Charter: Including the financial quantification, scope statement, and success criteria documented above.
5. Risk Assessment: Including the risk matrix above with active mitigation plans for high-scoring risks.
6. Project Plan: A high-level timeline showing DMAIC phases mapped to weeks, with tollgate dates, key milestones, and dependencies.
The Define tollgate review would present these deliverables to the sponsor and a peer reviewer. Key questions at the tollgate include: Is the problem clearly defined and quantified? Are the CTQs measurable? Is the scope appropriate for a Green Belt project? Are the right stakeholders engaged? Has the financial opportunity been validated with finance?
Upon passing the tollgate, the project moves to the Measure phase, where the Green Belt will collect detailed process data to understand the current state performance and identify where the critical defects and delays occur.
Key Takeaways
- Green Belt projects require multi-CTQ problem statements that acknowledge complexity and trade-offs
- Multi-stream SIPOCs reveal cross-functional handoffs and feedback loops that drive defects
- Financial quantification must be developed in partnership with finance using conservative, agreed-upon assumptions
- Risk assessment is proactive, not bureaucratic — it prevents project derailment
- Scope discipline is critical: it is better to deliver strong results on a narrow scope than mediocre results on an unmanageable scope
- In banking, regulatory imperatives and control requirements constrain solution design — identify these constraints early
- Tollgate reviews ensure rigor and alignment before committing to the next phase
In the next module, we will explore Measurement System Analysis — ensuring that the data you rely on for root cause analysis and hypothesis testing is actually trustworthy and consistent.