Short Discussion (250 words)
h66umi6q
WhatTheHeckAreWeBuilding.pdf
What The Heck Are We Building? 10 Steps To Successful Requirements Gathering
By Jordan Hirsch (posted on Phase 2 Technology web site November 21, 2013) There’s a common refrain that gets uttered at the end of unsuccessful projects: “The requirements weren’t clear.” Fingers start pointing, blame gets thrown around, and no one ends up happy. Thankfully, there’s a simple way to alleviate that problem, and it’s as obvious as it is challenging: requirements gathering. Depending on your project methodology, you may do this step at the beginning during a Discovery phase, you may do it during the project within each sprint or build cycle, or you may skip it altogether and hope for the best. That last option is a simple way to sabotage your project and guarantee a lot of late nights and awkward status meetings.
This doesn’t have to be you!
Successful requirements gathering is both an art and a science, but there are some general steps you can take to keep this all-‐important step of your project on the right path. Here are some guidelines that we try to follow at Phase2:
1. Establish Goals & Objectives Early This step can feel redundant: of course we know why we’re doing this project…don’t we? Even if you think you know, write it down, and get your client to sign off on it. Without clearly stated goals and objectives, you are lacking a framework to guide future decision-‐making. How do you know if a newly introduced requirement actually fits in your project? Simple: does it help accomplish a goal, or does it satisfy an objective? If so, it’s probably a good fit. If not, it’s a good candidate for a future release.
2. Write It Down When you’re in the midst of stakeholder interviews and document review, you can often feel like you have a great grasp on things. But then a week goes by, and some details start to get a little fuzzy, and you realize you don’t quite have a full grasp of X, Y, or Z. It sounds obvious, but making sure that you are taking detailed notes during your stakeholder interviews is a powerful step in successful requirements gathering. And it’s not enough to just write everything down, as you’ll see in #3…
3. Be Transparent Sure, you understand the requirements. And your client understands the requirements. But does your client understand your understanding of the requirements? After every meeting, go through your notes and clean them up – then share them with the project team, including the client. This transparency not only helps make sure everyone’s on the same page, it fosters a sense of project buy-‐in all the way through your project, beginning with the requirements. And it circumvents the issue of someone saying “hey, you agreed to X but it’s not here!” 6 weeks into the project. If it’s not in the notes, it didn’t happen.
4. Talk To the Right People A project can often have “hidden” stakeholders. Ask probing questions in your kickoff and initial meetings with your client to try and get to who the real users are – often those people are not going to be the main decision-‐makers, but their buy-‐in is essential to a successful project. Disgruntled users who are forced to use a system every day that was designed without their input are a key ingredient for a failed project.
5. Get Detailed Don’t assume that you understand everything, even if it seems obvious. A seemingly simple requirement such as “we want a blog” can mask all sorts of underlying assumptions, requirements, etc. What are the fields for a blog post? How are authors managed? What about tagging? Categories? How are the posts displayed? Are they aggregated into an archive? Is there an RSS feed? Who are the authors and what is their level of technical proficiency? Etc. etc. etc. The devil truly is in the details, but you can catch him by the tail if you ask a lot of questions and don’t rely on assumptions.
6. Confirm, Confirm, Confirm This ties into “be transparent” but is not entirely the same thing. Just sharing your notes with a client is great, but far more valuable is actually having a quick review with them and getting their official sign-‐off. This is true for meeting notes, user stories, diagrams, wireframes, really any kind of requirements artifact that you are creating. Radio silence is not an indicator of success – get actual confirmation from your client that you are representing the requirements correctly in whatever format you’re using, then move on.
7. Be An Active Listener Making someone feel heard is one of the greatest things you can do for them. But it goes beyond just listening to what they say – you also need to listen to what they don’t say, and how they say things, and read their body language, etc. This is called “active listening” and it’s a key component both of successful requirements gathering and improvised comedy, among other things. Don’t assume that you’re always getting the whole story – listen for little cues that reveal pain points, desires, unstated goals, and assumptions.
8. Focus On Requirements, Not Tools Be careful when you are gathering requirements that you are really focusing on and listening to what your client needs, not what your tool-‐of-‐choice happens to do best. Even if you know you are going to be using a certain product, you need to adapt the product to the user, not the other way around. Listen and gather first, then determine where the gaps are between your client’s needs and any existing product you may have in mind. Remember: requirements are about the WHAT, not the HOW.
9. Prioritize In an agile methodology, we work towards a Minimum Viable Product (MVP), which encapsulates the least amount of functionality that would count as a successful product at launch. Even when following a non-‐agile methodology, prioritizing is your friend when you are gathering requirements. It’s easy for requirements gathering sessions to turn into wishlist gathering sessions, where stakeholders tell Santa (i.e. you) everything they want. The point isn’t to ignore that information (in fact it often reveals goals and assumptions if you’re using Active Listening) but rather to clearly and transparently prioritize what you’re hearing and delineating what is in scope for your initial launch and what is not. You definitely want to track wish-‐list items, “nice-‐to-‐haves,” etc. but prioritizing helps you focus your efforts and helps you make decisions if time gets short and something has to go.
10. Remember That You Didn’t Get Everything Even the best requirements gatherer is going to miss things. Why? Because you and your clients are human beings, and human beings make mistakes. You will think of things later that you forgot to ask. Your client will think of things that they forgot to mention. Things will change. Priorities will shift. The good news is that if you plan ahead for this, you can build in time during your project lifecycle for ongoing requirements management. This time is essential because requirements
(being human-‐driven and human-‐created) are simply not static. Giving yourself time to actively manage requirements throughout the entire project can help you stop scope creep before it starts, and make sure that your team is always focusing on the right set of priorities that match actual requirements. There’s obviously a lot more that can be said about the art and science of requirements gathering, but hopefully this list has given you some helpful tools to manage this process successfully. If you are the client on the other side of this requirements process, check out Nate Parsons’ blog post “How to own a boat or… How to maximize the ROI on your expensive new website” to learn about the questions that your team should ask while gathering requirements for your new site. Good luck out there!
