Quantitative Management

Purpose & Context

Implements CMMI MA (Measurement & Analysis), QPM (Quantitative Project Management), and OPP (Organizational Process Performance) through data-driven decision making, statistical process control, and predictive analytics.

Core Principle: Measure what matters, use data to drive decisions, distinguish signal from noise.

Avoid: Measurement theater (tracking without action), vanity metrics (looks good but no value), gaming metrics (optimizing numbers vs processes).

When to Use This Skill

Triggers:

"What should we measure?"
"How do I know if this variation is a problem?"
"How do I establish process baselines?"
"What's the difference between Level 2, 3, and 4 measurement?"
"How do I use DORA metrics?"
"How do I implement statistical process control?"
"How do I use metrics for project decisions?"

Use this when:

Establishing a measurement program
Moving from Level 2 → 3 → 4
Implementing DORA metrics
Analyzing process performance
Detecting process instability
Predicting project outcomes
Making data-driven decisions

Do NOT use for:

Platform-specific metric collection → See platform-integration skill
One-time reporting → Just write the report
Metrics mandated by compliance → See governance-and-risk skill

Quick Reference: Finding What You Need

| You Want To... | Reference Sheet | Key Content | |----------------|-----------------|-------------| | Plan what to measure | measurement-planning.md | GQM methodology, cost/value analysis, anti-patterns | | Choose metrics | key-metrics-by-domain.md | Quality, velocity, stability, deployment metrics | | Implement DORA | dora-metrics.md | 4 DORA metrics, collection automation, baselines | | Analyze variation | statistical-analysis.md | Control charts, SPC, trend detection | | Establish baselines | process-baselines.md | Historical data analysis, baseline maintenance | | Make data-driven decisions | quantitative-management.md | QPM, prediction models, Level 4 practices | | Scale L2→L3→L4 | level-scaling.md | Maturity progression, requirements by level |

Maturity Level Guidance

Level 2 (Managed): Basic Tracking

Focus: Capture data for visibility

Measurements:

Counts (defects found, tests run, deployments)
Dates (when tasks completed, releases shipped)
Simple averages (average lead time, average velocity)

Tools: Spreadsheets, basic dashboards, manual collection acceptable

Example: Track number of bugs found per sprint, average time to close bugs

Limitation: No statistical analysis, no baselines, reactive only

Level 3 (Defined): Organizational Baselines & Trends

Focus: Establish norms, detect trends

Measurements:

Organizational baselines (typical velocity, typical defect density)
Trend analysis (improving or degrading?)
Comparative analysis (this project vs org average)

Tools: Analytics platforms, automated collection, historical databases

Example: Know that your organization typically delivers 30 story points/sprint ± 10, and current project is trending 25 (slightly below average)

Advancement over L2: Baselines provide context, trends show direction

Level 4 (Quantitatively Managed): Statistical Process Control

Focus: Predict outcomes, control variation

Measurements:

Statistical process control (control charts, control limits)
Prediction models (effort estimation, defect prediction)
Process performance objectives (quantitative targets)
Variance analysis (special cause vs common cause)

Tools: Statistical packages (R, Python), control chart software, Monte Carlo simulation

Example: Use control charts to detect when defect rate exceeds upper control limit (special cause), trigger root cause analysis. Use regression model to predict project completion date with 90% confidence interval.

Advancement over L3: Predictive, not just reactive; distinguishes noise from signal

Measurement Anti-Patterns

| Anti-Pattern | Symptom | Better Approach | |--------------|---------|-----------------| | Measurement Theater | Tracking many metrics, no action taken | Use GQM to link metrics to decisions | | Vanity Metrics | Numbers look impressive but don't drive improvement | Focus on actionable metrics with clear business value | | Gaming Metrics | Teams optimize numbers instead of processes | Measure outcomes, not activities; use multiple metrics | | Lagging-Only | Only measure results after the fact | Balance lagging with leading indicators | | Analysis Paralysis | Too many metrics, can't make decisions | Focus on critical few (3-5 key metrics) | | Flying Blind | No metrics, decisions based on opinion | Start with Level 2 basics, build up | | Over-Precision | Measuring to 3 decimal places when ±20% is noise | Match precision to decision granularity |

Integration with Other CMMI Process Areas

REQM (Requirements Management):

Metric: Requirements volatility (changes per sprint)
Metric: Requirements traceability coverage (% with tests)
Use baseline to detect abnormal churn

CM (Configuration Management):

Metric: Branch protection compliance
Metric: Baseline stability (changes after freeze)
Use SPC to detect configuration drift

