How I work · A sample engagement

Ninety-eight days. Thirteen of them were work.

A regional hospital network signs with Fauxmed Supply Co. to outfit its clinics with new infusion pumps. Fauxmed has the suppliers. The suppliers have the stock. Everyone agrees on the plan.

Ninety-eight business days later, the contract finally closes.

Nobody was idle. Legal was busy. Finance was busy. Procurement was busy. But trace the program day by day, and someone was actively moving it forward on only thirteen of those days. On the other eighty-five, it sat waiting: in an inbox, in an approval queue, on a third round of redlines.

A day someone worked on itA day it waited

That gap has nothing to do with effort. It lives in the pipeline, which means it can be measured, explained, and fixed.

Here is how I would do it, step by step, using the same Lean Six Sigma method I bring to real operations: define the problem, measure the baseline, find the root cause, redesign the flow, and build the controls that keep it fixed.

Fauxmed Supply Co. is fictional. The method is real. All figures are sample data.

Define · Choosing the project

Four problems worth fixing. One goes first.

A quick walk of Fauxmed's full pipeline turned up four pain points. Fixing all of them at once is how improvement efforts stall, so I scored them against what the business values most and let the numbers pick the starting point.

What this shows

How I decide where improvement effort goes: weighted criteria, a scored shortlist, and a stress test to make sure the choice holds when leaders weigh things differently.

The criteria, weighted before anything was scored

Each weight says how much Fauxmed cares about that criterion: 5 matters most, 1 least. Each project is then rated 1 to 10 on how well it delivers on each one.

weight ×5Customer impactHow directly the customer feels the improvement.
weight ×3StrategyHow well it supports what leadership is already pursuing.
weight ×3Cost of poor qualityMoney lost today to rework, errors, and disputes.
weight ×3Improvement potentialThe gap between how the process performs and how well it could.
weight ×1Ease of executionHow simple the project is to run. Weighted low so easy, low-value fixes don't win by default.

Candidate project	Customer×5	Strategy×3	Cost of poor quality×3	Improvement potential×3	Ease×1	Score
Negotiation and approvalsDeliveryFirst project	9	8	6	9	5	119
Acceptance and invoice disputesQuality · CostNext project	6	6	8	7	7	100
Sourcing cycle timeDelivery	6	5	3	5	6	75
Closeout delaysDelivery · Cost	3	4	5	6	8	68

How a score is built, using the winner: (9×5) + (8×3) + (6×3) + (9×3) + (5×1) = 119 out of a possible 150.

Stress test: does the choice survive a different point of view?

Weights are a judgment call, so I re-ran the matrix the way two different leaders might weigh it.

An operations lead who values ease

Ease of execution raised from ×1 to ×3.

129 vs 114

Same winner

A CFO who values cost

Cost of poor quality raised from ×3 to ×5. The disputes project closes ground, since cost is its strength.

131 vs 116 · lead narrows from 19 to 15

Same winner

How I got there

Pulled candidates from a walk of the whole pipeline, and tagged each by the kind of pain it causes: quality, delivery, or cost. The detailed baseline comes later, in Measure.
Set the weights before rating anything, so the criteria could not be tuned to favor a project I already liked.
Rated each project with a reason for every number. Negotiation and approvals is the hardest to run, but it scores highest where the business cares most.
Stress-tested the weights against how an operations lead and a CFO would see it. The winner held both times.
Turned the ranking into a sequence. Disputes is the biggest cost leak, so it is chartered next. Closeout ranks last partly because its delays come from those disputes, so fixing disputes should shrink it too.

Define · Project charter

One page that says what we will fix, by when, and what we will not touch.

The charter is the agreement between the project and its sponsor. Its most useful line is often the one under "out of scope," because it is how a team says no to "while you're at it" without a political fight.

What this shows

How I turn a chosen problem into a project with a measurable goal, guardrails against shortcuts, firm boundaries, and named owners.

FX-CI-001 · Continuous improvement charter

Subcontract cycle time: supplier cleared to PO issued

Approved by sponsor

Problem statement

From supplier clearance to PO issued, Fauxmed subcontracts take an average of 32 business days. Only about 3 of those days involve active work, and each subcontract goes through an average of 3.4 redline passes.

Business case

