Hi again! In our last blog post, What Is a Business Analyst?, we talked about what a Business Analyst (BA) is and how they gather project requirements. If you haven’t checked it out yet, give it a read.
In this post, we'll talk about what to do with those requirements to provide the greatest value to your project teams. We’re going to stay focused on the process in this blog, but stay tuned for the next post in this series which focuses on Requirement Formats and Tools.
Right, so we collected all this data and we have a good idea about what the requirements are for the project, so what we do with all that data? BAs aggregate everything pertinent to the project and package in a way that will be meaningful for all of the project stakeholders. This requires us to analyze the data and results of stakeholder engagement to help identify trends.
Not only do BAs get everything into one place for the project team, e.g. BRD, TRD, etc., they also ensure it’s organized in a way that helps walk through the project. This can be kind of tricky since no project is the same, but use your best judgement. We like to either group things together or organize requirements in line with a user flow. For example, we may group all of the components or elements of a website together, followed by forms and configuration settings; but, for another project, we might document the functional requirements for each part of the site that follows the idea user flow. The good news is, most of the team will trust your judgement on the approach, so don’t get too hung up on the order.
The next step is to finalize the requirements you put together and present them to your stakeholders. We’re super lucky at melt to have such amazing people who are, 1) cross trained and have a good idea what to expect from a BA, and 2) are always interested in helping ensure the project’s success. So for us, it’s easy to do internal requirements review to help fill in any gaps and get the project team aligned. Once we are all in sync, we walk the client and/or stakeholder through the requirements. This usually results in a round or two of revisions, which ensures the client’s alignment with the project before they sign off.
Great, so we have worked out the requirements, the team knows what to do, the client approved so now it’s time to work! So what does a BA do now? If you recall from the first blog, BAs are the voice of the stakeholder. It is important that you support the project team with any questions they may have related to the requirements and what the stakeholder may want. At melt, the BA can even be a Project Manager, or support our PMs for parts of the project that are larger and more technical in nature. Lots of companies have resources that wear multiple hats, so it’s possible that your designer, solutions architect, or someone else may put on this BA hat. In another post, we’ll talk about the different types of BAs and when to incorporate them into your project. This will help if you are trying to work out what role in your organization is a good fit for taking on these tasks.
After the work is done, the BA and other team members can run through the product to make sure it meets the needs of the stakeholders as well as meets all of the requirements. This is usually part of a User Acceptance Testing (UAT) or Quality Assurance (QA) phase. Once handed off to the client, the BA may need to support the stakeholder with questions. For this, it’s helpful to have in depth knowledge of the product or deliverable.
But all work and no play makes Jack a dull boy! The best part about melt is that we celebrate every project. Grab a drink, and join in the fun. You and the team worked hard, take a moment to acknowledge it. While you’re all together, you may as well talk through lesson’s learned. There’s always something we could have done better and we often come up with new processes that work well that we can convert to a recurring practice in the future.