VER/VAL (Verification/Validation):

Metric: Test coverage, defect density, escape rate
Metric: Code review effectiveness
Use control charts for quality gates

RSKM (Risk Management):

Metric: Risk exposure (probability × impact)
Metric: Risk burndown (risks closed over time)
Use trends to predict risk realization

DAR (Decision Analysis & Resolution):

Use measurement data as input to DAR
Track decision quality (outcomes vs predictions)

Cross-references:

requirements-lifecycle - Metrics for requirement quality
design-and-build - Metrics for development process
governance-and-risk - Risk and compliance metrics
platform-integration - Metric collection automation

Getting Started (Quick Start Scenarios)

Scenario 1: First-Time Measurement Program (Level 2)

Goal: Start tracking basic metrics for visibility

Read ./measurement-planning.md - Learn GQM methodology
Pick 3-5 metrics using GQM (don't start with 20+)
Set up manual or automated collection
Track for 4-8 weeks (establish baseline data)
Review monthly, adjust what you track

Example metrics for first program:

Deployment frequency (how often we ship)
Lead time for changes (commit to production)
Defect escape rate (bugs found in production)

Scenario 2: Implementing DORA Metrics (Level 2→3)

Goal: Industry-standard DevOps metrics

Read ./dora-metrics.md - Understand the 4 metrics
Read ./measurement-planning.md - Ensure DORA aligns with goals
Automate collection (see platform-integration skill for GitHub/Azure DevOps)
Establish baselines (4 weeks minimum)
Set quarterly improvement goals
Review weekly/monthly

Scenario 3: Statistical Process Control (Level 3→4)

Goal: Detect process instability automatically

Read ./statistical-analysis.md - Learn control charts
Establish process baselines (Level 3 requirement)
Calculate control limits (mean ± 2-3 standard deviations)
Plot data on control charts
Investigate points outside control limits (special cause)
Update baselines quarterly

Example: Defect escape rate control chart with UCL=15%, LCL=2%, current value 18% → investigate

Scenario 4: Data-Driven Project Management (Level 4)

Goal: Use quantitative data for project decisions

Read ./quantitative-management.md - Learn QPM practices
Read ./process-baselines.md - Understand baseline usage
Set process performance objectives (e.g., defect density < X)
Use prediction models for estimates (see statistical-analysis.md)
Monitor against objectives using SPC
Adjust process when out of control

Common Questions

Q: How many metrics should I track? A: Level 2: 3-5 basic metrics. Level 3: 5-10 organizational baselines. Level 4: 3-5 with statistical control. Focus beats breadth.

Q: How long to establish a baseline? A: Minimum 4 weeks for initial baseline. Prefer 12 weeks (1 quarter) for statistical validity. Update quarterly or when process changes.

Q: What's the difference between MA and QPM? A: MA (Level 2+): Measurement & Analysis - defining, collecting, analyzing metrics. QPM (Level 4): Using statistical process control and prediction models to manage projects quantitatively.

Q: Do I need Level 3 before Level 4? A: Yes. Level 4 requires organizational baselines (Level 3). Can't do statistical process control without knowing what "normal" looks like.

Q: Leading vs lagging indicators - what's the difference? A: Lagging: Measure results after the fact (defects found, deployment time). Leading: Predict future outcomes (code review coverage, test coverage). You need both. See ./key-metrics-by-domain.md for examples.

Q: How do I avoid measurement theater? A: Use GQM methodology (see ./measurement-planning.md). Every metric must answer a question that drives a decision. If you can't explain the decision, don't track the metric.

Q: When should I use control charts? A: When you have 20+ data points and want to distinguish normal variation from abnormal (special cause). See ./statistical-analysis.md for guidance.

Reference Sheets

measurement-planning.md - GQM methodology, cost/value analysis, measurement repository design
key-metrics-by-domain.md - Quality, velocity, stability, deployment metrics with selection guidance
dora-metrics.md - Deployment Frequency, Lead Time, CFR, MTTR implementation
statistical-analysis.md - Control charts, trend detection, confidence intervals, SPC
process-baselines.md - Baseline establishment, maintenance, usage for estimation
quantitative-management.md - QPM practices, prediction models, process performance objectives
level-scaling.md - Level 2→3→4 progression with concrete requirements

Related Practices

../requirements-lifecycle/SKILL.md - Requirements management metrics
../design-and-build/SKILL.md - Development process metrics
../governance-and-risk/SKILL.md - Risk and compliance metrics
../platform-integration/SKILL.md - Metric collection automation in GitHub/Azure DevOps

Last Updated: 2026-01-25