Methodology
What a Constraint Discovery Engagement Actually Finds
The Constraint Discovery Engagement page explains what it costs and how it's scoped. This is about what it's actually looking for.
It's looking for one thing, not a list of problems
Most operational audits produce a list — twenty things that could be improved, ranked loosely by how annoying they are. A Constraint Discovery Engagement is built to do something narrower: find the single point in the system where fixing it improves everything downstream, and where fixing anything else wouldn't.
That's a different question than "what's wrong here." A lot can be wrong with an operation and still not be the constraint — meaning fixing it wouldn't actually change total throughput. The engagement exists to separate real constraints from things that are merely annoying.
It starts with observation, not an interview
A Discovery Engagement starts by watching how work actually moves — physically, on site, and through whatever systems track it — rather than asking staff to describe the process from memory. People describe the process as it's supposed to work. Watching shows how it actually works, and the two are rarely identical.
This is the same instinct behind a production tracking system HSA's founder built for a foundry in 2014: the useful data didn't come from asking people what happened, it came from measuring what physically happened and deriving the rest from there.
It ends with a specification, not a sales pitch
The deliverable is a technical specification of the constraint and what removing it would require — detailed enough that a client's own developers could build from it without HSA, if they chose to. That's a deliberate design choice: if the diagnosis is only useful when paired with a proposal to build something, it isn't really a diagnosis.
Related Services
Have a specific operation in mind?
This is general analysis. Confirming what's actually true for your business is what a Discovery Engagement is for.