Reading a System Before Building for It: What Discovery Actually Involves

A lot of consulting engagements open with a workshop — stakeholders in a room, whiteboards, a facilitated discussion about pain points. Discovery work under Constraint Engineering starts differently: watching the actual physical and digital movement of work, on site where that's what the problem requires, and reviewing the systems that are supposed to be tracking it.

The reason is simple — people's mental model of their own process is usually a simplified, slightly-idealized version of what actually happens. That's not dishonesty, it's just how anyone describes a process they're inside of. Watching catches the steps nobody thinks to mention because they're too routine to describe.

Three things, generally: where physical or document movement and the systems tracking it diverge; where the same information gets entered or checked more than once; and where a delay exists that isn't explained by the actual work taking that long.

None of this can be done from a call. That's the practical reason travel is part of how HSA works — the observation step doesn't have a remote equivalent that's actually reliable, in the same way a 2014 foundry system couldn't have been built from a spreadsheet nobody had walked the floor to verify.