Every day in this segment delays supplier kickoff. Over the last ten customer programs, four missed the customer's first delivery date, and in each one this segment was the longest wait before kickoff. Faster subcontracting protects delivery commitments to customers like the hospital network, and the relationships that renew them.

Goal

Cut average cycle time from 32 to 18 business days, and redline passes from 3.4 to 2.0 or fewer, within six months of charter approval.

Metrics

Metric	Role	Baseline	Target
Cycle time, cleared to PO issued	Primary	32 days	18 days
Redline passes per subcontract	Secondary	3.4	2.0 or fewer
Contract modifications within 90 days of execution	Guardrail	12%	No increase
Supplier claims on contract terms	Guardrail	6%	No increase

In scope

Drafting, redline review, and final terms
Routing and queues for tiered approvals
The handoff from Legal to Finance
Timestamping each step for measurement

Out of scope

Approval dollar thresholds and authority levels, which are policy
Supplier selection and sourcing
Kickoff, delivery, and acceptance
Supplier-side review time: tracked, but not controlled

Team

SponsorVP of Operations
Process ownerDirector of Contracts
Green Belt leadMe
Core teamLegal, Finance approvals, Procurement
As neededIT, for timestamp automation

Constraints and risks

Baseline dates come from email, so the first measure is approximate
Supplier response time is outside Fauxmed's control
Legal has limited capacity for project work

Timeline · 24 weeks

Define 2 wk

Measure 4 wk

Analyze 4 wk

Improve 8 wk

Control 6 wk

SIPOC: the boundaries, and who needs to be in the room

Suppliers, inputs, process, outputs, customers. The middle column is the process at a high level. Everything around it tells me whose work feeds in and whose work depends on the result.

SSuppliers

Procurement
Legal
Finance approvers
The supplier
Program ops

IInputs

Cleared supplier package
Flow-down matrix
Statement of work and LOE baseline
Clause library and templates
Approved budget

PProcess

starts: supplier cleared

Draft the subcontract
Send to the supplier
Review and resolve redlines
Agree final terms and execute
Route for tiered approval
Issue the PO

ends: PO issued

OOutputs

Executed subcontract
Approved PO
Approval record with timestamps

CCustomers

Program opsneeds the PO to start kickoff
The supplierneeds it to start work
Accounts payablepays against the PO
The end customerfeels every day of delay

How I got there

Wrote the problem without a cause or a fix in it. Naming a cause this early skips the analysis and points blame before the data does.
Set one primary goal with a baseline, a target, and a deadline, so success is a number, not an opinion.
Added two guardrails. A team can get fast by cutting corners, so contract modifications and supplier claims must not rise while cycle time falls.
Kept approval thresholds out of scope. Changing who can approve what is a policy decision. This project fixes how fast approvals move, which is within the team's authority.
Used the SIPOC to staff the project. Every supplier and customer of the process needs a voice, which is why Legal, Finance, and Procurement are core team members, not just interviewees.

Tollgate · sponsor review

Is the problem measurable, scoped, and staffed?The charter was signed with a numeric goal, two guardrails, firm boundaries, and named owners.

Passed

Measure · Current state

Before changing anything, I map how the work really moves.

Fauxmed wins customer contracts, then subcontracts suppliers to deliver them. This is its pipeline today, from proposal pricing to contract closeout, across five departments and two outside parties.

What this shows

How I baseline a cross-functional pipeline: where the time goes, who owns each stage, and how far the data can be trusted.

The pipeline, stage by stage

Lead time is elapsed business days. Work is the time someone actively spent on it. Each stage lists where its dates came from, because no single system tracked the whole flow.

01
Scope and LOE
Program ops + pricing
lead7dwork2d
pricing workbook
02
Customer award
Contracts
lead6dwork1.5d
signed PDF date
03
Flow-down plan
Contracts
lead5dwork1d
email approval
04
Sourcing
Procurement
lead12dwork2d
shared tracker
05
Negotiation
Legal + procurement
lead21dwork2.5d
Avg 3.4 redline passes
email threads
06
Approvals and PO
Finance approval tiers
lead11dwork0.5d
ERP PO date
07
Kickoff
Ops + supplier
lead9dwork1.5d
meeting invite
08
Invoice and pay
Accounts payable
lead8dwork0.5d
18% of invoices disputed
AP system
09
Closeout
Contracts + finance
lead19dwork1.5d
paper checklist

