How to Complete a Feasibility Study

5 Ways to Gather Project Requirements

27 June, 2013

All projects start with requirements – after all, you have to know what it is you are about to deliver before you can start work. But how do you get those requirements? You may be lucky and find that you are asked to work on a project where the requirements are already clearly defined. Perhaps the business needs make the requirements really straightforward, or perhaps a business analyst has already gathered them and prepared the project scope information.

On the other hand, you may be handed a vague brief and asked to finalize the project scope yourself. In that case, you will have to work with all the key stakeholders to identify the important elements of project scope and prepare the project requirements. You can do this with your team members as they will probably have their own ideas of what needs to be included in the scope of the project. However you go about it, you need some techniques in order to be able to capture everything, so here’s 5 ways to gather project requirements.

1. Interviews

One of the easiest ways to gather project requirementsis to arrange one-to-one interviews with the major stakeholders. You can take as much time as you need to sit with them and work out exactly what it is that they are after from the project. Have a list of standard questions but be prepared to be flexible as you may find that the discussion strays away from your list and on to other related subjects. This is good, as it shows that the stakeholder has a clear idea of what they want. However, it is worth setting expectations in interviews like these, as if you don’t you could leave your interviewee thinking that they will get everything they asked for, which is unlikely to be the case!

The downside of interviews is that they can be quite time consuming. They also have the disadvantage of more admin work for you as you will need to collate all the interview output into one single document once you have completed all your interviews. You may also find that you uncover competing or conflicting priorities, which can be difficult to manage. The consolidation exercise at the end of a round of interviews can be as absorbing as the interviews themselves.

2. Focus Groups

A focus group is where you get a core group of stakeholders together. Focus groups are traditionally used with customers, so you could invite the end users of your product to a session to discuss how they see themselves using it. This works well when you have a tangible product such as a piece of software or an item, especially if you can show them a mock up during the session.

Despite the name, focus groups can be a bit unfocused, so think carefully about what you want to get out of the session. If you can come up with a list of structured questions and you facilitate the group well, the focus group format can be very beneficial in working out how customers want to interact with your product and therefore in getting some decent requirements out of the time.

3. Workshops

A workshop is similar to a focus group, althoughthey typically have more people and are internally-focused. You might invite a customer representative, such as someone from Customer Service or Sales, but generally you wouldn’t have end users present. Workshops are highly interactive, so you can use all your facilitation techniques to help people think about what they want from your project. This could include brainstorming, working in small groups and reporting back, thinking about ‘what if?’ and any other techniques you can think of to make sure that you use the time to get the most comprehensive list of requirements possible.

As this is an internal group and hopefully you have invited people with decision making authority, you can also use the time to prioritize the requirements that have been identified. If you can get the group to a point of consensus on what should be in scope and what is just a nice to have, then you will have made excellent progress on defining the project requirements.

4. Over the Phone

It is possible to talk to your key project stakeholders over the phone, either individually or on a conference call. This is one more way to gather requirements but frankly it is better for checking understanding and getting final agreement than it is for brainstorming. It is much better to talk about requirements when you are all in the same room as this aids understanding. Conference calls can be a very frustrating place for discussing new things and without the ability to jump up and draw something on a flip chart it can be difficult to get your point across. It can also be tricky to facilitate the call effectively so that everyone has equal time to speak, and that is easier to do in a face-to-face setting.

Avoid conference calls if you can, but if you need to use them to check understanding later, try to use them sparingly.

5. Using Collaboration Software

Collaboration software is a lot better than conference calls

Collaboration software

for eliciting requirements, but not quite as good as meeting up face-to-face. The good thing about collaboration software is that you can capture the output electronically as you go. You could even record the whole meeting and make it available for others to playback later.

An alternative way to use the collaboration features of software is to have your software open in the meeting and use it to capture the discussion in real time. This will save you an admin overhead later as you don’t have to prepare minutes, and it means that everyone will be able to log in and see the output directly after the meeting. When you have a finalized requirements document, you can also upload that to your collaboration software and everyone will be able to comment on it until final agreement on the project scope is reached.

Capturing requirements can be a challenge, and the most practical way to go about it is to use a combination of these methods. Then write up all the requirements that have been identified as a list, and work with your stakeholders again to prioritize them. Most of the time you will find that you have been asked to consider far more requirements than is practical to include, so something will have to be dropped out. Getting consensus on what to leave out is probably the hardest thing of all, so ask your sponsor to help arbitrate if discussions get difficult! You can also suggest running a Phase 2 of your project if there are enough sensible requirements to warrant it.