The Measure Phase
The Measure phase is where opinions give way to evidence. In the Define phase, you articulated the problem and scoped the project. Now you need to answer a deceptively simple question: how is the process actually performing today?
Many banking teams believe they know their process performance, but their understanding is often based on anecdotal experience or incomplete data. The Measure phase forces rigour. You will map the process as it truly operates (not as the procedure manual says it should), design a data collection plan, compute baseline statistics, and assess whether the process is capable of meeting customer requirements.
The golden rule of the Measure phase: measure the process as it is, not as you wish it were.
Process Mapping
Current-state process mapping is the first critical activity. You are documenting exactly how work flows through the process today — every step, every decision point, every handoff between teams, and every place where work sits waiting.
The most effective format for banking operations is a swimlane diagram, where each horizontal lane represents a different role or team. This immediately exposes handoffs, which are one of the biggest sources of delay and error in financial services.
When mapping a process, capture the following for each step:
- Activity — What is being done (e.g., "Verify counterparty details")
- Actor — Who performs it (e.g., "Settlements analyst")
- System — What tool or application is used (e.g., "Bloomberg TOMS")
- Cycle time — How long the step takes when someone is actively working on it
- Wait time — How long work sits idle between steps (in queues, awaiting approvals)
- Rework loops — Where does work get sent back for correction?
In banking, you will often discover that wait time far exceeds processing time. A reconciliation break that takes 20 minutes to investigate may sit in a queue for 3 days before anyone looks at it.
Data Collection Plans
Before you start pulling data, you need a structured plan. Jumping into data extraction without a plan leads to wasted effort, inconsistent measurements, and data that does not answer the questions you need answered.
A data collection plan specifies:
- What to measure — Define your output metric (Y). For a cash reconciliation process, this might be "break resolution cycle time" measured in business days from break identification to resolution.
- Operational definition — Remove ambiguity. When exactly does the clock start? When the break is auto-detected by the system? When an analyst first opens it? Define this precisely so everyone measures the same thing.
- How to measure — System extract from the breaks management platform, manual log, or sampling. Automated extraction from source systems is always preferable to manual data collection.
- Who collects it — Assign a responsible person. In banking, this is often a senior analyst or team lead who has system access and understands the data.
- How often and how much — Daily extraction over a 3-month period typically provides sufficient data. For low-volume processes, you may need 6 months. Ensure the sample is large enough to be statistically meaningful and representative of normal operating conditions.
Basic Statistics for Process Performance
With data in hand, you calculate the statistics that describe your process baseline. At the Yellow Belt level, you need to be comfortable with five foundational measures:
Mean (average) — The sum of all values divided by the count. If you measured 200 reconciliation break resolution times and the total was 840 days, the mean is 4.2 days.
Median — The middle value when data is sorted. The median is often more useful than the mean in banking because a few extreme outliers (a break that takes 30 days due to a legal dispute) can skew the average. If the median is 3.5 days but the mean is 4.2 days, you know outliers are pulling the average up.
Standard deviation (σ) — The measure of spread around the mean. This is the most important statistic in Six Sigma because it quantifies variation. A standard deviation of 1.1 days means that approximately 68% of reconciliation breaks are resolved between 3.1 days (mean minus one σ) and 5.3 days (mean plus one σ).
Range — The difference between the maximum and minimum values. Simple but useful for spotting extreme outliers.
Mode — The most frequently occurring value. Less commonly used, but helpful for understanding the most typical experience.
A process with a low mean but high standard deviation is unpredictable. A process with a higher mean but low standard deviation is at least consistent. Six Sigma aims for both — a low mean and low variation.
Process Capability: Cp and Cpk
Process capability answers the question: can this process consistently deliver output within the customer's specification limits?
The two key metrics are Cp (process potential) and Cpk (process capability index). At the Yellow Belt level, focus on understanding Cpk, which accounts for both the spread of your data and how centred it is relative to the customer's specification.
Consider our reconciliation example. The customer requirement is that breaks must be resolved within 5 business days (the upper specification limit, or USL). Our process has a mean of 4.2 days and a standard deviation of 1.1 days.
Cpk = (USL - Mean) / (3 x σ) = (5.0 - 4.2) / (3 x 1.1) = 0.8 / 3.3 = 0.24
A Cpk of 0.24 is well below 1.0, which tells us this process is not capable of reliably meeting the 5-day specification. Even though the mean (4.2 days) looks acceptable, the variation is so high that a significant proportion of breaks exceed the 5-day limit.
- Cpk < 1.0 — Process is not capable. Outputs frequently fall outside spec.
- Cpk = 1.0 — Process is minimally capable. It just barely meets spec.
- Cpk = 1.33 — Process is capable. This is the typical minimum target.
- Cpk ≥ 2.0 — Process is highly capable. Very few defects.
Banking Example: Baselining Cash Reconciliation
Let us walk through a complete Measure phase for a cash reconciliation process at a mid-sized investment bank.
Step 1: Map the process. The team creates a swimlane diagram covering four roles: the automated reconciliation engine, the junior analyst (who investigates breaks), the senior analyst (who approves resolutions), and the finance controller (who signs off on adjustments). They discover 14 process steps, 3 decision points, and 2 rework loops. Critically, they find that breaks sit in the senior analyst's approval queue for an average of 1.8 days — nearly half the total cycle time.
Step 2: Collect data. They extract 6 months of break resolution data from the reconciliation platform — 4,200 breaks in total. For each break, they capture: break type, dollar value, date identified, date resolved, analyst assigned, and number of times escalated.
Step 3: Calculate the baseline. The mean resolution time is 4.2 business days with a standard deviation of 1.1 days. The median is 3.5 days, confirming that high-value or complex breaks are pulling the mean upward. The defect rate (breaks exceeding the 5-day SLA) is 18.3%.
Step 4: Assess capability. With a Cpk of 0.24, the process is clearly not capable. The team now has an objective, data-driven baseline that tells them exactly how the process performs — and precisely how much improvement is needed.
This baseline becomes the benchmark against which all future improvements will be measured. In the next module, we move to the Analyze phase, where we will use root cause analysis tools to understand why the process behaves this way.