Business Outcomes
What Is a Business Outcome in ArchRepo?
A Business Outcome is a high-level statement of what the business wants to achieve through the solution. Outcomes describe the goal — the change the business is trying to bring about — rather than the specific features or functions the solution must provide.
Business Outcomes sit at the top of the requirements-traceability hierarchy. They are the “why” that justifies everything below them.
Examples of Business Outcomes:
- “Reduce the time taken to process a customer invoice from submission to payment by 60%”
- “Enable field engineers to access and update job records without returning to the office”
- “Eliminate manual data re-entry between the CRM and the billing system”
- “Provide customers with real-time visibility of their order status”
Outcomes vs Requirements
Business Outcomes and Business Requirements serve different purposes and should not be conflated.
- A Business Outcome describes a goal the business wants to achieve: “Reduce invoice processing time by 60%.”
- A Business Requirement describes something the solution must do: “The system must allow bulk upload of invoices in CSV format.”
Requirements support Outcomes — each requirement should be traceable back to one or more outcomes. If a requirement cannot be linked to any outcome, it is a candidate for challenge: “Why are we building this? What goal does it serve?”
Documenting Outcomes separately from Requirements makes this traceability explicit and provides a principled basis for scope control.
Why Document Business Outcomes?
Capturing Business Outcomes in ArchRepo provides:
- Scope validation — any requirement that cannot be traced to an outcome is a candidate for challenge or deferral; outcomes provide the business justification for everything the solution delivers
- Stakeholder alignment — outcomes are written in business language that stakeholders at all levels can understand and agree on; they provide a shared definition of success
- Acceptance basis — outcomes provide the high-level criteria against which the solution will ultimately be judged; acceptance criteria can be defined at the outcome level to make this explicit
- Prioritisation — MoSCoW prioritisation at the outcome level helps focus investment on what the business considers essential vs desirable
Priority
Each Business Outcome is prioritised using MoSCoW:
| Priority | Meaning |
|---|---|
| Must Have | This outcome is essential — the solution fails if it is not delivered |
| Should Have | This outcome is important but not critical; should be delivered if possible |
| Could Have | This outcome is desirable but lower priority; include if time and budget allow |
| Won’t Have | This outcome is out of scope for the current phase but may be revisited later |
Prioritising at the outcome level helps the delivery team make consistent decisions when trade-offs arise — requirements that support a Must Have outcome should generally take precedence over those supporting a Could Have.
Fields Reference
See Business Outcome Fields for a description of each field and guidance on what to record.