John Maynard Keynes said, “It is better to be roughly right than precisely wrong.” This is certainly true in the business of solution delivery.
“Early on, the goal is not to be right, but rather to be wrong in interesting, illuminative ways. Oh, it’s nice to feel like a genius when you do get it right the first time; but that’s rare. Much more common is that you think that you got it right, because your customer nods and doesn’t say much, when what’s really happening is that he’s too busy and just wants this meeting to be over. So being “right” in your early Echoes can lead to a false sense of security; and trying too hard to be right right away is misplaced effort and worry. Be as correct as you can manage, but recognize the limitations of your current knowledge.”
The idea of a “requirements workbench” is one that the guys over at Requirements.net have been consistently socializing over the past few months, and one that I have been following with interest.
Requirements.net has recently posted a Business Analyst Workbench Whitepaper and a Workbench Buyer’s Guide. To give the general gist of the workbench without stealing Req.net’s thunder, the workbench concept includes requirements management capabilities, but then goes beyond that to support the analyst through elicitation, elaboration and communication and validation activities.
A meeting can be very productive. A meeting can be a veritable nightmare. A lot depends on the professionalism of the participants.
I’ve devised a list that I think provides a broad but helpful guide that, if followed by meeting attendees, will result in a quality meeting where objectives can be met, and the tearing out of hair by its roots by participants can be greatly reduced, if not eliminated.