Got a problem? I’ll tell you the answer.
I’m sure you’ve worked with people like that – people who jump straight in with a suggestion for fixing something when they haven’t had a chance to fully review the issue. They know the answer instinctively, and they can’t possibly be wrong. There’s no need to go and talk to all those users because what they are suggesting will fix all their problems. Involving users is a waste of time as they already know what has to be done.
An experienced project manager will tell you that while it is tempting to jump in – project managers do like to fix problems, after all – you have to hold back and come up with the requirements before you can properly assess the situation.
People who can do this are hot resources. Team members who can analyze business issues and propose ways to overcome these are going to be in short supply, according to the US Bureau of Labor Statistics (http://www.bls.gov/ooh/business-and-financial/management-analysts.htm). They are predicting that we’ll need over 130,000 more of them by 2022 – a 19% increase. So project managers and business analysts who can see problems, work with their colleagues and get to the bottom of issues are going to be in demand.
It is tempting to jump straight in and suggest the answer but you can’t properly fix a problem unless you know what the solution’s requirements are. Looking at the requirements for the end result will help you come up with a solution that fits everyone’s needs. So how do you do that?
First, hold back! Bite your tongue, don’t jump in. Then you need to elicit those requirements. Here are 5 ways that you can use to get requirements from your business colleagues.
- Workshops
Workshops are probably the most common way of eliciting requirements because they are so flexible. You can carry out some brainstorming, watch a product demo, play with a prototype and make notes as you go.
They also have the benefit of involving a group, and it’s interesting to watch groups at work. One person will come up with a suggestion, someone else will add to it and a third person will chip in with their experience. You get a much richer definition of the requirement than if you had simply asked the first person alone. - Interviews
Sometimes you do need to talk to people one-to-one. This can be the case when they are very senior or when you think you’ll get a better response from them if they aren’t in a group setting. For example, end users might feel inhibited about giving their real opinions if top level management are in the room at the same time. Not everyone is going to bite their tongue in front of their bosses, but you’ll probably have a feeling of how it will be best to approach individuals.
Interviews could also be with two people or a small group. They are more formal than a workshop and it tends to be you asking questions rather than lots of banter and brainstorming as a group. - Focus Groups
Focus groups aren’t that different to workshops but they involve external parties. You might do a focus group with members of your customer base. Say you are launching a new children’s toy, for example. You might get a group of parents together who have children of the right age and ask them for their views on your proposals.
Focus groups are often recorded (audio or video) so the facilitators have a record. You might also have to offer participants some kind of incentive like a gift card. - Surveys
Surveys are a one-way form of asking questions but they can be useful if you are trying to elicit requirements from a large group. You could, for example, set up a survey to ask users what they think is the most important feature to add to your software. The results would help you prioritize requirements. - Observation
Finally, you could observe what is currently going on. Sit with a user and watch how long it takes to complete a process, or what steps are done. You can then assess where the shortfalls are in the process and you’ll probably find they talk to you as you watch, pointing out things they don’t understand or steps they feel are pointless (or conversely, things they would like to have instead).
Once you’ve gathered all the requirements, then it’s the time to start thinking about solutions. Remember that the people who worked with you to elicit and formalize the requirements should also be involved throughout the project to check that what you are building continues to meet their needs. With 80% of project team members in one study (http://www.geneca.com/75-business-executives-anticipate-software-projects-fail/) reporting that they spend at least half their time on rework you can see why spending time upfront and then working together throughout the project is essential for a smooth project. However, it can be hard to get it right exactly at the beginning, so if you involve the decision makers as you go you’ll find they will tell you more about how the product fits their needs and you can make changes accordingly. That’s cheaper, faster and more successful for everyone.
