There was a story of a rock band in the early 80’s (Van Halen) that had a stipulation in their venue contracts where they were to play that stated they were to be given a bowl of M&M’s with no brown ones in it. If there was a brown M&M, they threw a fit and wouldn’t play!
I have migrated this practice to Identity Management. Actually, any QA testing procedures.
Now, before I get ahead of myself, let me explain the “why” part of the brown M&M clause. You see, Van Halen had a lot of requirements that were required to pull off a safe and successful performance, and if any of those were overlooked, people could get seriously hurt, or massive amounts of damage be done to a venue. In the IdM world, there are a ton of little pieces and any one of them can make an entire implementation fail.
When they found the brown M&M’s in their bowl, these were the same people that overlooked the requirement on the weight support for the stage and the whole thing sake through the brand new flooring, causing over $80k in damages!
In IdM land, if you’re migrating an environment, and you forget to update a configuration XML file, you may accidentally wipe out all production data because it’s still pointing to production for deletes! Obviously this is bad, and we all know how easy it really is to do this.
So, back to the brown M&M’s. When Van Halen saw that there were brown M&M’s in the bowl, it clearly stated to them immediately that the overseers didn’t meticulously go over all the details of the contract (not just the M&M’s part), and would require a recheck of every item on the list before they would perform.
My brown M&M’s in IdM are log file settings. These things get changed very frequently in all environments, and are easily forgettable to reset. If I am tasked to migrate an environment or check for success of a new environment, I will check the log files of both environments. If they don’t match exactly, then I reply back with, “The systems are out of sync and need to be reexamined”. This will prompt the implementer (sometimes me) to go back through the migration documentation and double-check all configurations.
I guess this is kind of similar to the validity of a True or False statement. For a statement to be True, all of the parts must be true. If even one part is False, the entire statement is False. So if one piece of an environment is different, the entire environment is under suspicion.
To prevent things like this from happening, I make sure to make super-detailed documentation with screen shots along the way (and sometime even with videos!). I have never heard of a client complaining of “too much documentation”… have you?