the SOP methodology

Standard operating procedures are supposed to describe processes. In practice, at a large organization that has been running long enough, they describe the official version of processes — the version that was written down at some prior moment, approved by someone, and then not updated as the actual execution drifted. The gap between the SOP and the practice is where the institutional knowledge lives. It lives in the people who have been doing the job long enough to have absorbed the edge cases, the exceptions, the counterparty-specific accommodations, the steps that were added informally because something broke once and needed a patch. Extracting that knowledge — making it visible enough to audit, improve, or eventually automate — required a methodology that started from the assumption that the documentation wasn't the truth.

The sessions worked by sitting with the practitioner and asking them to perform the process while explaining it. Not to describe it in the abstract — to do it, step by step, and narrate what they were doing and why. The narration surfaced things that description never would: the check they ran automatically that wasn't in any SOP, the exception path for a specific counterparty type that had been handled the same way for fifteen years without ever being written down, the system workaround that had been invented to compensate for a gap in the tooling that was itself years old. Every session produced findings that surprised the team lead who had approved the original SOP. The documentation had been accurate at the moment it was written. The practice had grown around it.