Collect Requirements

Most project team members like to follow the Nike creed – Just Do It! The client has a business need and the team immediately wants to move into problem solving mode. There is no better feeling than completing the solution and showing the client. Until, of course, the client informs you that this is not quite what he or she had in mind.

Resist the urge to jump in head first! Before you start executing you have to make sure you understand what you are doing. This requires an upfront process to define the project requirements. The project requirements help you understand the objectives, deliverables, scope and other project-related information. You should also uncover some preliminary and high-level information about the project deliverables. These are the product requirements. You are not going to have the time to complete the detailed product requirements but you should understand these at a high-level. This high-level knowledge will help you better establish a work breakdown structure, and it will help you better understand estimated effort, cost and duration.

The Elicitation step is where the high-level requirements are first gathered from the client. To elicit accurate requirements, the project manager must ask the right kind of questions and then listen carefully to the answers. When you say that you are going to gather requirements from your client, the first thought that comes to mind is that that you will ask questions and document the answers.

In fact, gathering requirements through an interview process is probably the most common technique. However, there are many techniques for gathering requirements, and in many projects the team will need to utilize a number of them instead of, or in addition to, interviewing. For instance, if you want to gather input from 100 users, you probably will not be able to talk to each one of them independently. In fact, if you did, you would find that you are not receiving very much information after you have finished the first couple. A better, faster and cheaper approach might be to interview a small number of people in this group and then send surveys to the rest.

There are a number of techniques for eliciting requirements, and your project may need to use multiple techniques depending on the circumstances.

  • One-on-one interviews. The most common technique for gathering requirements is to sit down with the clients and ask them what they need. The discussion should be planned out ahead of time based on the type of requirements you are looking for.
  • Group interviews. These are similar to the one-on-one interview except that there is more than one person being interviewed. Group interviews require more preparation and more formality to get the information you want from all the participants. You can uncover a richer set of requirements in a shorter period of time if you can keep the group focused.
  • Facilitated sessions. In a facilitated session, you bring a larger group together for a common purpose. In this case, you are trying to gather a set of common requirements from the group in a faster manner than if you were to interview each of them separately.
  • JAD sessions. Joint Application Development (JAD) sessions are similar to general facilitated sessions. However, the group typically stays in the session until the session objectives are completed. In this case, the participants would stay in session until a complete set of requirements is documented and agree to.
  • Questionnaires. These are much more informal, and they are good tools to gather requirements from stakeholders in remote locations or those that will have only minor input into the overall requirements. A questionnaire can also be a valuable way to gather quick statistics, such as the number of people who would use certain features, or to get a sense for the relative priority of requirements.
  • Prototyping. Prototyping is a relatively modern technique for gathering requirements. In this approach, you gather preliminary requirements that you use to build an initial version of the solution – a prototype. You show this to the client, who then gives you additional requirements. You change the application and cycle around with the client again. This repetitive process continues until the product meets the critical mass of business needs, or for an agreed number of iterations.
  • Following people around. This is especially helpful when gathering information on current processes. You may find, for instance, that some people have their work routine down to such a habit that they have a hard time explaining what they do or why. You may need to watch them perform their job before you can understand the entire picture. In some cases, you might also like to participate in the actual work process to get a hands-on feel for how the business function works today.

Knowing your audience will help you determine the right techniques to utilize to best meet your needs. You should select techniques that get you the most relative information and are best suited for the audience.


Discover more from CMGuide

Subscribe now to keep reading and get access to the full archive.

Continue Reading

Scroll to Top