Join Haydn Thomas for an in-depth discussion in this video On collecting requirements, part of Insights from a Business Analyst.
Collecting requirements is a very big part of the business analyst role. The first thing is, is the number one frustration, is that the project manager does not understand the concept of the level of detail that's needed for organizations to be able to go away and design and construct what it is that they're trying to achieve in the project. So the first thing to do is that the estimation or the effort is always the most misunderstood element of gathering requirements. The second thing is trying to get into people's diaries to try and find time.
People are always busy. Projects are something that happens on top of their day to day activities. So trying to even get in their diary is difficult. So those very basic, high level elements are the starting point. But then when you do get to people, a lot of the times they don't know what they don't know. So when you actually ask them what it is they want, they will always try and throw the solution at you and the problem is, is if people provide the solution too early, it has a really big limiting factor on how you can actually achieve the result or outcome.
So one of the challenges you've got to face is that when people are sharing information with you, you want to really define what it is they're after rather than how. Because, ultimately, if you define [unintelligible] what, there's multiple how's. Where, if you focus on the how, it really limits things. So that's the first thing. The second thing is, is that gathering requirements, you have to use many different techniques. If you just rely on one, it's going to be very difficult to be able to get to a level of detail that may be needed later. Because the role of gathering requirements is taking information from what we call the input people, the key stakeholders that are requesting the change.
We, as a business analyst, then take it and turn it into information, but in the activity of gathering those elements and packaging things up. And we take that package and then provide it to the output people. These are the people that actually create the solutions or develop the solutions that we're looking for. So you can start seeing that, if we don't actually gather the information correctly at the start, as we go through the input, the activity, and the output, we find that the solution at the back end may be limiting the functionality or it may not be really delivering against what people are asking for.
So that's probably some of the key elements of challenges that you find in gathering requirements. And the biggest thing I find is that they're normally what I call, "vanilla answers." People don't go into the level of detail. And I talk a lot about making sure your requirements are SMART. Specific, measurable, achievable, realistic, and traceable. The point being is, they normally follow the first two, specific and measurable. So really when you're trying to gather requirements from your stakeholders, make sure they're as specific as possible. Get them to give you information.
Templates, tools, print outs, whatever it is that you can actually take away and physically see because then that gives you the capability of being able to verify later on, when you can actually verify the data that's provided, the information that's provided, and what's been said. Because, ultimately, you're going to have to take that and create some information to give it to the output people for them to design the outcomes.