The Top 8 Mistakes in Requirements Elicitation
Whether you are an Enterprise Business Analyst, Enterprise/Business Architect, Business Intelligence Analyst, Data Analyst, Process Improvement Analyst, Agile BA Team Member or IT Business Analyst, you work to bring about change within the organization. Sometimes these are small incremental changes, and sometimes these are big changes that require an organizational shift or cultural change. Whether small or large, most of those business analysis roles deal with gathering requirements. One of the key activities of a Business Analyst is to draw out and document business change requirements from stakeholders throughout the organization. As the International Institute of Business Analysis (IIBA®) celebrates their 10th anniversary this year, we are reminded that business analysis as a profession is still maturing, as is the practice of business analysis in many organizations around the world.
As organizations struggle with maturing their business analysis approaches, let’s take a look at some common mistakes that practitioners commit when eliciting requirements from stakeholders.
1. Improper Stakeholder Analysis
Often times resource managers or the Project Management Office (PMO) assigns resources to projects almost as early as the Project Manager (PM) and Business Analyst (BA) are assigned. With these resources the project marches on and the Business Analyst never does a proper and complete Stakeholder Analysis. Stakeholders can be missed because that early in the project all the lines of business within the organization that are affected may not be known. Perhaps as the project moves on, it takes a turn into a new business line; and if the Business Analyst doesn’t recommend that a representative of that business unit be assigned to the project team, then they are not doing their job. If you have stakeholders from one line of business answering for another line of business, you may not have all the business or functional stakeholders engaged in the project that should be.
One of the first activities that the Business Analyst should complete upon being assigned to a project is a Stakeholder Analysis. This helps ensure that the proper stakeholders are engaged in the project. However, a Stakeholder Analysis is not a one-and-you’re-done thing. It is an activity that should be considered throughout the project’s timeframe, especially when elicitation discussions take a turn into a new business area and there isn’t a representative from that business unit on the project team. This is the time for the Business Analyst to raise the red flag, complete a new Stakeholder Analysis, and recommend new resource(s) be engaged on the project.
2. Improper language in the requirements
Business Analysts that work in very large organizations or with very structured teams, especially Quality Assurance teams, have heard that your requirements have to be well structured and testable. Many Business Analysts have been told that requirements have to be SMART: Specific, Measureable, Attainable, Realizable and Time-bound. I worked in one place that advocated that requirements had to be SMART-CC, adding Complete and Concise to the SMART acronym.
Quality Assurance Teams advocate the SMART test for requirements as they want requirements that they can test. Even though, most of the time, QA teams test the solution against the solution (functional and non-functional) requirements, most Business Analysts will attempt to make their business and stakeholder requirements SMART. A lot of times the BA will fall into the trap of expressing the requirement from the technical viewpoint and in technical terms. So they have taken a requirement for/from the business and applied technical terms or changed the viewpoint of the requirement, which adds ambiguity and confusion for the business stakeholders.
Remember the business requirements and stakeholder requirements are primarily from and for the business stakeholders. Even though the technical team will use those requirements, the business is the main consumer of those requirements. Therefore, they should be expressed in business terms and from the business standpoint. Likewise, the solution requirements have to be SMART for testing purposes. The technical teams are the main consumer of those requirements, so they should be expressed in technical terms.
3. Jumping to design before getting the requirements
I have been in many stakeholder requirements elicitation activities where the stakeholders start talking about design and in which system this solution will be implemented. If the BA doesn’t squash those discussions immediately when they start too early, then they tend to multiply and consume the actual elicitation of requirements. Soon you have a design for a solution before you truly understand the business problem you are trying to solve—before you understand the business need.
This tends to put blinders on the entire project team, and everyone marches down the same path toward a solution because that is the only thing the team can see. Once the solution discussions begin, and are not halted by the BA, it tends to give everybody hearing the discussions a single focus, even though they don’t fully understand the business need. Quite often this leads to alternatives to the“initial solution never getting considered. This also leads into my next two mistakes BAs make during elicitation activities.
4. Not guiding the conversation during elicitation with a group of stakeholders
Even with a small group of stakeholders, even in a one-on-one stakeholder interview, discussions can go off course onto tangents that are not relevant to business needs. Sometimes the conversation can be so far off course that it is not even relevant to the present project. These conversations tend to distract from the task at hand and waste time during requirements discussions. It can cause stakeholders to become frustrated with the process and become disengaged with the project, as they find better use of their time than to continually hear a couple of people dominate the conversation with what they did over the weekend or other irrelevant topics. Another distraction is when there are two or three conversations going on in the room. Of course, all these issues compound as the number of stakeholders in the conversation increases.
Part of the task of the facilitator is to keep the discussion on topic. When the conversation goes off on a tangent, it can be difficult to find the proper time to rope it back in. The sooner the facilitator brings the conversation back on topic, the less likely further discussions will stray off, the less time is lost, and the more engaged your stakeholders stay in the project.
5. Getting approval for the requirements without a shared understanding of them
With today’s tight project schedules, often times the requirements approval process is rushed so much that ensuring that all stakeholders, business and technical, understand the requirements in the same way is difficult. With stakeholders coming from different viewpoints, ensuring that they all understand the requirements is a task in itself. A structured requirements walk-through will go a long way in accomplishing this task. As everyone in the walk-through hears comments from other stakeholders, a common understanding begins to take form. The stakeholders learn how others view the requirements.
6. Feeling requirements must be 100% complete and accurate before sharing with the stakeholders
Novice Business Analysts can fall into the trap of feeling that the requirements that they are documenting must be 100% correct before they share them with anyone. They feel that any corrections or changes to the requirements mean that they did not do their job correctly. So in an effort to make sure they are correct, they go talk to more stakeholders. They make sure to elicit from everybody in the organization. Then before you know it, the project is in analysis paralysis.
BA Managers have to ensure that there are no performance measures on the BA’s evaluation that measure changes to requirements. It is not a good measure of how well the BA did the job of elicitation. The BA themselves have to remember that they are one person and they cannot know everything. Changes to requirements are not any indication of how well the task of elicitation was done. Using a more collaborative approach to requirements elicitation, where the requirements are more visible throughout the process, is a better approach to ensuring the requirements represent what the business actually needs.
7. Not building trust with stakeholders
Often times BAs move from one project to the next, have four projects going on at once, and don’t take the time to get to know new stakeholders that they had not previously worked with. Getting to know the new people who you are working helps you understand their viewpoint and agenda. This will certainly help if conflict arises during elicitation. Understanding each person’s viewpoint will help the BA resolve the conflict by helping each person to understand the other viewpoints in the conversation. The BA cannot accomplish this if they do not understand the viewpoints in question. Taking the time to get to know someone shows them that you value their input and participation in the project.
8. Blindly using a template
I was recently handed a Business Requirements Document (BRD) template that had several categories of requirements including documentation, reliability, scalability and training, among others. All of these categories are non-functional, or solution, requirements—and as I said this was in the BRD template. Recognize the fact that these are solution requirements and do not have any place in the BRD. If you receive a BRD like this, remove these categories or mark “N/A” or “Will be defined during design and included in the Functional Requirements” in each category. If you do the latter, check the Functional Requirements document template to ensure that the category is in that template as well. If not, add it. Don’t blindly use a template just because that is what the organization uses. Don’t try to define solution requirements during business requirements. How do you know what your training needs are if you don’t know what the solution is? BAs are agents of change. Challenge the template and help the decision makers in the organization see the value of a correct template.
To do an effective job at requirements elicitation, avoid these traps that can get your activities off track. Be sure you have everyone in the conversation that should be, define the business need before designing the solution, ensure that there is a shared vision of the requirements, and document the requirements in a collaborative approach with the project team. This will help ensure that you do an effective job at eliciting the requirements for your organization.
So there is my list, what is yours?
Don’t forget to leave your comments below.