The PFV Process
// Five steps, each with the tool that supports it
// On a phone these stack top to bottom in the same order
What Leaders Gain
// Diagnose the cause, then invest against it — outcomes, not deliverables
PFV Tools
// Two tools, one progression — analyze and diagnose, then quantify
Learn more
Learn more
Set thresholds → analyze your process → model the investment → estimate the cost of delay. Each tool feeds the next.
Advanced Settings — Exposure Thresholds
PFV Exposure Thresholds
// Define what constitutes meaningful exposure in your environment
How thresholds work
PFV Process Flow Worksheet
// Identify where waiting, handoffs, and rework are delaying outcomes
How to use this — step by step
Why is it waiting?
// Finding the biggest wait tells you where to look — not why. Classify the mechanism before choosing a remedy.
What the six mechanisms mean — reference
A long queue locates a delay; it does not prove a bottleneck. The same symptom — a big wait — can come from six different mechanisms, and each one needs a different fix. Hiring another approver does nothing for a queue that is really a weekly batch. Name the mechanism, confirm it against the timestamps your systems already record, then choose the remedy.
Capacity constraint
Demand persistently meets or exceeds what the step can complete.
Evidence: WIP piles up before the step; the resource stays highly utilized; the queue grows over time; downstream is starved.
Batching / schedule
Work is held for a meeting, review cycle, committee, or release window.
Evidence: items wait even when capacity is free; completions cluster around the schedule; queue time tracks arrival timing in the cycle.
Dependency / blocking
Work can’t proceed until another team, vendor, decision, or prerequisite arrives.
Evidence: blocked status, repeated follow-ups, external ownership of the next action; queue age tracks response time, not capacity.
WIP overload
Too many items active at once; multitasking and interruption age everything.
Evidence: high active-item count per person, many started & few finished, frequent expedites, aging WIP while new work keeps starting.
Rework loop
Work repeats because inputs were incomplete, defects surfaced, or approvals rejected it.
Evidence: items move backward, reopenings and resubmissions, duplicate effort, high rejection or clarification rate.
Policy / control
The wait is intentional: approval, sign-off, separation of duties, compliance step.
Evidence: the control owner can name its purpose; removing the wait changes a control objective. Not automatically waste — ask if the objective can be met in less elapsed time.
Never take a hypothesized cause upstairs as a proven one; more than one mechanism can be true at once. The first three levels are confidence in the cause; Improved is a different claim — evidence the remedy worked. The diagnostic below walks this step by step and labels which level you are standing on.
PFV Investment & Return Calculator
// Estimate recoverable capacity — and the cost of delay — before funding an initiative
The figures behind this tab combine your unverified estimates with industry-average cost models — COPQ multipliers, Reinertsen cost-of-delay, industry cost benchmarks. They are illustrative scenarios, not forecasts. They can rank which process to fix first; they cannot price a business case on their own. For investment-grade numbers, verify per-step times against your system-of-record timestamps (CRM, ERP, ticketing) first — the trust ladder shows what each level of confidence can support.
Never take a hypothesized cause upstairs as a proven one; more than one mechanism can be true at once. The first three levels are confidence in the cause; Improved is a different claim — evidence the remedy worked. The diagnostic labels which level you are standing on.
* All figures are estimates for strategic planning and budgetary purposes only. Cost-of-delay and rework figures derive from your own inputs and the assumptions you enter. Actual results depend on process complexity, team engagement, and implementation quality.
Continual Improvement Cycle
// Each turn of the cycle reduces exposure and recovers capacity
The cycle is not improvement for its own sake. Each turn drives the two outcomes a board cares about — exposure reduced while work waits, and capacity recovered from queues, rework, and unnecessary steps. The wheel is the method; exposure down and capacity back are the results.
MODEL
to explore the step
Full CSI details — the seven ITIL® 4 phases
What Is the Vision?
// Define Green first; measure second
VOC is not a survey. It is a structured conversation with real customers — internal or external — to discover what good actually means to them. In PFV terms: what processing time is acceptable? What queue time causes them to escalate? What defect rate makes them stop trusting the output? These answers become your Green thresholds. If the customer says "I need this resolved within 4 hours" — that is your Queue Time Green limit.
Customer Need → Quality Driver → Critical to Quality (CTQ) requirement → PFV threshold. Example: "Faster detection" → "Resolution time" → "MTTR ≤ 4 hours" → Queue Time Green = 4 hrs. This chain is what makes a threshold objective and non-negotiable.
Where Are We Now?
// Fill the PFV Worksheet with real numbers — not estimates
SIPOC (Suppliers, Inputs, Process, Outputs, Customers) takes 20 minutes and prevents the most common failure in process mapping: scope creep. Define the process boundaries before the session. Start and end points in SIPOC become the first and last tasks in your PFV Worksheet — the first task is what starts the process, the last is what ends it.
| Element | Question | PFV Connection |
|---|---|---|
| Suppliers | Who provides the inputs? | Upstream handoff sources → Performer dimension |
| Inputs | What triggers or feeds this process? | Trigger / Input dimension → Automated, Document, or Manual |
| Process | What are the high-level steps? | Your task columns in the PFV Worksheet |
| Outputs | What does this process produce? | Output dimension per task |
| Customers | Who receives and depends on this output? | VOC respondents for threshold setting |
Walk the process with the people who do the work. Ask: how long does this step actually take? How long does it sit waiting? How often does it come back with errors? These are your PFV metric inputs. VSM is not a documentation exercise — it is a data collection exercise. The map is the product. The numbers fill the worksheet.
World-class service processes: PCE > 30% · Typical: 5–15% · Below 5%: systemic failure
The PCE is calculated automatically — use the Investment & Return Calculator below.
Gemba means "the real place" in Japanese. Never map a process from a conference room. Go where the work happens. Watch one end-to-end cycle. Time it yourself. The numbers you collect in person will differ dramatically from the estimates on any existing documentation — and the real numbers are what matter.
Where Do We Want to Be?
// Future-state thresholds — what does all-Green look like?
Example: 480 min/day ÷ 120 requests/day = 4 minutes per request
If any step takes longer than Takt Time — it is Red by definition.
| Target | Current State (Red) | Future State (Green) | Value |
|---|---|---|---|
| Lead Time | Weeks | Days or Hours | Customer satisfaction · SLA adherence |
| PCE | <10% | >30% | 3× throughput without adding headcount |
| Defect Rate | >10% | <2% | Rework cost eliminated · COPQ reduced |
| Handoffs | 5+ | 1–2 | Faster delivery · Clearer accountability |
| Manual Triggers | Majority | None | Automation-ready · Consistent quality |
Once your current-state Process Flow Worksheet is complete, scroll to the Investment & Return Calculator. Enter your hourly rate, annual volume, and estimated improvement cost. The calculator computes your current annual cost, projected savings, ROI %, and payback period — the numbers your executive needs to approve the project.
How Do We Get There?
// Each Red routes to the right tool. No guessing.
| PFV Red Dimension | Waste Type | Primary Tool | When to Use It |
|---|---|---|---|
| Queue Time Red | Waiting · Inventory | Pull System · Automation · Empowerment | Work sitting idle >50% of lead time |
| Processing Time Red | Over-processing · Motion | Kaizen · Standard Work · Takt Time | Step exceeds Takt Time or VOC limit |
| Defect Rate Red | Defects · Rework | 5 Whys → Ishikawa → Poka-Yoke | Rework loop visible · Output rejected >10% |
| Handoffs Red | Transportation · Utilization | Cell Design · Cross-training · RACI reset | Same work passing through 4+ teams |
| Trigger / Input Red | Motion · Waiting | Workflow automation · API integration | Manual data entry or document hand-off |
| Dependencies Red | Waiting · Over-processing | KT Problem Analysis · Process redesign | 3+ hard dependencies blocking progress |
| Cost Red | All waste types compounded | COPQ analysis · Automate Green first | Cost > 2× benchmark for this step type |
You cannot improve what is not stable. 5S creates the predictable baseline from which every other tool works. In knowledge work and IT operations: Sort out unused tools and data sources, Set in order the workflows and access rights, Shine by cleaning up queues and backlogs, Standardize the process into documented procedures, Sustain through audits and PFV re-measurement.
After a 5S event, re-run the PFV Worksheet. Processing Time and Queue Time Reds typically drop 20–40% from standardization alone — before any deeper improvement is applied. This is the fastest path to Green for chaotic, undocumented processes.
KT's Problem Analysis asks four precise questions about any Red: What exactly is the problem? Where and when does it occur vs. not occur? What is distinctive about where it does occur? What changed? This distinction analysis cuts through opinion and surfaces the actual cause — preventing the most expensive error in improvement work: solving the wrong problem with the right tool.
For straightforward Reds where the symptom is clear, five iterations of "why" reliably reaches the root cause. The key discipline: each answer must be falsifiable — you should be able to verify it with PFV data. Stop when the answer points to a systemic cause you can fix, not a person you can blame.
Use 5 Whys when the Red is recent, the symptom is specific, and the team agrees on what they observed. Use KT when the Red is persistent, the team disagrees on causes, or previous fixes did not hold. When in doubt: KT.
Write the specific Red PFV metric at the fish head. Draw six bones: Methods, Machines, Materials, People, Environment, Measurement. Brainstorm causes per category. The categories prevent the team from fixating on the obvious and missing the systemic. Validate top candidates with your PFV metric data history before committing to a fix.
Most PFV Reds map to one of eight waste types. The heat map shows where. The 8 Wastes name what type. Naming it precisely determines the countermeasure.
| Waste | PFV Signal | Modern Countermeasure |
|---|---|---|
| Waiting | Queue Time Red — most common | Pull systems · Automated approvals · SOAR triggers |
| Over-processing | Processing Time Red | Standard work · Takt time · AI-assisted triage |
| Defects | Defect Rate Red | Poka-Yoke · Input validation · ML anomaly detection |
| Transportation | Handoffs Red | Cross-functional teams · Single-queue models |
| Motion | Trigger Red · Processing Time Red | Workflow automation · Context-aware tooling |
| Inventory | Queue Time Red — backlogs | WIP limits · Kanban · Queue-time SLAs |
| Over-production | Processing Time Red (hidden) | Pull not push · On-demand generation |
| Underutilization | Handoffs Red · Performer | Skill-mapping · Automation of L1 tasks |
Before implementing any fix to a Red zone, ask: what could this fix break? FMEA scores each failure mode by Severity × Occurrence × Detection = RPN. Fix high-RPN items first. This prevents the most common implementation failure: trading one Red for three new ones.
RPN > 200: block implementation until mitigated
After fix: re-score and confirm PFV metrics moved Green
Take Action & Validate
// PFV metrics confirm the fix. No politics.
ITIL 4 distinguishes KPIs (operational performance) from KVIs (value delivered to customers and the business). Always report both. Reducing queue time from 10 days to 2 days is a KPI. Delivering 5× more throughput with the same headcount is the KVI. Executives fund KVIs.
Maintain Momentum
// Improvement that stops becomes expensive documentation
| Cadence | Activity | PFV Action |
|---|---|---|
| Day 30 | Early validation check | Spot-check the fixed Red metrics · Confirm trend is Green |
| Day 90 | Full PFV re-run | Re-fill the worksheet · New heat map · New routing decisions |
| Day 90 | Threshold review | Tighten Green limits where stable · Yellow becomes new Red |
| Quarterly | CIR business review | Present KVI progress · Cost savings realized · Next cycle approved |
| Annually | Strategic alignment | Map PFV results to organizational OKRs · Expand to adjacent processes |
Green steps that have been stable for two consecutive 90-day cycles are automation candidates. Use this sequence: Standard Work documented → Manual process reliable and Green → Automate → Re-run PFV to confirm automation did not create new Reds. It is a defensible sequence for durable automation — with PFV as the gate at each stage.
Search This Site
Jump to any tool, framework step, or method — runs entirely in your browser.
The worksheet runs entirely in your browser. Calculations never touch a server. Nothing you type is transmitted unless you click Save, Load, or cloud Export — and those requests go only to this same origin (pfv-csi.dewood.org). No third-party analytics, ad, or tracking scripts load on this site.
- ✓ CSP script-src 'self' — no inline JS, no eval, no CDN code
- ✓ Every script self-hosted; spreadsheet lib pinned with an SRI sha384 hash
- ✓ HSTS preload · X-Frame-Options DENY · nosniff
- ✓ object-src 'none' · frame-ancestors 'none' · base-uri 'self'