Where the 98 days go

Each bar is one stage's lead time. The bright segment is the work. Everything else is waiting in a queue or on the customer or supplier. Overall, the pipeline is 13% efficient.

The project segment, one subcontract at a time

To check the 32-day figure, I measured the last 25 subcontracts from the "supplier cleared" stamp to "PO issued," counting business days only. Each dot is one subcontract.

25Subcontracts sampled

32 daysAverage

27 daysMedian

16 to 74Fastest to slowest

median 27average 324 over 45 days

01020304050607080

Business days, supplier cleared to PO issued

Half of these subcontracts finish in 27 days or less. Four slow ones, all over 45 days, pull the average up to 32. That tail is the first lead for Analyze: what do those four have in common?

View the sample as a table

Subcontract	Total days	Negotiation	Approvals	Redline passes	Value tier
Average	32	21	11	3.4

How I got there

Mapped every stage and its owner, from proposal pricing to closeout, before looking at any numbers.
Rebuilt each stage's dates from wherever they actually lived, and recorded the source. Email threads and a paper checklist are the honest limit of this baseline, and I say so up front.
Separated elapsed time from hands-on work. Only 13 of 98 days involve anyone actively working. The rest is waiting.
Checked the project segment against real cases. I measured 25 recent subcontracts stamp to stamp and reported the median beside the average, because a few slow ones skew it.
Picked the biggest controllable wait. Negotiation and Approvals sit back to back and hold the most internal queue time, so one project can fix both and the handoff between them.
Logged what I found outside the project's scope. Invoices are paid without formal acceptance, which shows up later as disputes and a long closeout. That becomes its own recommended project instead of scope creep in this one.

Tollgate · sponsor review

Is the baseline trustworthy enough to analyze?Email-sourced dates are approximate, so each sampled subcontract's end date was checked against its ERP PO date before moving on.

Passed

Analyze · Root cause

Two causes, and they multiply each other.

Before fixing anything, I needed to know why work stalls, and whether the answer is more people or a better process. The data pointed to the process, and to two specific causes.

What this shows

How I move from a pattern in the data to a confirmed root cause: rule out staffing first, follow the outliers, count the causes, and ask why until the answer is something we can actually change.

First question: is this a people problem or a process problem?

If work arrives faster than the team can finish it, the queue grows no matter how good the process is, and the answer is staffing. So I checked capacity before anything else.

Workload against workforce, role by role

Role	Available	Arriving	Utilization
Procurement2 people × 55% × 20 days	22	14	64%
Legal2 people × 45% × 20 days	18	14	78%
Contracts admin1 person × 50% × 20 days	10	7	70%
Finance approvers5 people × 10% × 20 days	10	7	70%
Total	60	42	70%

Person-days per month. Work arriving is 14 subcontracts × each role's share of the 3 days of hands-on work: Procurement and Legal 1 day each, Contracts admin and Finance half a day each.

Little's Law: work in progress = throughput × lead time
0.67 per business day × 32 days ≈ 21 in progress at once

Verdict

The team has room. Work is waiting on routing, not on people.

No role is overloaded. Legal is the tightest at 78%. That does not indicate a clear capacity constraint in this sample, particularly given that the observed delays are concentrated in routing and repeated review cycles. About 21 subcontracts sit in progress at any moment, yet each needs only 3 days of work, so hiring would add capacity the process cannot use.

Following the slow ones

The baseline sample's long tail was mostly contracts over $250K. Compared with the rest of the sample, they spend far longer in both stages and go through more rounds of redlines.

Days in negotiation

32.5vs 17.4 for the rest

1.9× longer

Redline rounds

4.7vs 3.0 for the rest

1.6× more

Days in approvals

17.7vs 8.9 for the rest

2.0× longer

Size alone is not the cause. One mid-size subcontract, FX-SC-2325, also ran 47 days, and it had 5 redline rounds. Rounds are closer to the mechanism. Big contracts simply draw more of them.

Which clauses suppliers push back on

212 redlined clauses across the 25 sampled subcontracts, sorted by clause type. Four clause types account for 80% of all pushback.

Liability caps5827%

Flow-downs4951%

Insurance3768%

Indemnity2680%

80% line

Payment terms1587%

