Establishing scope and context
An agreed outcome establishes what the design should help the business achieve. Scope defines what the solution must include, what can be deferred, and what belongs outside the engagement. Context provides the operational, organizational, and technical evidence needed to make and justify those decisions.
The Solution Designer evaluates candidate scope against the agreed outcome, applies the relevant context, and recommends boundaries that the business can support and the Solution Builder can carry forward.
Defining scope
Scope is more than a list of features. It defines the boundaries of the solution by identifying what belongs in the first release, what can be deferred, and what sits outside the engagement.
Each boundary represents a decision the Solution Designer must be able to explain:
- Included: What must the solution provide to support the agreed outcome?
- Deferred: What may contribute value later but is not required in the current release?
- Excluded: What does not contribute sufficiently to the agreed outcome? What requires a different response?
Tip: Scope turns the agreed outcome into boundaries on which the Solution Builder can act. Each inclusion, deferral, and exclusion should be supported by a clear rationale.
How the outcome shapes scope
The agreed outcome provides the standard for evaluating scope. For each scope candidate, the Solution Designer asks:
How would including, deferring, or excluding this affect the likelihood of achieving the agreed outcome?
The answer informs one of three decisions:
- Include it in the first release when it contributes directly to the outcome or enables another capability on which the outcome depends.
- Defer it to a later release when it may contribute value but is not required to achieve the outcome within the current release.
- Exclude it unless its absence would put the outcome at risk.
The Solution Designer applies this question to each candidate, including Case Types, Personas, Data Objects, integrations, and workflow variations. Evaluating candidates consistently makes the reasoning visible and gives stakeholders a clear basis for reviewing the proposed boundaries.
Evaluating priorities
A first release may contain more candidate scope than the available time, resources, and delivery conditions can support. The Solution Designer evaluates those candidates to determine which are essential to the agreed outcome, which should be sequenced for later, and which require a different response.
Review each candidate against the four criteria in the following table:
| Criterion | What it asks |
|---|---|
| Outcome contribution |
How directly does the candidate support the agreed outcome? A direct contribution strengthens the case for inclusion, while a limited contribution may support deferral or exclusion. |
| Dependency structure |
On what does the candidate depend, and what depends on it? A candidate may need to be included because it enables other work, while an unresolved dependency may affect when it can be delivered. |
| Delivery feasibility |
Can the candidate be delivered within the time, resources, budget, environment, integration availability, and organizational readiness of the release? A candidate may contribute directly to the outcome but still need to be deferred if the conditions required to deliver it are not yet in place. |
| Reversibility |
What are the implications of deferring the candidate and adding it later, compared with including it now and changing direction if needed? Decisions that are easier to reverse can be made with greater flexibility. |
The Solution Designer considers the criteria together, applies the relevant context, and uses the evidence to recommend whether the candidate should be included, deferred, or excluded.
The three layers of context
Scope establishes the boundaries of the solution. Context provides the evidence needed to ensure those boundaries reflect how the business operates, how responsibilities are organized, and what the technology environment can support.
The Solution Designer evaluates three layers of context when recommending scope:
Context will continue to develop as the engagement progresses. The Solution Designer makes the available evidence, assumptions, and gaps visible so stakeholders can understand the basis for each scope recommendation.
- An assumption is information the team is using to proceed but has not yet confirmed.
- A gap is information or access the team knows is still needed before a related design decision can become a delivery commitment.
Recording assumptions and gaps clarifies which recommendations are supported by confirmed evidence and which may need to be revisited as additional information becomes available.
Bringing the framing work together
The initial solution context brings together the decisions and evidence developed throughout framing. It provides a shared record of what the design must address, what the business wants to achieve, and what will shape the boundaries of the solution.
The Solution Designer assembles six elements:
- Validated problem: The business challenge the design will address.
- Agreed outcome: The intended business change, including its beneficiary, target, time horizon, baseline, and measurement mechanism.
- First-release scope: What is included, deferred, or excluded, with the rationale for each decision.
- Context: The operational, organizational, and technical evidence that shapes the design and its boundaries.
- Assumptions: Information the team is using to proceed but has not yet confirmed.
- Gaps: Information, decisions, or access still needed before a related design decision can become a delivery commitment.
These elements will continue to develop as the engagement progresses. Recording them together ensures that changes can be evaluated against the validated problem, agreed outcome, scope, and available evidence rather than considered in isolation.
Scenario: Establishing scope and context for U+ Travel
The agreed outcome gives the Solution Designer a clear standard for evaluating U+ Travel’s candidate scope:
- Support 25 percent booking growth in year one without adding operators
- Reduce reconciliation errors from 11 per week to fewer than two.
The Solution Designer considers the contribution of each candidate to that outcome, along with the relevant context, dependencies, and suitability for the first release.
| Scope candidate | Evaluation | Recommendation |
|---|---|---|
| Shared operational view of bookings across all operators | Directly supports booking growth and reduces the reconciliation required across operators. It also addresses the operational reality that booking information is currently distributed among personal spreadsheets, phone messages, text threads, and a whiteboard. | Include in the first release |
| Real-time inventory visibility across excursion types and time slots | Enables the shared operational view and gives operators access to consistent booking information. The design must account for limited connectivity when operators are on the water. | Include in the first release |
| Automated customer confirmations and pre-booking communications | Supports the customer experience but is not required to establish shared visibility or reduce reconciliation errors. Current communication practices can continue while the first-release capabilities are established. | Defer to a later release |
| Post-booking service for weather-affected excursions | Could reduce operator workload but depends on access to an external weather-data source. A provider has been identified, but access has not yet been arranged. | Defer until the dependency is resolved |
| Multilanguage customer-facing interface | Could benefit international visitors but does not directly support the agreed first-release outcome. Operators can continue using their existing multilingual communication practices. | Exclude from this engagement and record as a candidate for a separate initiative |
The Solution Designer’s evaluation also identifies assumptions and gaps that may affect the recommended scope:
- Assumption: Existing customer communication practices can continue during the first release without limiting the agreed outcome.
- Gap: Access to the external weather-data source has not yet been arranged.
- Gap: Current peak-season booking volume still needs to be confirmed using the agreed measurement mechanism.
Making these assumptions and gaps visible allows the Solution Designer to recommend a first-release scope while identifying the evidence and dependencies that may require further attention.
In practice
The practices below help Solution Designers evaluate scope, apply relevant context, and recommend scope with a clear rationale:
| Practice | Why it matters | Questions to ask |
|---|---|---|
| Evaluate each candidate against the agreed outcome | The outcome provides a consistent standard for determining what the first release must support and helps prevent scope from expanding without evidence. | How would including, deferring, or excluding this affect the likelihood of achieving the agreed outcome? |
| Apply context to the scope decision | Operational, organizational, and technical evidence determines whether a candidate fits the business and can be supported within the release. | What operational, organizational, or technical evidence could affect this recommendation? |
| Distinguish inclusion, deferral, and exclusion | Each boundary represents a different recommendation. Clear distinctions help stakeholders understand what belongs now, what may be considered later, and what requires a different response. | Is this required in the first release, appropriate for later consideration, or outside the current engagement? |
| Record assumptions and gaps | Assumptions identify what the team is using to proceed, while gaps identify the evidence, decisions, or access still needed. | What are we assuming, and what must still be confirmed before this recommendation becomes a delivery commitment? |
| Make the rationale visible | Documented reasoning allows stakeholders to evaluate the recommendation and provides a clear basis for revisiting the decision when new information emerges. | What evidence supports this recommendation, and where should that rationale be recorded? |
A foundation for design
The Solution Designer works with stakeholders to establish:
- A validated business problem
- An agreed and measurable outcome
- Reasoned boundaries for the first release
- The operational, organizational, and technical context that shapes the design
- A clear record of the assumptions and gaps that require further attention
Together, these elements provide the foundation for creating and evaluating the initial Blueprint.
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?