LEARN. PRACTICE. GROW.Concept and mechanism
Technical delivery needs follow-up assessment of the outcome that justified the change. If the goal is fewer manual exceptions, server uptime does not measure that benefit, although it remains useful operationally. Define the population, period, counting rule, and measurement owner. Establish a comparable baseline before concluding improvement. Data source and exclusions matter too: no longer counting a problematic product may improve the chart without improving service. Combine outcome measures with effort, quality, and stakeholder experience when doing so helps explain the effect.
Guided application
Consider 80 exceptions in 2,000 transactions before and 60 in 1,000 afterwards. Count fell, but the rate moved from 4% to 6%, an increase of two percentage points or 50% in relative terms. That is not fifty percentage points. Even correct arithmetic does not prove the release caused the difference: the second period may contain more complex products. Segment where needed and seek comparable conditions. An acceptable average response may hide long waits for large files. Examine relevant distributions and percentiles without excluding the very cases the business needs to understand. Explain what the data supports and what still requires investigation.
The chart should show rate and volume; causal conclusions need more evidence than two totals.
Common pitfalls
Count as proportion; hidden population change; correlation as cause; average as the entire experience.
Related topics: Remove limitations and increase value · Plan analysis and decisions
Measure the defined benefit and retain comparison limitations.
Reference: CBAP Competencies and Proficiency Levels · CBAP six-knowledge-area blueprint, May 2026 handbook