Business Analysis: One of the Overlooked Areas of Successful Software Development

“What problem are we trying to solve?”

As a career business analyst, I’ve lost count of the number of times I’ve asked this question. More often than not, stakeholders are ready to discuss solutions before dissecting the problem itself. The result? A half-baked “solution” that may or may not address the key problem, and likely also creates new problems. Case in point: Once, a stakeholder submitted a project request to have a report generated out of the claims adjudication system. It didn’t sound unreasonable and it wasn’t a huge ask—estimated at roughly $200,000 to complete.

First thing’s first: “What problem are we trying to solve?”

I pivoted the discussion to focus more on the problem. Who is the report for? Why is it needed? What problem(s) does his team face without this report? What is the magnitude of said problem(s)—i.e., how often do they deal with it, and what is the impact? If there was no technology, and the business only had pen and paper, what information would they need in order to complete their tasks? By the end of the meeting, I learned that this report would be used by one team, that it was only needed on occasion, and that there was an existing query tool that could be used to generate such a report without needing to engage the software development team. The cost? A couple hours of the business’ time to build said query.

Conversely, we could proceed with the original project request, allocating software development resources for an application that was at the core of their business. The claims adjudication system was central to countless other tools, processes, and teams, and as such, any project request related to it could have a significant impact on the organization. It would have to be prioritized against other requests and managed with other projects competing to have changes deployed at the same time. Much overhead and detailed planning would be needed to ensure a smooth implementation without adversely impacting other projects. I saw dollar signs.

Based on this information, the business realized that the original solution was “overkill,” and they had no desire to risk creating other problems when their team already had the means to generate such a report on their own.Thus, the project request was canceled, freeing up funds for other pursuits later on. But, I digress.

Business analysts don’t accomplish this by being scribes. Understanding the software development lifecycle (SDLC) and writing business requirements is only a small part of what we do. There is an art to business analysis, and it takes years of experience to build an aptitude for it. So, what exactly do we do?

Problem analysis

Given one hour to save the world, I would spend 55 minutes defining the problem and 5 minutes finding the solution.

Albert Einstein

We analyze problems. We recognize the natural inclination to present solutions before understanding a problem. But we also know that in doing so, the business does itself a disservice by not giving others the opportunity to do the problem-solving for them. If the business can clearly articulate the requirements related to a problem, trust that our software development counterparts can offer a better solution.

Evaluating upstream and downstream impacts

We get out of the weeds to understand how an organization is structured, where each business process begins and ends, and within which domains. For example, if a new field needed to be added (say, for compliance reasons) to a web application being used to process new orders, then could we safely implement this enhancement without disrupting other business processes? Are there other people, processes, or technology that “feed” into the web application (a.k.a. “upstream” impacts)? Are there other people, processes, or technology that use the information from the web (a.k.a. “downstream” impacts)? Perhaps there’s a customer service team that relies on a report with data from the web; would this new field then need to be added to the report as well? Ultimately, we help the business evaluate these scenarios so that there are no surprises (read: unplanned consequences) come time for deployment.

Solution validation

We’ve gathered, analyzed, and documented requirements–now what? Our software development partners have consumed the requirements and are ready to present a solution. Does the solution meet the business requirements? Check. Is it delivered in a way that the business can support? Check. Are the maintenance costs associated with supporting the proposed solution reasonable and appropriate for the long run? Check. 

We help ensure the solution is appropriate in size and scope, and that any maintenance required can be justified based on the value-add of said solution. Put another way, if there’s an extra room in the house that never gets used, then we’ll make certain you are properly informed to decide whether the upkeep is worth your money.

Championing MVP

This is especially important if it’s your first rodeo with a software development team. You want a minimum viable product (MVP) and have allotted X amount of money to build it. We help you achieve this by managing the product scope, creating a roadmap plan, and facilitating requirements meetings to deliver within the allotted budget and timeframe. 

We understand the pressure with every product decision–that it feels safer to say “yes” to everything when every feature or enhancement sounds equally important. But we also know that this is how other projects end up with only half of the desired product; where they say “yes” to enhancements that aren’t necessarily on the critical path, we help by championing MVP and providing the guidance needed in order to help you make informed product decisions. 

What else?

Requirements elicitation, analysis, organization, and documentation; creating visual representations to support the analysis and discussion of complex concepts (fact models, gap analyses and process flows are a few favorites); risk identification and mitigation; contingency planning; decision analysis; the list goes on. There’s a method to the madness that is business analysis, and this is only scratching the surface.

So why does this matter?

Business analysts aren’t only pivotal for a single project’s success. We are here to ensure that the end result aligns with the business needs of the project, your team, and enterprise at large–in both the short-term and long-term. As consultants, we are with you every step of the way. We will challenge assumptions. We will ask the hard questions. And when there are difficult decisions to make, we will guide you; you will know the pros and cons at every juncture, so you’ll never feel a decision was made half-heartedly or without purpose. 

Ultimately, it is our imperative that you feel confident about the choices you make, and the product we are building. Together. If you need help streamlining your software development process with business analysis or need a partner to help with all aspects of your application, then please don’t hesitate to contact us to discuss how we can help!