>Something similar _almost_ happened a couple of years later in another project (due to miscommunication by someone doing requirements gathering) and this time

>Something similar _almost_ happened a couple of years later in another project (due to miscommunication by someone doing requirements gathering) and this time we caught it early. Right on. Requirements gathering and problem scoping is refined conversation. We were in a meeting with someone who wanted us to predict an event that caused losses in the 9 figures 48 hours before it happens and trigger an alert. 48 hours sounded round and arbitrary, so I used "negative framing" and asked "At what point would an alert be useless. At what point is it too late to inform you?" He said "It's never too late. Even if you predict it two minutes before, we can do things. We have procedures". Effectively reducing from 48 hours to 2 minutes. This changes the whole thing. Requirements that are polluted by client's solutions should always be explored further for the actual job to be done, and the actual problem to be solved.