Gathering Requirements
Projects have a tendency to grow in scope, and if not controlled, scope will eventually grow out of control. Uncontrolled growth of scope is a basic definition of Scope Creep, and Scope creep is one of the scariest two-word combinations in project management.
Scope creep happens due to several factors:
- Unforeseen circumstances
- Weak or non-existent change control
- Multiple client requests
- Inadequate planning
- Poorly defined requirements
This is the first part of the series of articles about requirements.
I will be looking at where it all begins — Gathering Requirements.
What is a requirement, and how do requirements differ from deliverables and scope?
Project Management Institute (PMI) defines a requirement as a capability that a product must meet to satisfy a user’s need to solve a problem. Requirements can be created because of legal need, to meet a particular standard or even a personal preference. The important part is to understand the reason behind every requirement you have.
Deliverables are the tangible objects that need to be created to meet the requirements, where the scope is all the work that needs to be done to obtain deliverables. As you can see, requirements is where it all starts, and gathering requirements is crucial for the project’s success.
Scope, deliverables and requirements are all interconnected and flow into each other. Think of this as a river system. Each river is fed by a smaller creek or a glacier and eventually flows into the lake.
Creeks are your requirements.
Rivers — your deliverables.
Lakes are the vastness of your scope.
You can control how much water is in your lake (the scope) by controlling how much water is going into the basin from the creeks (requirements), but you need to know the locations of each creek to put a dam on it.
In a sense, you are a surveyor of the project landscape. You need to find all the creeks that flow into the lake. Otherwise, if something is missing, the water level of your lake will be higher than you expect, and that can lead to a tragedy. Similarly, uncontrolled requirements and deliverables will lead to scope creep.
You need to control your requirements and to gather the requirements, you need to identify the stakeholders who will provide your requirements.
Stakeholders
You need to identify every entity that can impact or be impacted by your project. Create a stakeholder register and cast your net as wide as you can. The more stakeholders you identify, the better you will be prepared.
The list should include your sponsor, final users, people who maintain your deliverables, people who are against and in support of your project. The list may get quite large, but eventually, you will distill it to the final slimmer version.
Once you start identifying your stakeholders, you can begin contacting them to ask for their requirements. The last question I like to ask is, “Who else should I talk to about this project?”. This simple question saved me many times. I got new leads for stakeholders, and I avoided being surprised by an influential group that I never considered during my project planning.
Gathering Requirements:
You have your stakeholder list started; now it is time to gather the requirements. There are several techniques for identifying requirements for your project. Each method has its advantages, disadvantages and specific times when you can apply them. You will need to use your discretion and experience to utilize these techniques fully.
1. Interview
This is the simplest way to understand your stakeholders’ needs. You can do it face-to-face, over the phone or via FaceTime. In some cases, you can even do it over email or chat. It depends on the stakeholders’ preferences and comfort levels. Remember that you will need to do a lot of follow-up and clarifying questions.
To properly ask open-ended questions, you need to employ active listening. You need to ask follow-up questions, and you need to listen to understand. Do not bring up other requirements and how they may conflict, or do not question if requirements are reasonable. Conflict resolution and the ability to deliver come later. During an interview, you need to gather as much information as needed.
You need to figure out which items are a Must, which things Should be included, which things Could be included if possible and which things Won’t be included.
Must — Should — Could — Won’t
Things that Must be included are usually stipulated by regulations. They include safety, standards, regulations, legal, etc. You can’t do anything about it; without these items, your project will not be successful.
Things that Should be included are highly desirable items that will make this project successful for this particular stakeholder. You need to try to include as many of the Shoulds in your list of deliverables as possible.
Things that Could be included are the cherry on the top. If there is an opportunity to have them, it will be a bonus, but they are optional for the overall success of the project.
Things that Won’t be included are just as important as things that Should be included. These items are your boundaries, and setting your boundaries is how you keep your scope from creeping up. You should never forget about the things that your stakeholder doesn’t want to see. And don’t forget to ask why that is.
When conducting an interview, you will need to come prepared. Get a list of open-ended questions that relate to your project. You can even submit that list in advance, to let your stakeholder gather the required information. Each question should end with “and Why?” or “provide a reason for your statement”. An interview is the best way to understand why certain things are needed.
Five Questions Why
One of my favourite techniques is — Five Questions Why. You can see me do a quick demonstration of this technique during Crafter Con.
The premise is quite simple. You need to channel your best four-year-old and keep asking questions ‘Why?’ until your interviewee can’t handle it anymore. On average, it takes five questions. In some cases, you may need to go deeper; in others, just one is enough. For example, if it is a safety, legal, standard or any other regulated requirement that you have to follow. Requirements that are based on personal preference or need usually need deeper exploration.
Pros:
- Universal and can be used at any time
- Detailed
- It gives the best understanding
Cons:
- Time-consuming
2. Focus Groups
This technique can be used when you need to understand the needs of your target audience. Usually, there are things that the group can compare, evaluate and discuss.
Just like in the interview, you must come prepared for the meeting. However, you rarely send anything in advance to your focus group. You need to bring work samples, a list of preliminary requirements, possible ideas, etc.
It is usually more challenging to work with the group and to keep the conversation flowing and productive. Being prepared helps, and you may need a couple of people to manage the group. One person maintains the conversation while the helper records the findings.
Just like in the interview, you will need to consider Must — Should — Could — Won’t items and understand the reason why. But unlike the interview, you should be mindful that every member of the group contributes and that all ideas are considered. Discourage striking down of ideas, and keep asking those questions why.
Pros:
- Diverse perspectives
- Still can understand the reasons behind each selection
- Cost-effective
Cons:
- Time-consuming
- Subject to bias and groupthink
- Can be limited and not aware of the bigger picture
3. Questionnaire
Nothing beats a questionnaire when you need to ask a big group of people the same questions. This technique can be used to gather requirements, but I find it more useful when refining a list to something more manageable.
I like to use questionnaires with a large group of end-users or people who may not have a strong impact on the project but will be affected by the project (think about recreation facility users or end-users for the application or software that needs to be designed or the buyers of the product). Understanding the needs of the end-users will dictate the overall project success.
You need to have a combination of multiple-choice, short and long response questions. It takes time to create a good questionnaire that will meet your needs and gather the right information.
You still need to cover Must — Should — Could — Won’t items and understand the reason why. Be prepared that you may not have as good of an understanding of the reasons behind the answers.
You will also need to gather biometrics and other statistics from all participants. This will help you better analyze your responses.
Being able to analyze responses is a skill, and there are companies that specialize in creating questionnaires and analysis. I highly suggest using professionals, especially if you want to receive usable data.
Pros:
- Cost-effective
- Can gather vast amounts of information quickly
Cons:
- Hard to understand reasons behind responses
- Limited ability to follow up
- Need professional help to get the best out of the questionnaire
As you noticed, it all comes down to answering questions. Think of the multitude of ways you can ask questions, and that is the way you will gather requirements.
Here you have it: you interviewed people and ran focus groups and questionnaires. Now, what do we do with all that data?
You will need to analyze it for conflicts, you will need to classify requirements, and you will need to prioritize everything.
I like to keep these articles bite-sized, and I will cover the tools and techniques I like to use for requirement analysis in the next article.
Stay tuned and ask five questions ‘Why?’