IP and data1193%

Termination896%

Other8100%

Tagged from the redline versions of the 25 sampled subcontracts, using a category list fixed before tagging began.

All four are risk-allocation terms whose right answer changes with contract size. A liability cap or insurance minimum that suits a $15K purchase is wrong for a $500K subcontract, and every subcontract starts from the same template.

Why each round costs so much

Fauxmed requires every approver to re-review any change, and Legal has no pre-approved fallback positions. So each redline round restarts both Legal and the full approval chain. Part of Negotiation's 21 days is really approvers' queue time.

Sign-off cycles per subcontract

sign-off cycles = redline rounds × approval tiers

Under $25K, one tier: 2.6
Over $250K, three tiers: 14.0

What it means

More than five times the approval waiting, from less than twice the rounds.

The delays do not add up. They multiply, which is why the largest contracts fall so far behind.

Five whys, down to something we can change

01
Why does the segment average 32 days?
Large subcontracts take far longer in Negotiation and Approvals.
02
Why do they take longer?
They go through more redline rounds.
03
Why more rounds?
Their starting terms do not hold up, so suppliers push back on four risk clauses.
04
Why do the terms not hold up?
Every subcontract starts from one template written for small, low-risk purchases.
05
Why does each round hurt so much?
There are no fallback positions, and any change sends the contract back through every approver.

Root cause 1

One template for every contract size

Large subcontracts start with liability, insurance, indemnity, and flow-down terms that do not fit their risk, so pushback is built in from the first draft.

drives: how many rounds

Root cause 2

Full re-approval on any change, with no fallbacks

Every pushback needs a fresh Legal decision, and every change restarts the whole approval chain, however small it is.

drives: what each round costs

Rounds × cost per round. Fix both, and the 18-day goal is within reach.

How I got there

Ruled out staffing first. At 70% utilization the team has room, so adding people would not shorten the queue.
Followed the outliers. The slowest subcontracts were mostly over $250K, but one mid-size outlier showed redline rounds were the real mechanism.
Counted the causes with a Pareto chart, tagged against a fixed category list so the counts can be trusted.
Asked why until the answer was changeable. A template and an approval rule can be fixed. "Big contracts are hard" cannot.
Held the fixes for Improve. The causes are now confirmed with data, which is the condition for designing a solution.

Tollgate · sponsor review

Is the root cause proven with data, or just plausible?Both causes are backed by counts: the Pareto of redlined clauses and the sign-off cycles per tier. Staffing was ruled out first.

Passed

Improve · Designing the fix

The first draft of a fix is rarely the right one.

The solutions followed directly from the two root causes. The real work was stress-testing them: each answer raised a harder question, and each question changed the design.

What this shows

How I design a fix that is fast and still controlled: tying every change to a root cause, challenging my own first draft, and building in approval, audit, and error-proofing before anything rolls out.

Four solutions, each tied to a root cause

Fixes root cause 1 · number of rounds

Tiered templates

Separate starting terms by contract value for the four clauses suppliers push back on most.

Fixes root cause 2 · cost of each round

Fallback playbook, change-based re-approval, parallel review

Pre-approved concessions, re-approval only when a change needs it, and approval tiers reviewing at the same time. Thresholds stay as they are.

The decision trail

Each step below started as a reasonable answer that did not survive a harder question.

01
Where should the fallback positions come from?
First answerFrom the data. Tag where past negotiations actually settled on each clause, and offer those positions up front.
ChallengeA position suppliers accepted can still break corporate policy or a regulation. A faster process that produces non-compliant contracts is not an improvement.
DecisionData sets the fallbacks. Policy sets the floor: the strictest of corporate policy, regulation, and the customer's prime contract. No rung can go below it.
02
Is every term negotiable?
First answerGive each of the four clauses a ladder of positions.
ChallengeSome terms cannot be traded at any price: flow-downs required by regulation or the prime contract, and liability for things like bodily injury or a data breach.
DecisionThose sit outside the ladder entirely, marked fixed. Only discretionary terms get fallbacks.
03
Who is allowed to say yes?
First answerLet Procurement and the Contracts administrator accept a fallback without waiting on Legal.
ChallengeTo Legal and to an auditor, that reads as a loss of control.
DecisionLegal formally approves every ladder in advance, and Finance co-signs the ones with money attached. Every concession is logged automatically: contract, clause, rung, who accepted it, when, and under which playbook version.
04
What counts as a change?
First answerOnly send real changes back for re-approval.
ChallengeWithout a written rule, people re-approve everything to be safe, and the old delay comes back.
DecisionA three-bucket change rule, and a RACI so every step has exactly one owner.
05
What could go wrong with the fix itself?
First answerTrain people on the new playbook.
ChallengeTraining fades. The failure modes that matter most are the ones nobody notices until an audit.
DecisionScore the risks with an FMEA, and error-proof the top ones in the system so the wrong action is hard to take.

