The Requirement Gathering Process - Challenges & How to Overcome Them

Soliciting and gathering business requirements is a critical first step for every project. Creating a complete set of requirements up front enables better planning, more accurate cost estimates, shorter delivery cycles, improved customer satisfaction and adoption of the final product. Bridging the gap between business and technical requirements is the main responsibility of business analysts: they must fully understand the business needs within the given context, align these needs with the business objectives, and properly communicate the needs to both the stakeholders and development team. For that, they need to ensure requirements are written in a language that is understandable by both groups. In their position as client advocates, business analysts need to make their way through ambiguous and sometimes conflicting stakeholder views, to arrive at a clear picture of what needs to be accomplished. More often than not, requirements gathering efforts are inhibited by various pitfalls: it is not uncommon for the project stakeholders to disagree, underestimate design and development efforts, or not fully understand the implications of their decisions. In this post, I address some of the more common challenges of the requirement gathering process, and discuss potential approaches for addressing them.

1. Success criteria is not defined clearly

It is normal for stakeholders to know that they have a problem or an opportunity to explore, but not know exactly what they want. The key to addressing this issue is to break the project into smaller pieces, and start from a section that the client is clearer about. Collaborative modeling tools allow for giving the clients a high level vision of the end product, and getting their feedback early on in the process. Also helpful is asking for examples of systems that they like and what they like about them, to better understand their current business process and identify pain points that need to be rectified or improved. In any case, it is important to make requirements quantifiable and testable, in order to have a solid basis for measuring results later.

2. Stakeholders change their minds

This happens time and again. Whether the requirements were not clearly understood or communicated initially or they evolved over the course of the project, change happens. The only approach to this challenge is to be flexible and embrace the change. Changes need to be prioritized and estimated, and new time and budget allocations must be communicated and confirmed with the client before modifications are incorporated.

3. Stakeholders are not willing to speak up or they are being too expressive

This issue is often rooted in political issues within the organization. In some cases, people might be afraid of being pinned down for expressing their ideas. In other cases, the project might be politically important and everyone may want to be associated with it and have a say in how it should work. Active communication and stakeholder participation is key for the success of the requirement gathering process. Getting stakeholders to provide open, honest input requires establishing a foundation of trust and rapport. Preparing for meetings in advance, listening carefully, and learning and speaking the stakeholders language (as opposed to technical jargon) implies interest in understanding the business challenges and being focused on helping solve their problems.

4. Stakeholders imply or insist on a particular technical solution

This issue often arises when stakeholders have limited knowledge in certain technical areas, have had a specific technology work well for them in some past project, or simply are just not able to clearly articulate the actual need they are trying to address. The best approach here is to try to divert stakeholders focus back on defining what the system should do (by asking questions such as “if you had that technology in place, what problem would it solve?”), and leave the decision on how the system will do it to the technical team.

5. Stakeholders have Conflicting priorities

When a new system is created, it must adhere to the needs of several groups of stakeholders, such as end users and senior management. It is possible for these various groups to have conflicting views and priorities. The best approach to this problem is to have a designated authority in the organization who is in charge of negotiating the conflicting matters and makes the final decision. The requirement gathering process requires having tough, open ended questions for the stakeholders to answer. Stakeholders need time to fully articulate their ideas and perspective. Rushing the process may result in proposed terms that are considered out of scope, or promoting individual agendas rather than the organization’s vision. A good practice is to have multiple meetings with enough time between meetings for the stakeholders to digest the outputs, thus ensuring that the requirement gathering process is on the right track.