Step 1
Define the system
We decide what system we are looking at and what outcome matters.
Constraint Analysis
What is a constraint analysis?
A practical way to find the bottleneck that is holding the whole system back.
TL;DR
A constraint analysis is a short, evidence-based diagnosis. I look for the one limit controlling throughput, show why it matters, and map the smallest change that will move the system. If the bottleneck is in the offer, the workflow, or the structure around the work, the analysis should show that before anyone spends time on the wrong fix.
The first sign is usually not subtle. People are busy, the queue keeps growing, and nothing they try seems to stick. The team works harder. The report gets longer. The meetings get more careful. The constraint does not move.
Step 2
Find the constraint
We identify the part of the system that is limiting throughput right now.
Step 3
Check the logic
We test the cause-and-effect chain so the diagnosis is not just a guess.
Step 4
Choose one move
We pick the smallest change that is most likely to move the whole system.
A written diagnosis
A plain-English statement of what is actually limiting performance and why.
The evidence trail
The observations, documents, or data that support the diagnosis.
The first move
A concrete next step you can take without turning the whole business upside down.
Follow-through if needed
Implementation support when the fix needs more than a memo and a meeting.
Questions and answers
The constraint is the part of the system that most limits throughput. It is the bottleneck, the limiting factor, the place where extra effort elsewhere does not move the result.
Most of these start as a short diagnostic engagement. If the situation is simple, the analysis can be quick. If the logic is messy or the system spans multiple departments, it takes longer because the evidence has to be checked carefully.
You get a clear diagnosis, the evidence behind it, and the next move. If the fix needs implementation support, that can follow from the same conversation.
No. I work on healthcare, embedded systems, software, and business problems where the same pattern shows up: busy people, stalled progress, and a system that is not being improved at the right point.
That is the normal case. If the answer were obvious, the system would probably already be moving. The point of the analysis is to find the thing that is not obvious but is still driving the result.
Want the flagship diagnosis?
If the system is stuck, see the flagship fixed-fee service or start with sample outputs before you decide.
Common Sense Systems, Inc. | Kirkland, WA | Constraint analysis and improvement work since 1996