Dodging the Requirements Hazard
I was recently reminded about an anecdotal story involving the late Charles Proteus Steinmetz, the great electrical engineer who lived in the late 1800s–early 1900s. It’s reported that around the turn of the century, Steinmetz was called out of retirement to diagnose a fault with a generator. After a couple of days of work, he marked a large X on the side of the machine and provided instructions on how to fix the fault.
According to the story, Steinmetz later submitted an invoice for an unprecedented $1,000, which must have been a fortune in the early 1900s. When asked to itemize his invoice, he reportedly submitted an invoice that showed $1 for making a chalk mark and $999 for knowing where to place the mark.
It’s difficult to know whether this story is true, but it illustrates an interesting point that is relevant today for organizations and projects—the issue of tacit knowledge or the unknown knowns.
Tacit knowledge includes the knowledge that business stakeholders possess that isn’t codified or written down anywhere—and information that they don’t even know they possess. In the example above, it included Steinmetz’s detailed knowledge of how the faulty generator worked.
The challenge for us as business analysts is that it is often essential to get at this type of information in order to write accurate requirements. We need to understand how existing systems, processes, and people interact—and although our business colleagues know all the answers, they might unconsciously omit vital details when we interview or meet with them.
This might include things that are so familiar to our business stakeholders that they become second nature, and they don’t think to mention them. A stakeholder might forget to mention a critical step in a process when we discuss it with them, because it seems so obvious.
We might even discover that we have different mental models leading us to use the same word as our stakeholder but with completely different meaning or consequence.
Think of trying to explain to somebody how to drive a car. You might explain how you place the key in the ignition and start the car—but would you have mentioned that you need to unlock the car door first? Or that you need to open a garage door to find the car in the first place?
A key technique for uncovering tacit knowledge is observation. It is well worth going to see the environment your business users and colleagues work in, and it is extremely valuable to see a process from its beginning to its end point. This insight can be followed up with interviews, workshops, or any other requirements elicitation technique.
Asking probing questions is also key—as is ensuring that key business terminology is defined and used consistently.
However you handle it, be sure to plan for tacit knowledge, and engage and work with your stakeholders to bring it into the spotlight.
