Business Objective.
WS04 translates the problem from Situation into a SMART business objective with success criteria and a quantifiable benefit target. The benefit claim here becomes the accountability commitment the program gets measured against in Embed.
Purpose
The objective answers "what does success look like?" in operational terms that stakeholders can recognize a year later. The benefit claim — captured as a Quantifiable Benefit Estimate (QBE) — names the specific measurable improvement the program promises to deliver. This is what gets verified against actuals during Embed.
When to use
After WS03 Stakeholder Analysis and before WS05 Trade-off Table. You need the objective locked before evaluating options — options must serve the aim, not the other way around.
Template
| Objective | The outcome, framed in operational/realized-value terms |
|---|---|
| Specific | Unambiguous about what changes |
| Measurable | Has a data source and a number attached |
| Achievable | Threshold reflects a realistic target, not a wish |
| Relevant | Ties to strategy or named business need |
| Time-bound | When the realization window closes |
| Success metrics | Leading and lagging measures with baselines |
| Counted population | Which scope the measure applies to |
| Effective date | From what date the measurement starts |
| Benefit target (QBE) | The quantified claim the program commits to |
| Audit method | How the realization will be verified in Embed |
Best practices
- Prefer existing system records over manual audit schemes. If the measurement requires building new infrastructure to track, the objective is probably not yet realistic.
- Use approved exception paths where unrealistic "no exception" language would force the team to lie later.
- Frame benefits around realized operational value, not process activity — the target should describe what materially improves, not what gets measured.