Work in Progress (WIP)
Work in progress is the amount of work that has been started and not yet finished, counted as jobs or units rather than valued in currency. It is the quantity a shop manages to control lead time, and it is the lever behind every kanban limit.
Work in progress is a count, not a cost. It is the set of jobs that have been released to the floor and have not yet been finished, whether they are being worked on, waiting at a machine, or sitting in a tote between operations. Most of that population is waiting rather than being cut, which is the single most useful thing to understand about it. The closely related term work in process is the accounting view of the same material: the accumulated value of material, labour and applied overhead in those unfinished jobs, carried as a current asset. Shops use the two phrases interchangeably in conversation, and the distinction only matters when you are deciding whether you are managing a quantity or valuing a balance.
Little's Law is what makes the quantity worth managing. Lead time equals work in progress divided by throughput, so if throughput is set by your capacity and your constraint, the only lever left on lead time is how much work is on the floor. A shop with forty open jobs and a throughput of four a day quotes ten days whether it likes it or not. Releasing a fifty-first job does not make the shop faster; it makes every promise one job longer.
High work in progress costs more than floor space. A part that waits three weeks between operations is a part whose defect you will discover three weeks late, after you have added labour to it. Long queues also destroy the schedule's meaning, because when everything is started nothing is prioritised, and expediting becomes the only way to move anything. The busyness is real and the output is not: machines run, people are occupied, and the shop is slower than it was.
Capping it is the fix, and the cap has to be a rule rather than an intention. A kanban loop does this physically, because a card is permission to start and there are only so many cards. A per-work-centre limit does it numerically. Either way the uncomfortable move is the same one: start fewer jobs, and accept that a work centre with no queue sometimes stands idle.
Zero is not the target. A constraint with no buffer in front of it starves, and starving the bottleneck costs throughput you cannot get back. The right amount of work in progress is enough to keep the constraint fed and no more, which is a number you find by lowering the cap until something upstream starves, then settling just above it.
Lead Time = Work in Progress / Throughput, known as Little's Law. At a fixed throughput, halving the work released to the floor halves the time an average job spends on it.
A shop runs four jobs a day and keeps forty open on the floor. Little's Law puts its average lead time at ten days, which matches what customers experience. The owner caps releases at sixteen open jobs. Throughput holds at four a day because the constraint is still fed, but lead time falls to four days. Nothing got faster and no capacity was added. The queue in front of each machine got shorter, so each job spent less of its life waiting.
Is work in progress the same as work in process?
In practice yes, and in precise use no. Work in progress is the count of unfinished jobs you manage to control lead time. Work in process is the accounting value of those same jobs, sitting on the balance sheet as a current asset. Same material, two questions: how many, and worth how much.
How do I set a WIP limit without guessing?
Start from where you are. Count the jobs currently open and your throughput per day, then set the cap a little below today's count rather than at a theoretical ideal. Lower it a step at a time and watch the constraint. The moment the bottleneck starves you have gone one step too far.
Why does cutting WIP shorten lead time?
Because lead time is work in progress divided by throughput. Cutting the number of open jobs cuts the queue in front of every machine, and queue time is most of what a job experiences. The work itself takes exactly as long as it always did; it just stops waiting as much.
Can work in progress be too low?
Yes, and the cost is throughput rather than lead time. A constraint with nothing queued in front of it stops, and an hour lost at the constraint is an hour lost for the whole shop. Keep a deliberate buffer before the bottleneck and run lean everywhere upstream of it.
How does a kanban loop actually cap WIP?
The cards are the cap. Work cannot start without a card, and cards only free up when a job finishes and releases one, so the number of cards in the loop is the maximum number of open jobs. It turns a limit you intended into a limit the floor physically cannot exceed.