Define the challenge statement
Write an outcome-focused scope for the market to solve.
Define an outcome focused challenge statement
After shaping and framing the problem to be solved, use the outputs to define an outcome-focused challenge statement. Focusing on outcomes is essential to ensure suppliers can put forward a range of different solutions that match the scope of innovation.
This step involves writing an outcome-focused challenge statement over 2 weeks.*
*Duration will vary with project complexity and resource availability.
A challenge statement outlines the scope of the opportunity, the problem to be solved, desired outcome and measures of success.
When to define the challenge statement
The challenge statement should be written:
- after buyer discovery phase
- after pathway and tactics have been defined
- after problem statement shaping and framing
- before writing the Statement of Requirements (SoR)
- before writing the Procurement Strategy documentation
- before seeking approval to procure.
Who to involve
- Buyers and SME roles such as Service Designer, ICT architecture, digital strategy, and/or Innovation may contribute to the challenge statement definition.
- Buyers can engage a Service Designer or roles with similar skills to write the challenge statement document.
- Procurement representatives and stakeholders with expertise in the business unit or service area might review the challenge statement and provide feedback.
Resources
Before writing a challenge statement, document authors should have a minimum foundational level of ICT scoping experience and skill, usually possessed by roles such as ICT Business analyst, UX designer, or Service designer.
If you don’t have the foundational skills, yet intend to undertake this activity yourself, please contact the innovation procurement advisory team at InnovationProcurement@customerservice.nsw.gov.au for advice, support and guidance.
If you have the foundational skills, you may access the resources supporting this step. Note that these resources are undergoing testing and are available for guided use in conjunction with the Innovation Procurement Pathway advisory team. This ensures that the guides can tailor to project needs and incorporate any improvements.
To access expert resourcing to lead this activity, please contact the innovation procurement advisory at InnovationProcurement@customerservice.nsw.gov.au. If you have any trouble accessing a file or document on this page, you can request an accessible version from the same email address.
Key inclusions
The challenge statement should define:
- business objectives
- one or more concise, actionable ‘how might we’ HMW problem statements
- user stories that identify the end-user, need and value to the end-user
- desired outcome, success criteria and measures of success.
The challenge statement may also include:
- detailed user stories that identify the end-users
- use cases that identify the actors and interactions, either for the whole procurement, or for a single delivery stage such as Proof of Concept.
Resources:
Key steps
Define the buying objectives, background and strategic 'how might we’ (HMW) statement
- the challenge statement should state upfront the buying objectives, background and sufficient business information to provide context to suppliers
- in a multi-stage procurement, it’s important to signal the strategic opportunity for suppliers beyond the first stage
- this can be signalled via a strategic HMW statement
- following the definition of the objectives and background, define the strategic HMW statement
- the strategic HMW statement should reframe the overall buying project objective in the form of challenge
- following the strategic HMW statement definition, a summary of tactical use cases and HMWs should be defined
- this summary should reference a later section in the challenge statement with expanded levels of detail for each tactical use case.
Resources
Define the current state situation
- use the outputs and synthesis from the workshop 1 and 2 to define the current situation
- it may be expressed within each use case as a brief paragraph that includes current benchmark metrics
- it may be expressed as more nuanced user personas, where the attributes, goals and frustrations are noted for each user archetype in more detail upfront ahead of the detailed use cases
- known current state constraints should be noted in the constraints section of the challenge statement.
Resources
Define the high level use cases
- a high level use case is the highest level description of a function
- use the outputs and synthesis from workshops 1 and 2 to frame the high level functions required
- define each key high level function as a one sentence description and provide a reference number such as Use case 1, 2, 3, 4 etc.
- example of a high level use case: ‘Use case 2: Traffic fine fraud detection’
- the high level use cases identified are the ‘wrappers’ for additional detail that supports better context setting
- this additional detail will include a ‘how might we’ (HMW) statement, user stories, desired outcome, success criteria and measures.
Resources
Define tactical ‘how might we’ statements
- expand each high level use case with a ‘how might we’ (HMW) statement
- use the outputs and synthesis from workshop 4 to define the tactical opportunity in sufficiently narrow terms so that it provides solution focus, but uses sufficiently broad terms so it doesn’t assume the solution
- tactical HMW statements should be used to expand use case scope for the proposal or proof of value stage of a multi-stage procurement.
Resources
Define success criteria and measures
- for each high level use case and tactical HMW statement, define success criteria and measures, using the outputs and synthesis from workshop 3.
Resources
Define user stories
- for each high level use case and tactical HMW statement you may provide additional context by writing one or more user stories
- user stories use a specific format or syntax to define each specific user archetype, their current problem, and their desired outcome
- the outputs and synthesis from workshop 1 and 2 may be used to write User Stories workshop 3.
Resources
Prepare Statement of Requirements documentation
Coming soon