Confirming Desired Outcomes and Value Opportunities
Key Takeaways
- The BACCM defines value as the worth, importance, or usefulness of something to a stakeholder within a context.
- BABOK Guide v3 distinguishes an outcome, the end benefit of a change, from an output, the tangible or intangible artifact that produces it.
- Potential value is the highest value achievable if a change is implemented and used effectively; actual value is what is currently being realized.
- The Assess Solution Limitations task identifies internal factors, such as missing or inadequate features, that constrain value realization.
- The Assess Enterprise Limitations task identifies external, organizational factors, such as culture, training, or adoption gaps, that block value even when the solution itself is sound.
Outcomes vs. Outputs
Business analysis exists to enable change that creates value for stakeholders. The Business Analysis Core Concept Model (BACCM) defines value as the worth, importance, or usefulness of something to a stakeholder within a context. Confirming that a change has actually created value starts with a distinction BABOK Guide v3 draws sharply: an output is the tangible or intangible artifact a team produces — a deployed system, a signed policy, a trained workforce — while an outcome is the end benefit that results once stakeholders put that output to use. A project can deliver every output on schedule and still fail to produce the outcome the business needed. A business analyst's job when confirming desired outcomes is to verify that the outcome, not merely the output, is present and traces back to a stated business objective.
Confirming outcomes means asking, concretely, whether the change did what the business objective said it should do. If the business objective was "reduce average claim-processing time by 30 percent," the business analyst does not stop at verifying the new claims system was installed; the business analyst verifies that processing time actually dropped by roughly that amount under real operating conditions. This is where acceptance and evaluation criteria, defined earlier in the solution lifecycle, become the yardstick: they were written specifically so that, at this stage, there is an objective basis for saying an outcome was achieved rather than relying on impression or sponsor sentiment.
Understanding Value: Potential vs. Actual, Tangible vs. Intangible
BABOK v3 further splits value along two dimensions a business analyst must keep straight when confirming outcomes:
| Dimension | Definition | Example |
|---|---|---|
| Potential value | The highest value that could be realized if a change is implemented and used effectively | Full projected savings from an automated invoicing system |
| Actual value | The value currently being realized, which may be less than potential value | Savings actually observed six months after go-live |
| Tangible value | Value that can be measured directly, usually in financial terms | Reduced operating cost, increased revenue |
| Intangible value | Value that is difficult to measure directly but still contributes to goals | Improved morale, stronger brand reputation, reduced risk exposure |
The gap between potential and actual value is exactly the space a business analyst investigates during confirmation: why has the full projected value not shown up yet, and what would close that gap?
Identifying Value Opportunities
A value opportunity is any point where the enterprise could increase the worth stakeholders receive from a solution beyond what was originally planned. Business analysts surface these opportunities by comparing the current state against the desired future state and asking where underused capability, unaddressed need, or emerging stakeholder interest exists. Common sources of value opportunities include:
- Capabilities the solution has that stakeholders are not yet using to full effect
- Adjacent processes that could reuse a newly built capability
- Feedback from early adopters pointing to features stakeholders value more than expected
- Market or regulatory changes that increase the relevance of a delivered solution
Not every value opportunity should be pursued immediately. Business analysts document each opportunity with enough context — the current gap, the stakeholders affected, and a rough sense of tangible or intangible benefit — so that decision-makers can prioritize it against other initiatives competing for the same budget and attention. Treating every opportunity as an unplanned scope addition, rather than a candidate for a future change request, blurs the line between confirming today's outcome and expanding tomorrow's scope.
Barriers to Value: Solution and Enterprise Limitations
When actual value trails potential value, BABOK v3's Solution Evaluation knowledge area gives the business analyst two lenses for diagnosing why:
- Solution limitations are internal to the solution itself: missing features, inadequate performance, defects, or components that were never fully built out. These constrain value regardless of how well the organization adopts the solution.
- Enterprise limitations are external to the solution: organizational structure, culture, available skills, competing priorities, inadequate training, or resistance to change. A technically sound solution can still fail to deliver value if the enterprise around it is not ready to use it.
Distinguishing the two matters because the fix differs. A solution limitation calls for enhancement work — new development, defect resolution, added functionality. An enterprise limitation calls for organizational action — training, communication, process redesign, or leadership sponsorship. Recommending a technical fix for what is really an adoption problem wastes effort and leaves the true barrier untouched.
In practice, the two limitations often appear together. A poorly performing reporting feature — a solution limitation — can be worsened by a lack of user training on the workarounds available — an enterprise limitation — and addressing only one of the two leaves part of the value gap unresolved. Business analysts document both types of limitation side by side so that whoever owns the follow-up action, whether a delivery team fixing the solution or a change-management sponsor fixing the enterprise, has a complete, undistorted picture of why expected value has not yet fully materialized.
Confirming Outcomes on the Exam
Because the ECBA is situation-based, expect stems that describe a delivered solution alongside evidence of stakeholder behavior, then ask you to identify what that evidence represents. The core exam habit: locate the business objective in the stem, compare it to what stakeholders are actually experiencing, and decide whether any gap sits inside the solution or outside it in the enterprise. Reflexively assuming every gap is a requirements problem is a common wrong-answer trap; many gaps are adoption, training, or cultural limitations that no amount of re-eliciting requirements would have prevented.
A business analyst reviews a newly delivered inventory system and finds that warehouse staff now generate accurate stock reports in half the time they used to. Which BACCM concept best describes this reduction in report time?
During a post-implementation review, a business analyst learns that a new CRM was deployed on schedule and meets every documented requirement, yet the sales team keeps relying on spreadsheets because they were never trained and do not trust the new data. What should the business analyst report?