Data sets the fallbacks. Policy sets the floor.

The change rule

Every supplier change is classified before anything is routed.

Within the playbook

Accept and log

Procurement or Contracts accepts it. No re-approval. The concession is logged automatically.

Outside the playbook, above the floor

Targeted review

Legal decides, and only the approver whose area the change affects re-approves.

Below a floor

Cannot be accepted

Escalates to the floor's owner and is logged as an exception.

The playbook: contracts over $250K

Approved by Legal, with Finance co-signing liability and insurance. Smaller tiers have their own, lighter ladders.

Liability cap

Owner: Legal · Finance co-signs

Preferred3× contract value
Fallback 12× contract value
Fallback 21.5× contract value
Floor1× contract value
FixedNever capped: bodily injury, data breach, gross negligence, willful misconduct, IP infringement

Indemnity

Owner: Legal

PreferredSupplier covers all third-party claims from its work
Fallback 1Limited to supplier negligence or misconduct
Fallback 2Mutual: each side covers claims it causes
FloorSupplier covers bodily injury, property damage, IP infringement, and regulatory fines it causes

Insurance, general liability

Owner: Risk · Finance co-signs

Preferred$12M
Fallback 1$8M
Fallback 2$5M
Floor$5M, set by corporate risk policy

Fallback 2 meets the floor: the playbook can concede no further than policy allows.

Flow-downs

Owner: Compliance

FixedMandatory clauses from regulation or the prime contract. Not negotiable.
PreferredAll other prime contract terms flow down in full
Fallback 1Tailored to the supplier's scope of work
Fallback 2Only terms that touch the supplier's work
FloorEvery mandatory clause, plus anything the prime contract requires

RACI for the new flow

R does the work, A owns the outcome, C is consulted, I is informed. One A per row. Floor escalations go to Risk for insurance, Legal for liability and indemnity, and Compliance for flow-downs.

Activity	Procurement	Contracts admin	Legal	Finance	Process owner
Approve playbook and floors	C	C	A	R	I
Classify a supplier change	R	R	C	I	A
Accept a fallback within the playbook	R	R	I	I	A
Approve a change outside the playbook	C	R	A	C	I
Re-approve when money terms change	I	R	C	A	I
Escalate a floor breach	R	R	C	C	A
Maintain the concession log	I	R	I	I	A
Quarterly playbook review	C	R	A	R	C

Risks in the new process, and how each is prevented

A short FMEA. Each failure is scored 1 to 10 for severity, how often it could occur, and how hard it is to detect. Multiplied together, they give a risk priority number.

Failure	Sev	Occ	Det	RPN	Prevention
A concession is accepted but not logged	6	5	7	210	The final contract cannot be generated until every concession is logged
The playbook falls behind a policy change	7	4	6	168	Floor owners must notify on any policy change; quarterly review
The wrong tier's template is used	6	4	5	120	Template selected automatically from contract value
A value is entered below a floor	9	3	3	81	The system blocks the entry and routes it as an exception

Prove it before rolling it out

Pilot

Scope: Next 10 subcontracts over $25K
Length: 8 weeks
Before it starts: Playbook approved, team trained

Success criteria are fixed before the pilot begins, so the result cannot be argued after the fact.

Roll out only if all are met

Average cycle time, cleared to PO issued 20 days or less
Average redline rounds 2.5 or fewer
Concessions logged 100%
Floor breaches accepted Zero
Guardrails: modifications and supplier claims No increase, tracked 90 days

If the pilot fails, which criterion failed decides where to go back

"The pilot failed" tells you nothing on its own. Each criterion points to a different part of the project.

