Starting the Problem Half solved: Strategic about Successful requirements gathering

In one of the recent round table discussions that I spoke on the differences between traditional and agile approaches, it became apparent to me that there was some disconnect in the notion of what constitutes a requirement. The software development approaches leveraging traditional plan driven approaches to project management focuses on scope planning activities that centers on requirement definition because it is well known that a successful definition of the problem means we have the problem half solved.

Considering the developments in agile approaches to project management where change is welcome even at later stages in the development, the gathering of up-front requirements is often frowned upon. Although the requirements definition may be a daunting task when there is ambiguity around it, value delivery happens only when an attempt is made to eliminate such ambiguity. When client facing members fail to ask powerful probing questions and engage the expertise to eliminate some level of ambiguity, the business goals are often compromised.

For instance, a requirement should at a minimum address what the software must to do satisfy what the users need so that the value is maximized, and benefit is realized. On the contrary, if the requirements are conflicting and attempts made to eliminate ambiguity are thwarted, then neither the traditional nor the agile approaches to software development will benefit. As the movie, Apollo 13 calls its mission at the end, such requirement gathering from the beginning can only lead to "Successful failure."

Readers are directed to check out an interesting video at this point to gather some insights into the incomplete requirement gathering This video is on youtube at https://www.youtube.com/watch?v=BKorP55Aqvg. What went wrong here? A few thoughts are as follows. Share your thoughts.

• Is starting immediately with a “No” a good approach?
• When trying to ask what the end result will look like, is attempting to over-please rather than understand the business goal appropriate?
• Is both the client facing person and the project manager on the same team as the expert?
• Were any attempts made to negotiate for an acceptable best alternative?
• Is this project setup to succeed?
• Is this a productive meeting?

What powerful questions can you add to ensure that redefine the requirements correctly? Stepping outside of this video into our own projects or products, what additional questions can we ask to understand the client’s requirement and the reasons behind the requirements better to position ourselves for success?