Evaluating Solution Options

Why Business Analysts Evaluate Solution Options

Rarely is there only one way to satisfy a need. In the BACCM, a given Need can typically be addressed by more than one possible Solution or design option, and each option comes with its own trade-offs in cost, risk, and organizational impact. Business analysts support the team by systematically comparing these options so that whoever holds decision-making authority — a sponsor, product owner, or steering committee — has clear, objective analysis to work from rather than guesswork or personal preference.

This evaluation work typically happens after needs have been elicited and requirements have been specified, when the organization must decide how to satisfy those needs: build custom software, buy a commercial package, extend an existing system, change a business process, or some combination of these.

Feasibility Factors

A central part of evaluating options is assessing their feasibility — whether an option can realistically be delivered and sustained by the organization. Three feasibility factors recur across most options analysis:

An option can look attractive on one dimension and fail on another — a technically elegant solution that the organization has no operational capacity to run is not, in practice, a feasible one. Business analysts document all three dimensions for each option under consideration rather than focusing on a single factor.

Assessing and Documenting Risk

Alongside feasibility, business analysts apply Risk Analysis and Management — a named BABOK technique — to identify and assess the risks associated with each solution option. This generally means identifying specific risk events, estimating their probability and potential impact, and considering what response (avoid, mitigate, transfer, or accept) would be appropriate if the option were selected.

Common categories of risk to weigh when comparing options include:

• Implementation risk — the chance that delivering the option itself goes wrong, such as schedule slippage or integration failure
• Operational risk — the chance the solution creates problems once it is running day to day
• Adoption risk — resistance from stakeholders who must change how they work
• Technology risk — reliance on unproven, unsupported, or soon-to-be-obsolete technology
• Financial risk — costs exceeding estimates or benefits failing to materialize

Documenting these risks alongside each option's feasibility gives decision-makers a fuller picture than cost or technical merit alone would provide.

Weighing Feasibility and Risk Together

Feasibility and risk are related but not the same thing, and evaluating options well means looking at both side by side rather than treating either in isolation. A low-feasibility option is not automatically the same as a high-risk one: an option can be technically and operationally feasible yet still carry meaningful financial or adoption risk, while another option might be lower-risk in the short term but only marginally feasible to sustain over time. For example, extending an existing in-house system the team already maintains might score well on technical and operational feasibility because staff already understand it, while still carrying financial risk if the underlying platform is approaching end of vendor support. A commercial package might carry lower long-term technology risk through vendor support, while scoring lower on operational feasibility if it requires the organization to change established processes.

Business analysts capture both dimensions for every option under consideration — typically in a simple comparison format that decision-makers can scan quickly, such as a table or matrix listing each option against its feasibility rating and its principal risks. This keeps the analysis grounded in evidence rather than intuition, and it means that when a decision-maker chooses an option that is not the cheapest or fastest, the trade-off being accepted is visible and documented rather than hidden.

Contributing to Recommendations

An entry-level business analyst does not typically make the final call on which option to pursue — that decision sits with whoever holds governance or budget authority. What the business analyst does contribute is structured, objective comparison: for example, using a technique such as SWOT Analysis (Strengths, Weaknesses, Opportunities, Threats) to lay out each option's profile side by side, or building a simple weighted comparison against agreed evaluation criteria (see the previous section).

The business analyst's responsibility is to present trade-offs clearly and neutrally — cost against risk, feasibility against strategic fit — without steering the outcome toward a personal preference, and to make sure the comparison is traceable back to the original business need and value the initiative is meant to deliver. This analysis becomes the input the decision-making authority uses to select, adjust, or combine solution options, and it is also the record the team returns to later if the chosen option's performance needs to be reassessed.