5 Steps to Prevent that Overwhelmed Feeling

There are numerous reasons to get overwhelmed as a Business Analyst in a project. The requirements aren’t shaping up; there is no vision for the product and the solution design isn’t complete. As a Technical BA, you are anxious about starting.

And so it continues…

In a utopian world, everyone is on the same page, stakeholders have their vision organized, and all a BA has to do is, understand it, articulate it and help deliver it.

Easy-peasy!!! If only this were true in the real world.

On certain projects, I have felt overwhelmed and at a loss on simply where to start and what are the milestones we are planning to achieve. At times, it feels the project will never start or worse, it will never end. Also, after discussing this with fellow BA’s I have concluded: I am not the only one.

Captured here are the 5 mantras I now follow, and they have helped me secure my footing in the world of projects:

1. “Converse and Collaborate”: I believe it is one of the core requirements of being a BA. It is the crux of what we do. It is critical to make a start, to gather and collate information, to facilitate, to start making sense. First and foremost start talking to the entire spectrum of stakeholders: business, end-users, architects, implementers, testers, security. Even if the dots don’t connect, keep these conversations and collaborations flowing. These conversations need to be frequent at the start of the project and then they can be scheduled as required. Yes, a BA needs to have the conversations with the stakeholders but equally important is all the stakeholders coming together and brainstorming. Get your business and users together to brainstorm requirements, understand what they need, what is the vision, what end user problem are they trying to solve with this requirement. Once that is underway, get the technical team in workshops, either you can be the product owner or have someone from business play the role. Again, these workshops should be conducted as often as it is required for the design to start taking shape.
2. “Break it down and Bring it together”: Even if the information is not lining up and seems absolutely haphazard, record it. If there is no structure at the beginning, don’t fret. It will start taking shape. The roadmap will start showing itself through these conversations and information. Different categories will emerge out of the information, which at the beginning may seem random. Break down your requirements into manageable/understandable pieces of work. In an agile world, you start splitting them into epics. Categorize the pieces based on a theme. The theme in turn, can be based on a roadmap, milestone, functionality, menu of the application, the infrastructure it lives on, so on and so forth. When you pick up a bite sized piece of requirement, analyse it with developers, quality, performance testers, security architects, operations and DevOps. It doesn’t have to be a detailed design at this point. But the various perspectives will start shedding light on the details, unknowns and the risks. This will start bringing the variables on a requirement together.
3. “Step in and Step back”: Facilitating conversations is imperative. Have an agenda and communicate the same before you bring the stakeholders together. As a Business Analyst, step in to ensure the conversations are flowing in a way to achieve the expected outcome of the meeting. At times, the conversation drifts towards a topic/constraint/feature that no one anticipated. Let it continue. These inputs uncover a can of worms that was not thought about originally. It adds a different dimension to the requirement that needs more work. Stepping back during technical conversations allows the team to brainstorm solutions, uncover unanticipated blockers or just a different approach to achieve the solution.
4. “Revisit and Revise”: The requirements have started to make sense but the requirements might change; technically the requirement might not be doable, you might run into licensing issues, a feature might take longer than anticipated, third party constraints might pop up, a functionality would now be considered “good to have” instead of “must have”. Revisit your epics/roadmap and adjust.
5. “Validate and Verify”: You don’t want the technical teams to be designing a beautiful solution that doesn’t solve the given problem. Keep validating your requirements, keep verifying the solution. Acceptance criteria, the definition of done and test strategy at the beginning of the SDLC will help in achieving the right goals efficiently. These need to be continuously validated by the business. The product owner or the business from where the requirements originate need to be kept in the loop. I strongly advocate for the business to be involved during the development lifecycle. Issues or changes can be caught before they become critical or un-manageable.

---

---

Every Business Analyst has her/his own strategy that works. These steps have been my go to when I feel overwhelmed. Whether it is a small requirement or a program of work, I take one step at a time and the progress comes with it.

What is your strategy?