Then BoingBoing pointed me to the Van Halen Brown M&M story in snopes.com.
The brown M&M's was actually a compliance test. If you read the contract rider, and complied with all the terms and conditions, you'd filter the brown M&M's off the buffet.
If you were not prepared for the technical requirements for the Van Halen show, you'd book them, skip reading the rider, hope it went off well, and -- generally -- fail to filter the M&M's.
Statements of Work
We write a lot of Statements of Work (SOW's) with lots of "assumptions". A common assumption is that deliverables will be approved within three days. We often write it, suspecting that the client can't actually take action in three days.
But we never really know until we start work. Once we're there, we discover that it takes them a month to get ready to spend five days reviewing a document and wondering what to do. Now we're five weeks behind the original schedule, and the customer will blame us for "springing" the 3-day decision window on them.
If we had a "No Brown M&M's" assumption, perhaps we'd have an earlier indication that things weren't going to work out well.
I'm also wondering if there needs to be a "Brown M&M" use case. Something egregious, but small. Something that should lead to client confusion. If they approve the scope of work, including the Brown M&M use case, we know they didn't really read or review the scope of work.
Perhaps there should be a "Brown M&M" in the architecture. Perhaps an irrelevant component that we insist must be downloaded and installed in the development environment. We simply check that it's there. If not -- well -- what else will be wrong?