A problem well stated is a problem half solved

A problem well stated is a problem half solved © Charles Kettering

Trying to reduce costs by cutting down the team is probably the most common temptation at the start of building the product:

“Well, should I add a business analyst to my team? Isn’t that an additional cost? Am I not expanding how much this project is going to cost? Why don’t we just get to coding, because that’s what we really need? We need that code, or we need that configured system into our business user’s hands. Why don’t we just skip the analysis and go right to coding?”

All of a sudden, something that seemed simple at first, gets complex as stakeholder requests, defects, and change requests come in, and you have this re-work where you’re going back and reviewing the same code, making the same implementation again, and again, and again.

Well, we know it doesn’t always work that way, but some specific ways that business analysts help reduce costs, even though, of course, their salary is a line item on the budget for the project. But this will result in reducing re-work and unavoidable costs caused by this re-work

So I’d love to talk about how a business analyst could create a better return on investment (ROI) when assigned to building a new software product.

1. Running effective meetings

I’m not going to use the standard tips “Create an Agenda” or “Prepare Deliverables” quote, I’m sure you’re thoroughly sick of it.

Creating a successful new venture is not easy. There are many pitfalls and risks involved, from funding to technology. But the biggest challenge is building something customers will love.

The casualties of the wrong meeting process could be such nuances as causality, anxieties, and motivations which you have to understand when creating great products.

Philosophy of focusing on these items is called Jobs To Be Done (JTBD), and a granular way to bring this concept into a product is to use Job Stories to design features, UI, and UX.

A good business analyst always helps stakeholders and development team recognize users’ pain and be close to JTBD principles through the development process.

2. Describing and prioritizing requirements

When you are trying to figure out what problem actually needs to be solved before you dive deep into the software requirements, you’ll want to analyze the business process. And to do that, you create a visual and a textual business process model.

First, it’s not surprising that correct, clear and complete software requirements specifications (SRS) are the key to the successful development of products in the IT industry.

Second, the stage of analyzing, reviewing and verifying specification by project’s members and stakeholders before their implementation is so important that its significance cannot be overstated.

In my opinion, the decision to use BPMN (Business Process Modeling Notations) in addition to the Requirements Documentation (Use Cases, User Stories, SRS, etc. depends on general methodology) in these cases is a really powerful choice.

The goal should never be to use as many different symbols as you can. The goal is to show the correct execution of the process by using the right symbols to help the stakeholders and the development team have a clear visual representation of what is happening in the simplest possible way.

If you use the following criteria it will go a long way in alleviating some of those complexities:

1. Limit the number of symbols you use

2. Review your diagrams with stakeholders and development team instead of just sending it to them to review on their own

3. Include a legend that explains the symbols

3. Helping find more cost-effective solutions

When it comes to the investment side of the equation, the other way that business analysts can help is finding more cost-effective solutions. When you dive into the problem we are solving — you’ll hear me say that again and again — what problem are we solving? Why is this feature implemented in the first place? Sometimes creative solutions just pop up:)

They don’t even have to be big technology solutions. Maybe there are tools that you already have and you can use them. Maybe there’s a business process change that can get you a certain amount of the ways there. That’s where we can take what could have become a huge expense and reduce that by half and still get that same outcome. It doesn’t always happen. But if it is possible, your business analyst IS the person who can help you find it.

Author: Anna Dereka