Twenty-two places this
method has earned its keep
PFV makes the flow of work visible, measures where time and resources actually go, and determines the consequence — so an organisation can decide what is worth changing or investing in. This is a non-exhaustive list of applications where it has been used successfully.
Before you buy more people, technology, or services — do you know how effectively your existing resources are being converted into outcomes?
PFV shows where an investment would actually improve capacity, flow, throughput or exposure — and where it would not.
| Application | The question PFV answers | Consequence of waiting |
|---|---|---|
| Resource optimization | Are we getting what we reasonably can from the people and technology we already have? | Lost capacity / throughput |
| Disaster recovery | Can we execute recovery within the specified RTO, and is the recovery process consistent with the specified RPO? | Longer outage / missed recovery objective |
| Project planning & execution | What actually determines the completion date? | Schedule delay |
| Vulnerability remediation | Why does a known vulnerability remain open this long? | Extended cyber exposure |
| Incident response | What delays containment and resolution? | Extended incident impact |
| Change management | Why does a change take this long from request to production? | Delayed business value |
| IAM / access provisioning | What delays granting, changing, or removing access? | Productivity loss / security exposure |
| Customer / service provisioning | What delays delivery of the service? | Delayed revenue / customer value |
| Technology deployment | Why isn’t purchased technology reaching productive use faster? | Delayed return on investment |
| First-of-a-kind technology implementation | What will it really take to get this new technology into productive use? | Delayed deployment, unforeseen dependencies, rework, delayed time-to-value |
| Problem management | Why do recurring problems remain unresolved? | Continuing operational impact |
| Service desk / escalation | Where does resolution stall between support levels? | User downtime / poor experience |
| Compliance remediation | Why do audit findings remain open? | Extended compliance exposure |
| Vendor management | Where are external dependencies controlling outcomes? | Schedule / operational delay |
| Procurement | What delays request through purchase and availability? | Delayed capability |
| Software delivery / DevSecOps | What prevents code or capability from reaching production faster? | Slower value delivery |
| Security exceptions | Why do exceptions remain unresolved? | Extended accepted risk |
| Cloud migration | What controls migration velocity? | Delayed benefits / overlapping costs |
| M&A integration | What prevents systems and processes from being integrated faster? | Delayed synergy / value |
| Sales-to-delivery | What happens between selling something and delivering the outcome? | Revenue / customer delay |
| Contact-center operations / AI bots | Can we deploy AI bots fast enough, and are they improving contact-center flow? | Customer wait / capacity loss / delayed AI value |
| Splunk detection engineering | Can we move high-fidelity detections from development to response fast enough? | Security exposure |
The measurement principle
The method does not change between these. Separate hands-on work from waiting, identify dependencies and approvals, identify rework and handoffs, determine what can genuinely run in parallel, and establish where elapsed time actually sits.
The measurement stays the same. The consequence of time changes. Depending on the application that consequence may be capacity, throughput, a completion date, recovery time, cyber exposure, customer experience, revenue, or the return on a technology investment.
AI value realisation
AI is not a separate application. It is a technology investment that can affect nearly any process on this page — which means it should be measured the same way as any other investment.
PFV measures AI by the outcome it changes, not by the activity the AI performs.
A bot handling thousands of interactions, a copilot generating code, or an engine triaging alerts all demonstrate activity. The question is what changed end to end.
| Stage | What to do |
|---|---|
| Before | Establish the process baseline and identify where AI could realistically reduce work, waiting, rework, handoffs, constraints, or exposure. |
| After | Measure the process again. Determine whether AI returned capacity, improved flow or throughput, reduced exposure or rework, accelerated recovery or completion — or simply moved work and queues elsewhere. |
| Both | Compare the measured baseline against the resulting process, and decide whether the investment produced measurable operational and business value. |
That last possibility is the one worth guarding against. Work that moves is not work that disappeared, and a queue that relocates has not been removed. The only way to tell the difference is to have measured before.