Defining Value and Assessing Value Realization
Key Takeaways
- BABOK Guide v3 defines Value as "the worth, importance, or usefulness of something to a stakeholder within a context," meaning value is always relative to who is judging it and the circumstances they judge it in.
- Potential value is the value expected or projected before a solution is implemented, while realized (actual) value is the value actually delivered, confirmed only after the solution is in use.
- Value can be tangible and quantitative, such as cost savings or revenue, or intangible and qualitative, such as improved customer satisfaction, reduced compliance risk, or better morale.
- Delivering a solution on time and on budget does not automatically mean value has been realized; value realization must be assessed against the original need after the solution is in use.
- Because value is stakeholder-relative, a single solution can deliver high value to one stakeholder group while delivering little or negative value to another within the same initiative.
What "Value" Means in Business Analysis
The BACCM defines Value as "the worth, importance, or usefulness of something to a stakeholder within a context." Two words in that definition do most of the work: "a stakeholder" and "a context." Value is never absolute or universal — it is always judged by someone, from within a particular set of circumstances. A new automated reporting feature might have enormous value to an executive who needs faster insight into operations, while the same feature has little value, or even negative value, to a data-entry clerk whose role it eliminates. Neither perception is "wrong"; they are both accurate assessments made from different stakeholder positions within the same context.
This stakeholder-relativity means a business analyst cannot define value once, generically, and apply it to an entire initiative. Value has to be defined in relation to specific stakeholder groups, and where different groups' definitions of value conflict, that conflict itself becomes something the business analyst must surface and help resolve.
Potential Value Versus Realized Value
Business analysis distinguishes between value that is expected and value that is confirmed:
- Potential value is the value projected or expected from a solution before it exists — the business case, the anticipated benefit, the reason the organization decided to invest in the change in the first place.
- Realized (actual) value is the value the solution genuinely delivers, measured after the solution is implemented and in use.
These two figures are not automatically equal. A solution can be delivered exactly as specified and still fail to realize the potential value that justified building it, because the underlying need was misunderstood, the context shifted, or adoption was poor. Conversely, a solution can realize value the original business case never anticipated. Distinguishing potential value from realized value is what makes value assessment a genuine analytical activity rather than a formality performed once at project kickoff.
Tangible and Intangible Value
Value is often discussed in purely financial terms, but business analysis recognizes both quantitative and qualitative dimensions:
| Type of Value | Examples |
|---|---|
| Tangible / quantitative | Cost reduction, revenue growth, cycle-time reduction, error-rate reduction |
| Intangible / qualitative | Improved customer satisfaction, reduced regulatory or compliance risk, stronger brand reputation, improved employee morale |
Both categories are legitimate forms of value, and both should be defined explicitly rather than left implicit. A common analytical mistake is treating only the tangible, easily quantified benefits as "real" value while dismissing intangible benefits as soft or unmeasurable, when in fact intangible value frequently drives the tangible value that follows it — for example, improved employee morale reducing costly staff turnover.
Assessing Outcomes for Value Realization
Because potential value and realized value are distinct, business analysis includes a deliberate step of checking outcomes after a solution is delivered:
- Define value explicitly before delivery, tied directly back to the original Need, so there is a clear baseline to measure against later.
- Identify what evidence would demonstrate value realization — usage metrics, satisfaction scores, cost data, or cycle-time measurements — before the solution goes live, not after.
- Measure actual outcomes once the solution is in use, rather than assuming delivery equals success.
- Compare actual outcomes to the originally defined need and expected value, not merely to the solution's technical specifications.
- Feed findings back into the organization, since discovering that potential value was not realized is itself valuable information that should inform future change decisions.
Why "Delivered" Does Not Mean "Valuable"
A recurring exam trap is treating on-time, on-budget delivery as evidence of success. A reporting solution can be delivered exactly as specified and still fail to realize value if it does not answer the questions stakeholders actually needed answered, or if the people expected to use it never adopt it. Confirming value realization means looking past whether a solution was built correctly and asking whether the original need was actually satisfied — a distinction the ECBA blueprint reinforces later through the applied Value domain, but one that starts here with a precise definition of what value means and how it is assessed.
A project team delivers a new reporting solution on time and on budget, exactly as specified. Six months later, adoption is low because the reports don't answer the questions users actually need answered. What does this scenario primarily illustrate?
In business analysis, which of the following best distinguishes potential value from realized (actual) value?