Recently, a team was trying to understand a seeming anomalous message (or lack of one, actually) in their complex computer transaction system. (Complex Computer Transaction System is abbreviated “E.R.P.”)
They discussed possible causes, settled in the likely culprit, constructed an experiment to try to replicate the issue and… everything worked perfectly. Meaning that the cause they were testing wasn’t the cause at all.
They worked to reconstruct the timeline from initial data entry to the point where the message should have been issued, and did a better job looking at what along the way could have suppressed the message.
After a series of trials, they found the culprit. It had originated in a data entry omission in a sister plant. They were able to turn the problem on and off at will with that one field.
They had actually discussed this possibility in their original discussion. But they had talked past it, and ended up focusing elsewhere.
There was a great learning here.
If you are discussing possible causes to a problem, write them down. All of them.
Get methodical. Be certain what evidence you either have in hand, or need to get, to eliminate a potential suspect from the list.
It feels slower, but it works better than faster approaches that don’t work.