John Maynard Keynes, the acclaimed economist, once stated, “It is better to be roughly right than precisely wrong.” I have found this to hold true for business analysis and solution requirements.
I’ve observed over the years that when time is short, analysts often instinctively dive into details before they understand the full breadth of scope and business impacts. This often results in a requirements model that appears, albeit deceptively, sufficiently detailed and complete to meet a specified date on the project schedule.
As a case in point, I recently participated as a judge in a “Business Analysis with the Stars” game show held at an Atlanta IIBA meeting. In the game, participants were given a business problem and asked to provide a summary of their approach, and the rationale for their approach and artifacts created. They were to be scored on the merits of the approach and types of deliverables. By necessity and by design, the contestants did not have a lot of time to do their work in great detail. They didn’t have time to actually elicit requirements from real stakeholders. They were clearly limited in the depth of knowledge available to them.
What I found interesting was the degree to which some contestants made some pretty broad assumptions – or even made stuff up – in order to present the more “complete” and polished looking deliverable as if that, above all else, was most important.
What I found fascinating was that analysts seem to have an inherent discomfort in leaving assumptions as assumptions until they can be verified. There seems to be an impulsive dive into detail in order to produce something precise, detailed and polished looking as opposed to something we know to be right, but can only give a confidence level as to its completeness.
It seems as if the analyst puts greater emphasis on being perceived as capable of producing a detailed document within a timeframe than on being as accurate, complete and easy to understand as possible. Why? Because business analysis performance measurement is often weighted more heavily on how the analyst filled out the template, met the style guidelines, and completed the task within a targeted time frame. Unknown or “in progress” items are perceived as a sign of lack of effort or skill on the part of the analyst.
According to Aristotle, “It is the mark of an instructed mind to rest satisfied with the degree of precision which the nature of the subject admits and not to seek exactness when only an approximation of the truth is possible.”
While giving the illusion of completeness and detail may be more effective at getting sign-off on a document, it jeopardizes the success of the delivered solution, and the project team typically ends up paying later with interest in terms of defects, change requests and issues at user acceptance time.
By getting into details too quickly, we can present a false image of completeness based on assumptions and analyst opinions.
I’ve been better served by seeking to understand the breadth of scope and impacts and progressively get into details as opportunities to gather them emerge. It is important to be clear in distinguishing what we know from what we think we might know.
Even if it feels uncomfortable – leave assumptions as assumptions. Work as quickly as possible, but don’t sacrifice accuracy for illusory precision.
