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?