What failed	What it means	Go back to
Redline rounds did not drop	The template fix is not working, or the root cause was incomplete	Analyze: re-tag the pilot's redlines
Rounds dropped, cycle time did not	Each round still costs too much; people may still be re-approving everything	Improve: check how the change rule is being used
A floor breach, or a concession not logged	The controls failed	Stop. Fix the error-proofing before any re-pilot
A guardrail rose	Speed was bought with weaker contracts	Improve: tighten the fallback positions

The rule: adjust and re-pilot once. If a second pilot fails, the root cause is probably wrong, so the project returns to Analyze instead of tweaking the fix again.

What the project segment should look like

Projected from the sample, pending the pilot. Rounds fall because terms start closer to agreement; each round costs less because most concessions need no re-approval.

Today

32 days

Projected

18 days

Negotiation: 21 to 12 days
Approvals and PO: 11 to 6 days
Redline rounds, all subcontracts: 3.4 to 2.0
Sign-off cycles, contracts over $250K: 14 to about 3
Full pipeline, proposal to closeout: 98 to 84 days

How I got there

Tied every solution to a confirmed root cause, so nothing on the list was just a favorite idea.
Challenged my own first draft at each step. The biggest correction: settled positions from past deals can still break policy, so the floor comes from policy and regulation, not from the data.
Kept control while removing delay. Legal approves the playbook in advance, Finance co-signs money terms, and every concession leaves an audit trail.
Wrote the rules people would otherwise improvise: a three-bucket change rule and a RACI with one owner per step.
Error-proofed the highest risks in the system instead of relying on training, and set pass or fail criteria before the pilot.
Planned for failure before the pilot started, mapping each failed criterion to the phase it sends the project back to.

Tollgate · sponsor review

Did the pilot meet every criterion set in advance?Yes: 19.4 days, 2.3 rounds, every concession logged, no floor breaches. Approved for full rollout.

Passed

Control · Keeping it fixed

A fix only counts if it is still working six months later.

Improvements fade. People drift back to old habits, policies change, and new hires never learn the playbook. Control catches that drift early and hands the process to an owner who keeps it running after the project team walks away.

What this shows

How I prove results honestly, separate real signals from normal variation, and build a control plan where every measure has an owner, a trigger, and a response.

Results: what happened, and what is still projected

The pilot met every success criterion, so the playbook rolled out to all subcontracts. Three months of rollout are actual. The final three months are a projection from the trend, shown as a dashed line until the data arrives.

Average cycle time, supplier cleared to PO issued

Month 1 ran slightly slower than the pilot while the wider team learned the playbook. That is normal for a rollout and is why the target date sits at month six.

Cycle time, month 318.6 daysBaseline 32 · target 18

Redline rounds2.1Baseline 3.4 · target 2.0

Within the playbook88%At or above 85%

Floor breaches accepted0On target

Modifications in 90 days11%Guardrail held · was 12%

Supplier claims5%Guardrail held · was 6%

Control chart: signal or noise?

Every contract varies a little. Limits calculated from the data show how much variation is normal, so the team reacts to real signals and ignores the rest.

The one signal, and what happened

Contract 22 took 33 days, above the upper limit. The Contracts administrator traced it within two days: a new supplier rejected every liability position, and the change went to Legal for targeted review exactly as the rule intends. No floor was breached. It was a one-off cause, so nothing in the process changed, and the supplier's position was logged for the next playbook review.

Individuals chart. Limits are the average plus or minus 2.66 times the average moving range, calculated without the investigated point.

The control plan

Every measure has someone watching it, a clear trigger, and a response decided in advance.

Measure	Target	Watched by	Trigger	Response
Cycle time per contract	18 days average	Contracts admin, weekly	A point outside the limits, or 7 in a row above average	Investigate within 2 days; Director of Contracts owns the response
Redline rounds	2.0 or fewer	Contracts admin, monthly	Monthly average above 2.5	Review which clauses drew pushback; feed the playbook review
Concessions within the playbook	85% or more	Director of Contracts, monthly	Below 80%	Bring the quarterly playbook review forward
Floor breaches accepted	Zero	Floor owners, every exception	Any	Immediate review by the floor's owner
Concessions logged	100%	Legal, monthly audit sample	Any missing	Fix the system gap, then retrain
Guardrails: modifications and supplier claims	No increase	Finance and Legal, quarterly	Either rises	Pause and review the playbook positions involved

