Business Analysts : The Truth About What We Really Do

Out of all the embarrassing moments in my life, not knowing the difference between Business Analytics and Business Analysis has to be in the top 3 list. But the one that has my attention, and curiosity is Business Analysis.

I know there are formal definitions of what Business Analysis means. And the first time I can remember seeing the proper explanation was in the International Institute of Business Analysis (IIBA).

With multiple definitions and understandings of the term, “BA” can mean different things to different people. In this blog, I want to explain what we actually do in the wild — which requires a story.

Imagine a small, slightly chaotic kingdom called “Biztopia.” The King (the CEO) has a grand vision: “We shall dominate the online widget market!” He shouts this from the top of his metaphorical castle tower. The people (employees) are excited but mostly confused. They have no idea how to turn this vision into reality, and frankly, half of them are still trying to figure out what a “widget” even is.

Enter the Business Analyst, the kingdom’s tech-savvy translator. She’s the one who can actually understand both the King’s lofty pronouncements and the slightly panicked tech team who are trying to build the darn thing.

Her first task? Figure out what the King really wants. Is it world domination? Maybe just a decent profit margin? What are the business requirements?

Then, she has to talk to the stakeholders. The marketing team wants flashy ads. The sales team wants easy-to-close deals. The customer service team just wants fewer angry calls. And the developers? Well, they just want pizza and a bug-free code. She gathers all these needs, sorts through the noise, and starts crafting a plan.

The plan involves some fancy new tech: a widget-selling website! But what should it look like? What features does it need? That’s the “solution requirements.” What do I want? And the Tech team has the how and what to build.

She doesn’t forget the Transition requirements. She has to transition the solution to the real world.

With clear requirements in hand, she collaborates with the developers, designers, and everyone else, ensuring they all build something that aligns with both the King’s vision and the customer’s needs.

The King is happy, the stakeholders are mostly satisfied, and Biztopia has a shot at dominating the widget market. Because she has made the Business requirements, stakeholder requirements to solution requirements in the real world.

That, in a nutshell, is what a Business Analyst does. We bridge the gap between the business vision and the technical reality, ensuring that technology empowers the business instead of creating a bigger mess. We do that while making the Stakeholders requirements come true.

Okay, so now that we know what we’re all about. Let’s dive a little deeper into how we stay on track with the requirements, and what we do with them. Well, that’s where the beautiful cycle of requirements comes in.

The Circle of BA Life (and Requirements, of Course) :

Let’s get down to brass tacks and talk about the heart of Business Analysis - Requirements. I know, I know, it sounds about as exciting as watching paint dry, but stick with me. It’s a necessary evil, and, when done right, can be… dare I say… almost enjoyable. This visually stunning cycle perfectly encapsulates the continuous loop of requirements gathering and assessment that BAs live and breathe by:

1. Business Requirements: “Why Are We Doing This Again?”

At the top of the circle, we have Business Requirements. This is where we ask the fundamental question: “Why do I want it?”. Think of it as the “meaning of life” for your project.

2. Stakeholder Requirements: “What Do They Need?”

Next, we dive into Stakeholder Requirements: “What are the needs?” This is where we put on our empathy hats and try to figure out what our stakeholders want.

3. Solution Requirements: "Okay, Now What Do We Build?"

Then we move on to Solution Requirements: "What do I want?". This is where the rubber meets the road. Armed with business and stakeholder needs, we define the specific features and functionalities that will solve the problem. It's like designing the perfect Swiss Army knife – versatile, efficient, and hopefully not too complicated.

4. Transition Requirements: “How Do We Not Break Everything in the Process?”

Before launching, there’s the crucial part which is the Transition Requirements: “What are the conditions?” This stage often gets overlooked, but it’s essential. This phase figures out the conditions on when and how the solution will transition to the real world.

In the fast-paced world of startups, where every decision can make or break the business, the role of a Business Analyst becomes crucial. They are the wizards behind the curtain, transforming chaos into clarity and ensuring that innovative ideas don’t just stay as dreams but turn into tangible successes. Let’s dive into some real-world examples where BAs have worked their magic, showcasing how their insights and strategies.

BAs in Startup Environments :

1. E-commerce Startup

• Project: Boost sales with a personalized recommendation engine.
• BA Magic: Analyzed customer data to suggest the right products (hopefully not socks with shoes).
• The Payoff: 20% sales jump! Finally, decent coffee for the team.

2. Fintech Startup

• Project: Create a mobile banking app (because people love banking apps).
• BA Wizardry: Researched user gripes and made sure the app was user-friendly, secure, and legal.
• The Win: 4.5-star rating and 10,000 users in 3 months. More users than people who get crypto!

3. Healthcare Startup

• Project: Creating a telemedicine platform to provide remote consultations.
• BA Contribution: The BA facilitated communication between doctors, patients, and IT teams to define the features and functionalities of the platform. They ensured that the platform complied with HIPAA regulations and integrated seamlessly with existing healthcare systems.
• Outcome: The platform reduced consultation costs by 30% and improved patient access to healthcare services. Finally, a way to see a doctor without sitting in a waiting room for three hours.

Conclusion

In the startup world, the role of the Business Analyst is not just about analyzing data or documenting requirements; it’s about being a strategic partner who drives innovation and helps the company achieve its goals. By understanding the different types of solutions BAs provide, the needs of various user types, and the essential knowledge areas, startups can leverage the power of business analysis to succeed in today’s competitive market. Or at least survive another funding round.

I hope these insights provide a clear understanding of the many facets of Business Analysis in the exciting realm of startups! Let’s continue this discussion — what are your experiences with BAs in startup environments?

And please, share your best war stories. We all need a good laugh (or a good cry) !