If you’re looking for guidance on how to start gathering requirements for a project, look no further! This quick to-do list/help guide can assist you in your Business Analyst journey – no matter how your company functions or the status of your project.
TL;DR
If you’re unsure of where to start gathering requirements for a project, start with the ‘what,’ ‘why,’ and ‘how.’ Be sure to ask a lot of questions to project managers, developers, and other stake holders. Confirm your understandings with everyone involved, write out requirements in whatever form your company prefers, and pass off the project to your developers!
Introduction
Over my career, I’ve learned a thing or two about working with project managers, developers, stakeholders, scope creep-ers, User Experience (UX) designers, Quality Assurance (QA) engineers, etc. While every place seems to treat business analysis a little different, there are steps you can take to know you’re handing off a fully defined project to your developers. While this is certainly not the source of truth, it can help provide some guidance when you’re unsure where to start or where to go next.
Define the Project
You’re here if you’ve been assigned a new project (WOOHOO)! Regardless of whether this project is big or small, it needs to be defined. What does this mean, exactly? Well, you could be asked “Make this screen better.” That doesn’t really help, does it? A Business Analyst needs to know the what, why, and how before they can get going on a project.
What
Most simply, what is the end goal of this project?
Why
There can be a lot of noise happening when enhancements are requested – something to remember is the why. If this is going to take 2 weeks of development, and help only one person save one click – that doesn’t seem necessary. Make sure you are discussing the ‘why’ with managers and developers to fully understand the impact and work associated with a project.
How
This is how you reach the end goal – the “how you make this screen function better.” This will take some back and forth with managers and stakeholders to ensure the project is performing the ‘how’ in a way that makes the most sense - based off of available resources and the established end goal.
Establish Your Contacts
This is to help you! Work with your project managers to understand who you will be reaching out to for any questions, discuss gaps in the project, provide updates to, etc.
Establish knowns/unknowns
This comes back to defining the project: Once you have an understanding of the end goal, you’ll want to define what you know about the project and what is still ambiguous. Review any current documentation in depth with your project managers, stakeholders, developers, and (if possible) any UX designers.
Write out Requirements
After you have defined the project, hashed out any unknowns, and established your contacts, write out your requirements in whatever form your company uses. As you go through the document, you may find you have more questions and need to go back to your contacts. This is something you may also want to write as you go down your list. There is no “one way” to do things, so find whatever method works best for you!
This is also where - if it’s part of your department’s process - you would write out any user stories. These could be in the form of tickets, or in an Excel file that’s passed off to a story writer, or your project manager, developer, etc. Depending on your release structure, these could be broken out in a number of ways. If you have short sprint cycles, then your user stories would need to be pretty small – IE development hours would need to make sense. If you have longer sprint cycles, then you can make the stories a little more robust.
Discuss with Stakeholders and Developers
Before passing off your requirements and stories, go back to your stakeholders one last time to discuss what you have gathered. It’s possible they’ve thought of something new, or a piece was lost in translation, or they’ve changed their mind entirely (hopefully this is not the case). This is the last chance for any ‘scope creepers’ to expose themselves and add on any additional requirements, or establish what the first enhancement will be. This is also where a developer might ask that a user story be broken out into multiple stories, or could even ask for some to be combined. Add any additional information to the stories/requirements as needed to ensure the final product is what everyone has discussed.
Be sure to get the “go ahead” from everyone involved so you know you’ve covered all your bases. There should (hopefully) be no surprised faces from stakeholders when the project goes live. Document this approval to proceed and by whom to support your potential stance against scope creepers.
Pass Off the Project
At this point, the project goes to whoever will be working on it! You might get questions and the project might shift a little bit, but that can be handled as needed while working with your contacts. Document when it was passed off and to whom.
Things to remember as you go:
ASK QUESTIONS!
Do not forget to ask questions! Mention any concerns you may have, don’t be afraid to be annoying, naïve, or persistent with the amount of question asking. You and any stakeholders will be happy to have hashed out any potential issues early on. Do what you need to do, ask that question.
DOCUMENT EVERYTHING!
Take as many thorough notes as you can along the way. Having in-depth notes to reference will be a life savior. Timestamps and approval documentation will save you during a crisis.
Closing Thoughts
It can be difficult to know where to start with a project. Keep these simple suggestions in mind as you go, and know that you can always ask questions. Although Business Analysis might look a little different depending on the company, there is always one common denominator – Requirements need to be gathered to fully understand a project. Go forth, and gather those requirements!
