This past summer, I had the pleasure of working with a great internship team comprised of Master’s students from a few of our local universities. One of our interns filled the business analyst/product owner role. It was his first time working with a development team, and his first time speaking with stakeholders.
During my time with this intern, I realized that while there is a lot of information available when it comes to writing requirements, there is less available to a person who just wants to know how to start gathering.
What are you supposed to write, and how do you get it?
Let’s start by quickly discussing the term “requirements” and figuring out what you’re trying to gather.
Why, Who, What, Where, When, How.
Why: I put this first, because nobody should work on anything without knowing why it is necessary. A good rule of thumb is to go five-deep in your asking of “why”. We need to convey more than a surface explanation here, and this method will help you to identify the problem you are solving. (Or the “opportunity” you are seeking to fulfill, to put a more positive spin on this.)
Example: “We need an online address book, accessible to customers.”
Maybe in the case of our example above, you will find that the problem here isn’t necessarily the address book. The problem is that our checkout process is too long in general, hurting conversion rates.
The “why” of this task is to improve conversion rates during checkout.
Who: Who will be using your solution is extremely relevant.
Example: In the case above, it’s obviously the customer. But are these returning customers with accounts in our system, or are these new customers who have come to our site for the first time? Are they gift buyers?
Dig around and find out as much as you can about the “who” of this puzzle.
What & Where: These can vary and may be determined later in some cases.
Among this list are constraints – perhaps something previously built for compliance is unmovable but causing strife. In this case, you would be sure to outline the original solution so that the new solution can meet the same compliance need. (There you go – another “why” pops up in the middle of the “what” statement!)
When: When a project will be completed is always going to be relevant to someone.
In some instances, the deadline is not negotiable due to a dependency like a holiday or a season of use (think tax software or insurance opt in dates). In these cases, the “what” will be determined by the amount of time available to build the solution.
Other times, “when” is determined by the size of the solution or other dependent projects in the pipeline.
Deciding when something will happen is often a group decision, and you need to make sure the right people are contributing to this piece.
How: This is often driven off of all of the above criteria and is extremely relevant to the final solution, but will likely not be written into non-technical requirements.
How you build something can often be decided by when you need it. This should be the very last thing that is decided.
My advice is to go for the “why” and the “who” first. If you miss those, then none of the rest will be relevant.
Before you can start writing, you need to gather.
To do this, you need to identify the right people and get as much information from them as you can.
There are some basic behaviors I’ve come to value when gathering requirements:
This can require a lot of personal investment.
You will only become the funnel of information you are supposed to be when people are willing to trust you with that responsibility.
There is a ton of benefit in making people comfortable and earning their trust. When people are comfortable with you, they are more likely to call you up with additional information, they are more likely to give you the time you need to discuss their needs, and they are less likely to seek ways to go around you.
Your stakeholders are the key to everything you do. Building relationships with them should be the first item on your to-do list. Once you have built those relationships, protect and maintain them.
These relationships will be your most valuable asset.
Use time wisely.
Use both your own time and the time of others wisely.
When you are conversing with stakeholders, give them your attention. Take great notes. Later there will be time to comprehensively document what you have learned.
Set meetings with agendas, stick to time boxes, and make every conversation meaningful. Strong facilitation skills are necessary to meet this goal. Don’t let meetings drift. Use this time to get the answers you need.
My advice is to always schedule smaller meetings when possible, because smaller groups are a lot easier to facilitate. There will be times when you need a whole room full of people to weigh in on something, and it becomes necessary to schedule something larger. But on average, I find that 5 or less people in a room increases the productivity of a meeting considerably.
People are more willing to give you their time in the future if they know they can depend on that time to be useful.
Learn their roles. Job titles and org charts can be relevant when it comes to final sign-off of a project or set of requirements. But often you will find that the person who has the best information is someone behind the curtain. Figure out who has the meaty details, and then go talk to them.
Learn how different individuals communicate, and adjust your own communication style to fit their needs. 90% of locating requirements depends on knowing who to talk to and knowing how to get them to answer your questions completely.
Be prepared to be a translator. Five different stakeholders may refer to the same thing five different ways and you have to know that they’re all talking about the same thing. It’s not up to them to be clear – it’s up to you to take what they’re saying and make it clear. That’s your job.
Communicate in person.
Use face to face communication whenever possible. A long walk for a quick question will provide benefits that an email can’t create. You’re building trust, letting people know that you value their participation, and most of all you’re harder to ignore. Emails can slip into oblivion, but a person standing in your office commands immediate attention.
Again, use time wisely. You don’t want to be a dreaded interruption in someone’s day. Ask if they have a moment to talk, use that moment, and let them get back to what they were doing. Always thank them sincerely for their time.
Focus on consistency.
Be consistent in who you are. The response a person gets from you should not be dependent upon your current mood. Let them know that every time they come to you, they can expect to find the same version of you with predictable reactions. Be someone they can depend on without reservation.
Find the right person for the right conversation.
Don’t solution with those who are not solutioners. When it’s a person’s role to define a problem, go to them to explore the problem.
Once the solution has been defined, you can run it past your stakeholders to verify the solution solves the problem, but be cautious about solutioning with the wrong people.
Solutioning with the wrong people can create false expectations, waste time, and create a lot of bad mojo on the project as well as in your relationships with stakeholders. Just be sure that you’re having the right conversations with the right people. Which brings me to the next item on my list:
Do not make promises about specific solutions while you are gathering requirements. Avoid promises of release dates and functionality until those things have been finalized. When you begin to make false promises to your stakeholders, you erode the trust you’ve worked so hard to build.
Do not silo by keeping your work in shadows. You’re gathering requirements, not protecting state secrets. There is no reason for your work to be private, and every reason for it to be seen.
A few reasons to share:
If you’re suddenly unable to return to the office tomorrow, what happens to your work? Put the information you’ve gathered in a place where others can access it and understand it.
You need as many people as possible to see your work so they have the opportunity to weigh in. They may be able to identify similar problems that can be solved simultaneously or share insights that your other sources could not provide. Seeing what you have gathered may cause them to remember something they forgot to mention. Or maybe they will see where you’ve explained something in a way that only you understand, and it’s helpful to get that feedback as soon as possible.
Visibility is our friend.
Share your work.
Accept feedback gracefully.
You don’t need to be a perfect stand-alone requirements creator.
Unless you’re writing requirements for yourself alone, it’s important that your requirements are clearly understood by others.
Most of the time, you’ll be creating requirements that must be digestible to an entire team. (Sometimes many different teams.) If you don’t get feedback, then how do you know you’re succeeding?
When you get feedback, listen.
It’s okay to question feedback. Remember to always ask “why”. I understand that not all feedback is equally valuable. But if you aren’t open to listening, you won’t get those pearly nuggets of wisdom when they become available to you.
In this role, you will need to be an advocate for your customer, for your stakeholders, for your development team, and for your company.
When the needs of those groups are misaligned, you may need to do some digging to find out why.
The best of the best are also ambassadors, bridging the worlds of customer need and technical detail.
As you can see, there’s a lot more to requirements gathering than sitting at a desk shooting out emails or filling in blanks of formatted documents all day.
Every project and every conversation is a learning opportunity. When you get discouraged, remember that even the most seasoned requirements gatherer is still learning. The best of us embrace every opportunity for improvement as it comes our way.