Lead time: the clock your stakeholders actually feel
A stakeholder doesn’t experience “procurement policy.” They experience waiting. Lead time is the total elapsed time from a triggering event (a requisition, a stockout signal, a project need) to the moment the item or service is available for use. If the team can’t start work because the laptop hasn’t arrived or the contractor can’t begin because onboarding isn’t complete, that’s lead time in the only sense that matters.
Procurement teams often talk about cycle time (how long procurement spends actively processing something) and forget the dead time between handoffs. Lead time includes those pauses: approvals sitting in inboxes, clarification loops, supplier quoting delays, and “we’ll raise the PO once finance opens the period.” Those gaps are usually where the biggest reductions are hiding.
Lead time vs cycle time (and why arguing about definitions wastes time)
Cycle time is how long work takes when it’s being worked on. Lead time is cycle time plus waiting. Procurement teams sometimes optimize what they can see—PO creation, sourcing events, contract edits—while the real delay is waiting for budget holders, legal review queues, or suppliers who respond in 72 hours because they can.
A practical way to keep it simple: if you want to improve stakeholder experience, measure lead time. If you want to improve internal efficiency, measure cycle time too. Both are useful, but lead time is the metric that exposes bottlenecks across the whole system, not just inside procurement.
Where lead time starts and ends (pick boundaries you can defend)
Lead time definitions fall apart when different teams pick different start points. One team starts the clock when the requisition is submitted; another starts when procurement accepts it; a third starts when the budget is approved. If you’re trying to reduce lead time, agree on boundaries that match the stakeholder’s reality.
Common start points: request created, request submitted, request approved, procurement triage accepted
Common end points: PO issued, supplier confirmed, goods received, service start date, asset ready-to-use (configured laptop, system access granted)
Tip: define two lead times when needed—“procurement lead time” (submission to PO) and “end-to-end lead time” (submission to ready-to-use). The second is what the business cares about.
How to measure lead time without a six-month analytics project
Start with a small set of high-volume or high-pain categories: laptops, contingent labor, marketing agencies, MRO spares, freight, software renewals. Pull timestamps from whatever system is the system of record (ERP, e-procurement, ticketing, contract repository). If you don’t have clean timestamps, sample manually for two weeks and build a baseline from real cases.
Don’t average everything into one number. Use percentiles. The median shows typical experience; the 90th percentile shows the “why is this still not done?” cases that create escalations. A process that looks fine on average can still be miserable at the tail.
Track: median lead time and 90th percentile lead time per category
Segment: new supplier vs existing supplier, contract in place vs not, standard spec vs custom spec
Add one qualitative field: “reason for delay” (choose from a short list). This is where the fixes come from.
The usual suspects: where procurement lead time actually gets stuck
Most lead time isn’t “slow buyers.” It’s queues and rework. Rework is especially brutal because it resets the clock: missing specs trigger clarification loops; incorrect coding triggers finance rejection; a supplier can’t accept your PO terms so legal gets pulled in late.
Unclear demand: vague requirements, changing scope, no delivery date discipline
Approval latency: budget holders, project owners, IT/security, legal, finance period controls
Supplier responsiveness: slow quotes, limited capacity, long manufacturing or shipping times
Contract friction: starting negotiations after the supplier is “selected,” redlines bouncing for weeks
Internal handoffs: sourcing to contracting to ordering to receiving, each with its own queue
Receiving and “ready-to-use” delays: goods arrive but aren’t receipted, assets not configured, access not provisioned
How to reduce lead time (without just skipping controls)
Cutting lead time is not the same as “pushing people harder.” The cleanest reductions come from removing avoidable waiting and preventing rework. The temptation is to bypass controls under pressure; that usually buys a short-term win and a long-term audit headache. Better is to design fast paths for low-risk work and reserve heavy process for genuinely risky spend.
1) Make intake brutally specific
A requisition that says “consultant—urgent” is a guaranteed delay. If you want speed, force clarity upfront. Provide category-specific request forms (not one generic form) with the minimum fields needed to avoid back-and-forth: scope, deliverables, location, start date, rate model, required certifications, and who will sign off.
Use templates: statements of work, laptop bundles, standard service packages
Add guardrails: required fields, drop-downs for common specs, examples of “good” requests
Reject early: a 10-minute triage rejection beats a two-week procurement loop
2) Pre-approve the boring stuff
If you need three approvals to buy a standard monitor, your lead time problem is self-inflicted. Build catalogs, frameworks, and rate cards for repeat buys. Then set approval thresholds that reflect risk, not tradition.
Catalogs for standard items and bundles with contracted pricing
Framework agreements for common services (design, translation, temp labor) with pre-negotiated terms
Auto-approval rules for low-value, low-risk items; tighter controls for exceptions
3) Pull contracting earlier—or don’t start at all without a path
A common mistake: running a sourcing event, selecting a supplier, then discovering the supplier won’t accept your terms. That’s a lead time bomb. For anything non-trivial, validate contractual deal-breakers early (data protection, liability caps, payment terms, subcontracting, IP).
Also: stop negotiating from scratch when you don’t need to. Standard paper isn’t glamorous, but it’s fast. If legal hates your templates, fix the templates rather than fighting the same battles every month.
4) Design a “fast lane” with explicit risk criteria
Fast lanes work when they’re earned, not when they’re begged for. Define what qualifies: existing supplier, contract in place, standard scope, no personal data, low value, no new jurisdictions. Then publish the rules so stakeholders stop escalating everything as “urgent.”
Fast lane example: “existing supplier + contracted terms + under X value + standard scope = target PO in 48 hours”
Slow lane example: “new supplier + personal data + custom scope = security review + DPIA + legal negotiation”
Make exceptions visible: if a request uses the fast lane but fails criteria, route it back without debate
5) Work with suppliers on their lead time, not just your own
Procurement teams sometimes treat supplier lead time as a fixed constant. It isn’t. You can negotiate quote turnaround SLAs, reserve capacity, agree forecast sharing, hold buffer stock, or set up vendor-managed inventory for spares. For services, you can pre-qualify bench resources and standardize onboarding so the supplier can start faster.
Trade-off: suppliers will often charge for responsiveness (priority production, expedited shipping, dedicated resources). Decide where speed is worth paying for, and where it’s better to plan earlier.
6) Kill hidden queues with WIP limits and ownership
Lead time inflates when everyone starts too much work and finishes too little. If your buyers each have 40 open files, nothing moves quickly. Set work-in-progress limits and define who owns the next action at every step. A request with no clear owner is a request that will age.
Use a visible board (even a simple queue view) showing stage, age, and next owner
Set SLA targets per stage (triage, sourcing, contracting, ordering) and review breaches weekly
Escalate based on age and impact, not the loudest stakeholder
Common reductions that backfire
Some “lead time improvements” just move pain elsewhere. Dropping competitive bids can speed up a purchase and quietly increase cost. Skipping due diligence can create supplier failure later. Over-automating intake can frustrate users and push spend off-system. The goal is shorter lead time with acceptable risk, not speed at any price.
Removing approvals without changing thresholds or risk rules (audit issues later)
Forcing one-size-fits-all workflows across categories (people work around it)
Measuring only average lead time (tail cases keep causing escalations)
Treating “urgent” as a category instead of fixing planning and intake
A practical 30-day plan for procurement teams
If you want measurable improvement quickly, don’t try to redesign Source-to-Pay end-to-end. Pick one category with visible pain, map the real steps, and remove one major queue and one major rework loop. That’s usually enough to show progress and earn support for bigger changes.
Week 1: define start/end points, pull 20 recent cases, calculate median and 90th percentile lead time
Week 2: categorize delays (approvals, specs, supplier response, contract), pick the top two causes
Week 3: implement one intake fix (template/required fields) and one flow fix (fast lane, WIP limit, SLA per stage)
Week 4: re-measure on new cases, publish results, and lock in the new rules (not just a one-off push)