Worked Example 2's own steady state: 18 + 15 + 42 + 22 + 12 + 11 = 120 units, moving at the constraint's 8 units/day. Little's Law applied to each stage — a stage's WIP divided by throughput is the time a job spends there — gives 2.25 + 1.875 + 5.25 + 2.75 + 1.5 + 1.375 = 15.0 days, which is the CONWIP limit's promise (120 ÷ 8 = 15) arrived at from the other end. The queue and the machine at Op 30 hold 42 + 22 = 64 units, so 64 ÷ 8 = 8.0 of the 15 days is one operation, and a four-hour breakdown there is absorbed by a buffer holding 5.25 days of work. The red tab is the defence table's arithmetic, drawn on the same ruler: one bypass is one more unit, 121 ÷ 8 = 15.125 days — 0.125 days added to all 120 jobs, not only to the one let in. Caveat: dividing per stage this way assumes every job passes every stage at the same 8/day, which is what a serial steady state means; a stage with scrap or a shared machine would need its own throughput.
Why CONWIP Works Where Kanban Fails
Traditional Kanban works beautifully in repetitive, high-volume environments: a dedicated card circuit for each part at each station, triggered by downstream consumption. But in aerospace manufacturing — where a machine shop might process 300+ different part numbers through varying routings, with lot sizes of 1–20 — maintaining individual Kanban loops for every part-station combination is impractical to the point of absurdity.
CONWIP solves this by abstracting the control to a higher level: one global WIP limit for the entire value stream. It does not matter which part number enters or which routing it takes. What matters is the total count of units in the system. When one exits, one enters. The routing, the part number, and the priority are handled by the scheduling system. The WIP cap is handled by CONWIP.
This is a direct application of Little’s Law: CT = WIP / TH. By fixing WIP at a calculated level and allowing throughput to be determined by the constraint, cycle time becomes a guaranteed output of the system rather than an unpredictable accident.
Setting the CONWIP Limit
The calculation is simple. The discipline to maintain it is not.
📐 The CONWIP Formula
CONWIP Limit = Target Lead Time × Throughput Rate
This is Little’s Law rearranged: WIP = CT × TH. You choose the lead time you want to promise. You measure the throughput your constraint can deliver. The product is the maximum WIP you can allow.
Scenario: A fabrication shop targets a 15-day lead time. Throughput = 8 units/day. Current WIP = 340 units.
Step 1: Calculate the CONWIP limit.
CONWIP Limit = 15 days × 8 units/day = 120 units
Step 2: Current state assessment.
Current CT = 340 ÷ 8 = 42.5 days. You are promising 15 days and delivering 42.5 days.
Step 3: WIP reduction roadmap (12 weeks).
Reduction needed: 340 – 120 = 220 units. Reduce in controlled increments:
| Week | WIP Target | Expected CT | Action |
|---|---|---|---|
| Week 0 (current) | 340 | 42.5 days | Baseline measurement |
| Weeks 1–3 | 280 | 35.0 days | Reduce releases to 6/day (below TH of 8) while system drains |
| Weeks 4–6 | 220 | 27.5 days | Continue reduced releases; validate TH remains at 8/day |
| Weeks 7–9 | 170 | 21.3 days | Increase releases back toward 8/day as WIP approaches target zone |
| Weeks 10–12 | 120 | 15.0 days | CONWIP limit activated: one out = one in |
Critical observation: Throughout this entire 12-week reduction, throughput remains at 8 units/day. The constraint didn’t slow down — it had 340 units to work through. You delivered the same total output. The only thing that changed was lead time, which dropped from 42.5 days to 15 days.
What management usually fears: “If we stop releasing work orders, we’ll run out of work.” This fear is unfounded as long as WIP exceeds the CONWIP limit. There are still 120+ units in the system at all times — the constraint will not starve.
How the System Operates Under CONWIP
Scenario: CONWIP limit = 120 units. The system is at steady state.
Before event: 120 units in system. 18 at Op 10, 15 at Op 20, 42 in queue at constraint (Op 30), 22 at constraint being processed, 12 at Op 40, 11 at Op 50.
Event: One unit ships from Op 50 (exits system). System WIP drops to 119.
Response: The CONWIP signal triggers release of one new work order at Op 10. System WIP returns to 120.
Why this works: The release rate is automatically tied to the exit rate, which is tied to the constraint’s capacity. You never release faster than the constraint can process. WIP stays constant. Lead time stays constant. The system self-regulates.
What happens if the constraint slows down: If the constraint has a 4-hour breakdown, fewer units exit, fewer units are released, and WIP stays at 120. The buffer in front of the constraint absorbs the disruption. When the constraint resumes, it works through the buffer and the system returns to steady state without intervention.
Defending the CONWIP Cap
Setting the CONWIP limit is the easy part. Defending it is the hard part. Here is what will happen, guaranteed:
A program manager will arrive with an urgent job. “This part is critical. We need to get it started immediately. Just this once, can we release it even though we’re at the cap?”
The answer must be no. Here is the data to bring to that conversation:
| Argument | Response (with data) |
|---|---|
| “But this job is critical!” | Releasing it increases lead time for every other job — including the other 119 “critical” jobs already in the system. At 121 WIP, the new CT = 121 ÷ 8 = 15.125 days. It gains 0.125 days of arrival advantage and adds 0.125 days to 119 other jobs. |
| “We’ll fall behind!” | Throughput is unchanged at 8/day. You are not falling behind. You are controlling lead time. The job will ship in 15 days under CONWIP. Without CONWIP, it would have taken 42.5 days. |
| “Just this once.” | Every bypass is permanent. That extra unit stays in the system until it exits. If you bypass once per week, in 12 weeks WIP is back to 132 and lead time is 16.5 days. In 6 months, you’re back at 200+ WIP. |
| “The customer is waiting.” | Expedite by priority within the existing CONWIP pool. Move it to the front of the queue at each operation. This gets it through faster without adding WIP. |
⚠️ Every Bypass Adds to Every Other Job’s Lead Time
Every time management bypasses the CONWIP cap to “just get this one job started,” they add to every other job’s lead time — including the critical ones. CONWIP is not about slowing things down. It is about moving every job faster by refusing to let congestion build. The math is non-negotiable: more WIP at constant throughput equals longer lead time for all jobs.
CONWIP vs. MRP Release
Most aerospace facilities use MRP (Material Requirements Planning) to determine when to release work orders. MRP calculates release dates by backward-scheduling from the due date using planned lead times. The problem: MRP’s planned lead times are estimates loaded during system setup, rarely validated, and almost never updated. They do not account for current shop floor conditions — current WIP, current constraint capacity, or current variability.
The result is that MRP releases work orders based on fiction. If MRP thinks lead time is 20 days but actual lead time is 40 days (because WIP is twice the CONWIP level), MRP will release jobs 20 days too late — or, more commonly, planners will override MRP and release everything early “just in case,” flooding the system with WIP.
CONWIP does not replace MRP. MRP still determines what to make and when it is due. CONWIP controls when to release it. The integration:
MRP generates the demand signal
MRP determines which jobs are needed and their due dates. This is the “what” and “when.”
CONWIP controls the release gate
Jobs are queued in priority order at the release point. When a unit exits the system, the highest-priority job in the queue is released. This is the “how fast.”
Priority is determined by due date
The release queue is sorted by due date (earliest due date first). This ensures that the most urgent jobs enter the system first, within the CONWIP cap.
💡 CONWIP Is Not About Slowing Down
The most common misconception about CONWIP is that it slows production. It does not. Throughput is determined by the constraint, not by the release rate. CONWIP controls lead time by controlling congestion. The result is that every job moves faster because it spends less time waiting in queues. Total output is unchanged. Individual job speed increases. Schedule predictability increases. Everybody wins — except the manager who equates “lots of jobs in progress” with “lots of progress.”
🎯 The Bottom Line
CONWIP is Little’s Law turned into a production control system. It is the simplest pull mechanism that works in high-mix, low-volume aerospace environments. Calculate the limit, implement the one-out-one-in rule, and defend the cap against the relentless organizational pressure to bypass it. The reward: predictable lead times, reduced inventory carrying cost, and the ability to promise — and keep — delivery dates. Next: The Black Book Problem — why none of this works if your ERP data is fiction.
Interactive Demo
CONWIP limit = target lead time × throughput. Then the harder half: draining to it without stopping the line. Withhold releases and watch WIP fall while throughput does not move.
Stop reading, start modeling
Model your process flow, run simulations, optimize staffing with TOC math, and test your knowledge with 107 interactive checks — all in one platform.