How intense a Project status call can be when you have to say "We won't be able to deliver our code in time"? And to state "Requirement Error" as reason will add fuel to fire. Following few days will demand lot of rework from revisiting requirements to updating all requirement artifacts, passing updated information to developers to getting defects fixed and tested .Coordination with project and Business stakeholders can be even more demanding . A successful release after interruption is a sigh of relief but what went wrong ? We should inspect few basic aspects of our Requirement Gathering practice :
Is our Business Stakeholder Surrogate User or Actual User ?
For most of the Business cases I worked on, I experienced 3-4 more Requirement Gathering iterations for any answer surrogate user did not have. As a Business
Analyst on a Project, possibility of interacting with any of them or sometimes both is high . How does it matter ? We cannot ignore the fact that surrogate User might
not have answers to all real time issues that Actual Users face and how do users resolve them today. This invites for few more Requirement Gathering iteration which could hit project deadlines badly. It is certainly a good idea to follow up on pending requirement , however at decent intervals.
There are intermittent issue which are known only to actual user. Neither can a Business Analyst think of such possibilities nor surrogate user guarantees to
convey such issues. This leaves a GAP in requirement. This situation is not easy to avoid , but requesting for a requirement workshop involving actual user might work.
Availability and accessibility of Business Stakeholders ?
How much available our User is ? I have worked on project where User's availability and accessibility was two hours a week . And it certainly makes the task in hand very challenging. The experience taught me how to plan my meetings time and content effectively. Divide the available time to accommodate several iterations. Smaller meetings ensured I do not have to wait for one more week for my clarifications.
Create bullet points for your requirement clarifications ,group related requirements together , prioritize them and share them along with meeting request. Even if half of stakeholders go through bullet points before coming to meeting , it mitigates lot of risk and conflicts.
Are we controlling Ambiguities in Requirement ?
If our requirement can be interpreted in several ways, it is a symptom of Ambiguous Requirement. Do we have Quality controls to avoid Ambiguity?
Do we re confirm our interpretation of Requirement and Expectation of Business stakeholders from solution ?
Do we re confirm our development team's interpretation ?
Do we re confirm our test teams interpretation of Business Rules and Quality aspects ?
While Requirement gathering workshops works best for Business Users , Project planning and estimations is best place to sort Developers understanding and Test
reviews gives insight of test teams understanding.
How do we avoid Scope Creep ?
Frequent changes to requirements, introduction of new requirement at regular intervals and frequent changes to our time estimates are signs of scope creep. A
bad requirement gathering can lead to Project scope. Not only it impacts deadlines but Project budget as well. A peer review of Requirement objective , scope ,
limitation , success and exceptions criteria will identify Open ended questions . New requirements identified can be accommodated (if possible) or can be parked in Project backlog. However , it is always good to fix some budget for scope creeps.
Do we spend too much time on "good to have " requirements ?
Sometimes developers spends too much time on " Good to have " requirements. But such implementations cannot be mapped to core of Users need. These implementation might not be of great use for Business User but might hit project deadlines. Regular co ordination with team during daily status calls can help identify such instances early. However , such possibilities can be presented to Business stakeholders and take their opinion before we start working on it. This ensures scope of project is properly defined and each requirement can be mapped to its purpose.
Do we identify "Yes" men and "No" men ?
We encounter "Yes" men during different phases of project. As a BA it is very useful if we understand their nature . "Yes" men are friendly during requirement
gathering meetings but behave indifferent during UAT. You should be extra cautious while dealing with "Yes" men and identify the scope creep each friendly "yes" can lead to . While "NO" men might ridicule and create troubles during requirement gathering but it helps us to identify conflicts and gaps during early stage of projects.