The feedback loop: how the playbook stays honest

The concession log is not only an audit record. It is the data that tells the team when a position no longer fits reality.

Log every concession
Clause, rung, who accepted it, and the playbook version, captured automatically.
Review quarterly
Which rungs get used, where suppliers push past the playbook, and any floor exceptions.
Recalibrate the ladders
If one fallback is used in most deals, the preferred position is unrealistic and moves.
Approve and republish
Legal approves, Finance co-signs money terms, and a new playbook version goes live.

Back to step 1 with the new version

Sustained shiftThe control chart drifts, not just one pointThe process has changed. Reopen Analyze.
Floor exceptions clusterSuppliers keep pushing past the same floorTell the floor's owner. Changing a floor is a policy decision.
Rules changeA regulation or prime contract is updatedCompliance updates the fixed terms before the next contract.

Handoff

Process owner: Director of Contracts
Watches the chart: Contracts administrator
Playbook review: Quarterly, Legal accountable
Next project: Acceptance and invoice disputes

The runner-up from project selection is chartered next. Fixing disputes should also shorten closeout.

Lessons learned

Ask the people who do the work before trusting the map. The re-approval rule was invisible in the system data.
Speed and control are not a trade-off when decisions are made in advance and every use is logged.
Set pass or fail criteria before the pilot. It ended every debate about whether the change worked.

How I got there

Kept actual and projected results visibly separate, so no one has to guess which numbers are proven.
Used a control chart instead of reacting to every slow contract. One real signal was investigated. Normal variation was left alone.
Gave every measure a trigger and a response, decided before they were needed.
Handed the process to a permanent owner and scheduled the review that keeps the playbook current.
Built a feedback loop and exit triggers, so the playbook recalibrates from its own data and a real shift sends the team back to Analyze.
Closed by sequencing the next project, so improvement continues instead of stopping when this one ends.

Tollgate · sponsor review

Is the process owned, measured, and able to correct itself?The Director of Contracts accepted ownership, the control plan is live, and the project was closed.

Closed

Ninety-eight days became eighty-four, and the slowest part of the pipeline now runs on a system instead of on email.

The hospital network's next order will reach its clinics about three weeks sooner. Nobody works harder to make that happen. The work simply stopped waiting.

Fauxmed Supply Co. is fictional. The method is real. For what goes into each subcontract and what happens after signature, see How I Work: Subcontracts. For a working system built on the same approach, see Case Study 03.

Ninety-eight days. Thirteen of them were work.

The criteria, weighted before anything was scored

Stress test: does the choice survive a different point of view?

An operations lead who values ease

A CFO who values cost

How I got there

Subcontract cycle time: supplier cleared to PO issued

SIPOC: the boundaries, and who needs to be in the room

How I got there

The pipeline, stage by stage

Scope and LOE

Customer award

Flow-down plan

Sourcing

Negotiation

Approvals and PO

Kickoff

Invoice and pay

Closeout

Where the 98 days go

The project segment, one subcontract at a time

How I got there

First question: is this a people problem or a process problem?

Workload against workforce, role by role

Following the slow ones

Which clauses suppliers push back on

Why each round costs so much

Sign-off cycles per subcontract

Five whys, down to something we can change

One template for every contract size

Full re-approval on any change, with no fallbacks

How I got there

Four solutions, each tied to a root cause

Tiered templates

Fallback playbook, change-based re-approval, parallel review

The decision trail

Where should the fallback positions come from?

Is every term negotiable?

Who is allowed to say yes?

What counts as a change?

What could go wrong with the fix itself?

The change rule

Accept and log

Targeted review

Cannot be accepted

The playbook: contracts over $250K

Liability cap

Indemnity

Insurance, general liability

Flow-downs

RACI for the new flow

Risks in the new process, and how each is prevented

Prove it before rolling it out

Pilot

If the pilot fails, which criterion failed decides where to go back

What the project segment should look like

How I got there

Results: what happened, and what is still projected

Average cycle time, supplier cleared to PO issued

Control chart: signal or noise?

The control plan

The feedback loop: how the playbook stays honest

Log every concession

Review quarterly

Recalibrate the ladders

Approve and republish

Handoff

How I got there

Have a Complex Problem Worth Solving?