Prepare a Statement of Requirements
How to prepare a a Statement of Requirements that will attract innovation and support evaluation.
What requirements should look like for innovation
When the end solution is not known, deliverables, timelines, milestones, constraints and pricing are subject to uncertainty. They may depend on the nature of the end solution, which makes it hard to communicate expectations to suppliers through a Statement of Requirements. Existing templates need amending to support an innovation procurement.
Expect to tweak templates for innovation procurement
Documenting requirements for innovation procurement generally means tweaking a standard Statement of Requirements template to accommodate a challenge statement, outcomes-based approach and/or multiple stages.
Statement of Requirements templates designed to capture fixed specifications are suitable when the buying team is confident that it knows and understands the solution. A standard template can be well-suited for the later 'Build it with us' or ‘Implementation’ stage of a multi-stage procurement. By those later stages, buying teams have narrowed down their preferred solution and can document specific requirements and timelines. For example: a Minimum Viable Product (MVP), pilot or full-scale implementation.
However, when first approaching the market, this level of certainty and detail is not available. A Statement of Requirements for the initial market approach should focus on the challenge statement. It may only provide deliverables and timing information in relation to the planned testing stages rather than solution delivery. Buying teams should include some technical requirements and/or constraints if they are show-stoppers, but most would come at a later stage.
Between the first and last stage (for example, at the ‘Prove it works’ stage) a combination of a challenge statement and a level of specification is appropriate. This stage involves testing technical feasibility in a limited scope experiment. It happens once one or more probable solutions have become evident.
This page supports buying teams to make the most appropriate amendments to Statement of Requirements templates based on their unique innovation buying project.
Guidance on structuring requirements for the 'Proof of Concept' (PoC) or 'Build it with us' stage of an innovation procurement will be coming soon. If you have a query that concerns writing requirements for a PoC, please contact the Test and Buy Innovation team at InnovationProcurement@customerservice.nsw.gov.au
Documenting deliverables
This section provides an overview and sample phrasing for how to approach the deliverables and timelines sections of the Statement of Requirements for innovation procurement.
Deliverables
The deliverables section of a Statement of Requirements instead usually focuses on the products or services the supplier is expected to provide. Since these are unknown at the initial market approach, the content of this section will depend on the type of market approach and the stage (if a multi-stage procurement). Expand the boxes below to learn how to approach deliverables for the relevant stage.
Context
An Expression of Interest (EoI) or Request for Information (RfI) is used to understand the appetite, possible solutions and capabilities in the market. These insights help to create a procurement strategy. Participating in an EoI or RfI should be relatively low effort for suppliers, with summary-level information requested and a limited burden of proof.
Insights from an EoI or RfI can inform more detailed requirements and deliverables for an eventual tender once more is understood about potential solutions and the state of the market.
What to cover
The deliverables section for an EoI or RfI should focus on the information the buying team is asking suppliers to provide. Information may be requested in writing or as part of a pitch or demonstration, depending on the nature of the project and the type of insights needed. The request will usually be through direct questions in a supplier response schedule but could also appear more generally in deliverables. Suppliers might be asked for:
- explanation of how a solution could address a specific challenge
- whether a functional requirement can be met either fully or partially
- indication of whether non-functional requirements, including requirements for working with the NSW Government, can be met
- evidence of knowledge about the project context
- alternative approaches to solve the problem and/or feedback on the framing
- benefits of the solution or the case for change
- description of how a solution is usually tested and/or delivered.
Suppliers may need to refer to other content to prepare their response. The deliverables section should link to relevant content using section or attachment names clearly, and in a way that makes it easy for suppliers to jump back and forth. The other content may include:
- minimum eligibility requirements, also called mandatory criteria, including requirements for doing business with the NSW Government
- an indication of requirements that will likely need to be met at a later stage of the procurement depending on the type and scale of services being procured
- a challenge statement, including detail about the current state, user stories, desired outcomes and constraints.
With the goal of gathering insights, buying teams should minimise mandatory requirements. This ensures they can adjust to new insights and mitigate any specific risks arising, rather than attracting few eligible responses. To make this clear to suppliers, include a paragraph like the below along with any lists of requirements:
Example 1:
‘We acknowledge that suppliers may not meet all requirements. The information gathered through this RfI will serve as insights into these gaps and may help develop collaborative strategies and ways of working within the identified constraints.’
or
Example 2:
‘If Respondents progress to future stages, [AgencyName] will, at the appropriate time, assist them to further understand and navigate these requirements. Any specific questions relating to future requirements can be raised via the questions process outlined in section [X].’
Context
In a multi-stage approach, the buying team develops a single procurement strategy and approaches the market once. After this they rely on short-listing through testing and evaluation stages.
With each stage, the buying team builds their knowledge of suppliers and solutions. This enables the team to tighten requirements and deliverables ahead of each stage.
What to cover
The staged nature of deliverables should be communicated clearly to suppliers, as well as any criteria for short-listing or progressing from one stage to the next. Examples of some variations that buying teams might consider, and which need to be clearly explained, include:
- the ‘Prove it works’ stage might apply only to solutions where the solution is not mature or there is limited evidence it has been implemented in comparable contexts
- the ‘Implement at scale’ stage might proceed without a “Prove it works” stage if a mature solution is found to have met all requirements
- stages might run concurrently for different use cases, if different solutions are found to have different applications and maturities.
Rather than covering detailed requirements, the deliverables section should outline:
- the number of proposed stages and the name of each stage
- the minimum expectations for the delivery of each applicable stage
- the pathways and/or criteria for progressing between stages
- the minimum response expected for the initial Stage 1 Proposal.
Detailed requirements (a challenge statement in the first stage) should be described later in the document under a separate heading or as an attachment.
Buying teams can adapt the following example for their Statement of Requirements.
‘The Project has three defined stages of deliverables: a Proof of Value stage, a Proof of Concept stage and a Scale stage. Suppliers will be short-listed for each stage based on deliverables from the prior stage, in accordance with evaluation criteria in section [X].’
‘By participating in this tender, the Respondent commits to delivering the following as a minimum for each applicable stage:
- Stage 1 Proof of Value – demonstration (or pitch) of how solution can solve the problem described in the challenge statement, with reference to user stories, desired outcomes and constraints.
- Stage 2 Proof of Concept – depending on the nature and maturity of solutions, a limited implementation, sandbox testing, trial, Minimum Viable Product or pilot.
- Stage 3 Implementation – depending on the nature of the solution, an agreed implementation plan covering configuration, integration, user training and ongoing support.’
‘The Respondent must respond to a minimum of 1 of the use cases described in section [X] for their Stage 1 Proof of Value Proposal.’
For more detailed suggestions for how to describe the deliverables of future stages, expand the box for each relevant stage.
Context
The ‘Show us’ stage usually involves an interactive presentation providing more insight into a proposal. This could be a demonstration of an off-the-shelf product. It could cover how the product would be tailored for the user stories described in the challenge statement. It could be a pitch, a presentation, or another interactive format that helps bring a solution to life.
What to cover
Buying teams can choose to communicate their expectations for the ‘Show us’ stage to suppliers as part of the initial market approach. Or they can wait until after they have short-listed suppliers based on written responses.
Communicating expectations upfront has the advantage of reducing the amount of notice suppliers need to take part in the ‘Show us’ stage. It can also speed up the evaluation process. However, buying teams will need to invest time into defining the scope of the ‘Show us’ stage to ensure suppliers understand what is expected of them. This can delay the initial market approach.
If buying teams wait until after short-listing to set expectations, they will need to factor several weeks into timelines for suppliers to understand and deliver against the ‘Show us’ scope. The advantage of waiting is that, if buying teams find gaps in their insights from written proposals, they can ensure they are addressed in the scope of ‘Prove it works’ stage. All short-listed suppliers would receive the detailed stage deliverables when invited to participate. This option gives the buying team more agility and adaptability. It also ensures fairness and transparency for suppliers.
An example of how deliverables can be described up-front for a ‘Show us’ stage, in this case a Proof of Value, is below. Deliverables might become more detailed if buying teams refine the scope after evaluating written responses.
Show us example – Proof of Value (PoV)
Shortlisted respondents will be invited to undertake a Proof of Value to demonstrate their understanding of the challenge and selected use case(s), the capability and case for change and benefits of the proposed solution. The Proof of Value must propose solution(s) for at least one of the use cases specified in the Statement of Requirements and may also propose alternative or use cases for their Proof of Value.
Proof of Value demonstrations will take place in-person on [date] with 90 minutes allocated to each respondent. Virtual demonstrations will be considered on a case-by-case basis. By participating in this tender, respondents commit to being available to participate in Proof of Value demonstrations.
The session will consist of 10 minutes of NSW Government introduction, 60 minutes for respondent presentation and 15 minutes for questions. Respondents may use one or more forms of media to demonstrate and provide evidence to support the information provided in their written response. These media may include PowerPoint presentations, product demos, videos and prototypes.
Further information relating to protocols will be issued to respondents closer to the date.
Context
The ‘Prove it works’ stage aims to determine if the solution is technically feasible. There are many ways to achieve this. Buying teams may need to be able to adapt the stage to the nature and maturity of solutions before it starts. To enable this, expectations for this stage should be set at a high level only at the initial market approach, with clear criteria for when the stage might apply (e.g. for less mature solutions that do not have live customers).
What to cover
More detailed deliverables can be given to short-listed suppliers when they are invited to participate in the stage. The initial market approach document should clearly signal that the stage scope and requirements deliverables will be communicated to eligible suppliers, and when this will occur.
Below is an example for an optional Proof of Concept stage. Deliverables for the stage would be much more detailed and, at this point, technical once the stage is ready to start.
Example Stage 2 - Proof of Concept (PoC)
Shortlisted respondents from the ‘Show us’ Proof of Value (PoV) stage may be invited to participate in in the ‘Prove it works’ stage to undertake one or more Proofs of Concept (PoCs). This may occur where additional validation is required of the technical basis and commercial feasibility of all or part of the proposed solution from the PoV. During the PoC, Respondents will be asked to further develop the proposed solution, such as through testing the product or service in an on-premise environment.
The decision to proceed with the PoC stage will depend on the outcome of the PoV stage, and [AgencyName] will determine whether to pursue this optional Stage for all or part of the proposed solution presented in the PoV.
Following completion of the PoV, shortlisted Respondents will receive a Statement of Requirements that details the deliverables for the PoC.
Context
The ‘Build it with us’ stage, if used, aims to confirm the solution is commercially feasible and suppliers are viable. At the ‘Implement at Scale’ stage, buying teams should have achieved the aims of all earlier stages, as well as determining whether the solution is viable at scale. Suppliers invited to take part in this stage would be evaluated through co-design processes, further tests and/or detailed plans. In the end, the successful supplier would be contracted to deliver and/or operate a solution.
Buying teams may need to be able to adapt the design of this stage to the nature and maturity of solutions before starting. Just as for the ‘Prove it works’ stage, expectations should be set at a high level only at the initial market approach.
What to cover
The deliverables section at the initial market approach should:
- briefly set expectations by providing examples of what constitutes a deliverable for the future stage
- signal that the final stage will include a Value for Money assessment
- signal that successful suppliers will be invited to submit scale proposals.
Before inviting suppliers to this stage, buying teams will need to define the stage deliverables (and/or final and ongoing deliverables) using a standard specification-based Statement of Requirements.
An example of how this can be communicated at the initial market approach is below.
‘Implement at scale’ example – Implement solution
Suppliers of successful Stage 1 Proofs of Value (PoV) and/or Stage 2 Proofs of Concept (PoC) may be invited to submit a Proposal Form for Stage 3 to enter into a contract to implement solutions for the priority use case and/or the identified potential future use cases.
Insights from the PoV and PoC stages will be used to define the final deliverables, which may include licensing, systems integration and/or managed service contracts.
Respondents will be assessed against information supplied in each stage of the RfP as well as information and deliverables for this stage against evaluation criteria for the selection of one or more appropriate solutions for the project. The final evaluation will include a value-for-money assessment.
Documenting timeframes
The timeframes section should cover key milestones and expected timing for the initial stage, including, where relevant:
- supplier dialogue, briefings and/or question and answer sessions
- cut-offs for questions and responses to questions
- tender close
- evaluation period
- contract award
- notification of outcome and invitation to debrief.
In a multi-stage procurement, the duration of subsequent stages could range from 6 weeks to a year depending on the level of testing built into the buying pathway. Therefore, buying teams may need to provide high-level timing for later stages, such as the estimated start and end of each stage, or approximate duration. Buying teams should also include any other noteworthy milestones.
Timeframes can be noted as conditional and subject to change, in which case buying teams should indicate how suppliers will be informed of changes. To make timing estimates as realistic as possible, buying teams should build in time for:
- extended evaluation times due to larger than expected number of responses or more diverse solutions of varying maturity
- longer than expected supplier contract negotiation
- unexpected delays in approvals for awarding of contracts.
Documenting individual stage timeframes for a multistage approach
Expand the boxes to learn more about documenting timeframes relating to individual stages for a multi-stage approach.
Context
When buying teams first write the Statement of Requirements (usually during the Plan phase to support approval of a procurement strategy), timeframes are likely to be impacted by approval timelines. Once the procurement strategy is approved and tender document prepared, the Timeframes section of the SoR should have firm timeframes for the initial stage.
Buying teams may want to move through a first stage quickly and get up-front commitment from suppliers to be available on a particular date. The following example shows how this can be done.
‘Tell us’ example – Proof of Value
Respondents shortlisted for Stage 1 will be required to deliver their Proof of Value on [date]. By participating in this tender, the Respondent is committing to be available on this date.
Context
At the time of writing the initial Statement of Requirements (SoR), buying teams are unlikely to be able to estimate detailed timeframes for the ‘Show us’ stage and subsequent stages. They will need to keep the level of detail low.
When shortlisted suppliers are invited to take part in later stages, buying teams will either provide them with stage-specific requirements or with more detail and certainty about the milestones and timeframes.
For these stages, buying teams should include the following information:
- for each stage, an estimated start date (or month) and duration
- whether stages are sequential or could run concurrently
- when suppliers will receive more detailed timeframes for each stage
- how suppliers will be informed of material changes to timeframes.
What to cover
Below are some examples of how to communicate the timing of later stages at the initial market approach.
‘Show us’ example — Proof of Concept
‘Shortlisted Respondents will be asked to provide a detailed project timeline for their proposed Proof of Concept that meets the key delivery milestone dates in [Table X]. For [one or more] successful suppliers, the project timeline will be negotiated and included in the agreement for the delivery of the Proof of Concept.’
‘Implement at scale’ example:
‘Following a successful Proof of Concept or Proof of Value, Respondents may be invited to quote for the delivery of goods or services at scale. Shortlisted Respondents will be asked to provide a detailed project timeline for their scale implementation that meets the key milestones dates in [Table X]. The timeline will be negotiated as required and included in the agreement for delivery of the goods or services.’
Other key information for a Statement of Requirements
This section helps buying teams tweak other parts of a Statement of Requirements (SoR) when buying innovation. The tweaks make it easier to accommodate an outcome focus (usually a challenge statement) and/or testing through multi-stage procurement.
Buying teams can request an innovation-specific template suitable for the initial market approach by contacting InnovationProcurement@customerservice.nsw.gov.au. They will need to confirm whether their agency supports its use.
Some agencies may only support the use of their standard template. In these cases, the boxes below can guide buying teams through some adjustments for innovation. They may not perfectly match the sections used in templates due to variation between agencies, so some tailoring may be needed.
Expand each one to learn more and access samples from other buying projects.
This section should draw from the procurement strategy problem shaping undertaken during the Scope step. It should give suppliers a clear context for the procurement, including:
- a description of the business function and its key stakeholders
- a summary of the current problem and the benefits of solving it
- the reasons for approaching the market
- information about work undertaken previously such as discovery, trials or historic solutions and reasons why they were or were not successful.
This section is usually brief in an outcome-focused and/or multi-stage procurement. The outputs expected from the procurement are mostly found in the requirements section. This section should clear up any ambiguity about the scope of the procurement and help suppliers understand the scale and type of opportunity. Buying teams should aim to give suppliers clarity on:
- future opportunities to scale solutions to other use cases
- business functions or problems that seem related, but which are not covered by the procurement
- any technical aspects or capabilities that would be provided by the agency and would therefore not be part of the procurement
- whether a complete solution is expected to be delivered, as opposed to services or capabilities
- the type of solution or services, if known (noting that for innovation, it is not recommended to narrow these down too much)
- the level of maturity that can be tolerated (see separate box on Maturity level)
- if transforming all or part of an existing system, which components, functions or integrations are out of scope
- if a solution is likely to need integration, whether the supplier will be responsible for integration or any changes to existing systems.
In multi-stage procurements, detailed information about government environments, complex systems and/or processes might not be shared until later stages. If this is the case, buying teams should note what is out of scope for the initial proposal stage and indicate the stage at which that detail will become part of the scope. Consider using a table to show this information clearly.
This section can give suppliers more information about how maturity of solutions will be considered. For emerging markets, this section can signal an appetite to test solutions with lower maturity and/or unproven solutions. It can also describe co-development opportunities or commercialisation approaches.
A buying team may be open to new and emerging solutions, including suppliers that might not have worked with the NSW Government before. Or they might prefer to limit their scope to more mature solutions. Agencies may reserve the right not to proceed with lower maturity solutions should an equivalent mature solution already exist.
Technology Readiness Level (TRL) is a measurement system developed by NASA to assess the maturity of a particular technology. TRL can be a useful reference for solution maturity in discussions within buying teams as well as in supplier responses.
- TRL 1: Basic principles observed and reported.
- TRL 2: Technology concept and/or application formulated.
- TRL 3: Analytical and experimental critical function and/or characteristic proof of concept.
- TRL 4: Component validation in laboratory environment.
- TRL 5: Component validation in relevant environment.
- TRL 6: System/subsystem model or prototype demonstration in a relevant environment.
- TRL 7: System prototype demonstration in an operational environment.
- TRL 8: Actual system completed and qualified through test and demonstration.
- TRL 9: Actual system proven through successful operation.
Consider supporting suppliers to identify their Technology Readiness Level using the TRL calculator from Investment NSW.
Requirements can be functional (what a solution should do) and non-functional (how it should do it).
Challenge-based procurements should express functional requirements as a challenge statement at the initial market approach. This is best introduced at a summary level in the requirements section, referring to a new section towards the end of the document or a separate attachment, with a heading like 'Detailed challenge statement' or 'Detailed use cases'. This way, suppliers can see key procurement information first.
Non-functional requirements are usually not known in the initial market approach for a multi-stage procurement. This section should signal what they might be and when suppliers can expect more detail. This helps avoid surprises for suppliers choosing to respond. See the separate non-functional requirements box for suggestions.
This section should appear towards the end of the Statement of Requirements or as an attachment, as it is often quite long. It should provide all the detail suppliers need to understand the problem to be solved. A challenge statement is usually defined in detail at the end of the Scope step.
A challenge statement should focus on users and define:
- one or more concise, actionable ‘how might we’ problem statements that define the immediate opportunity that is the focus of the procurement
- a description of the current state and why the problem needs to be solved
- desired outcome, success criteria and measures of success.
The challenge statement may also include:
- use cases that identify the situation, actors and interactions
- personas that describe the core goals, tasks, challenges and feelings of end users
- user stories that identify the value or desired outcomes for end users or personas
- current business processes
- future potential opportunity in terms of expansion or additional use cases
- constraints that might affect solution options (see separate box titled 'Constraints').
Non-functional requirements at the start of a multi-stage procurement are usually limited to terms of participation, rather than solution requirements. However, the Statement of Requirements should, where possible, signal what non-functional requirements may need to be met at a later stage. This is so suppliers can make an informed choice to participate.
Such non-functional requirements include:
- ability to comply with the supplier code of conduct
- ability to contract with the NSW Government, including having an Australian Business Number (ABN) and being registered for GST
- ability to meet key (or high risk) contract terms and willingness to work within the standard contracting framework for the type of goods or services
- registration to the relevant scheme (indicate which scheme, if mandated, and include any requirements in the scheme rules)
- ability to meet insurance requirements (refer to amounts in standard contract or scheme, or specify if different form these)
- demonstrate financial capacity to enter into an agreement with NSW Government to deliver products or services
- be able to complete the modern slavery tender schedule (DOCX, 40.31 KB).
Buying teams can also use the Statement of Requirements to identify other non-functional requirements that could evolve. These might only need to be met for certain solution types. Listing them and signaling when more detail will be provided helps suppliers know what to expect. These can include:
- be able to comply with applicable legislation and standards (include relevant examples e.g. accessibility, personal information)
- be able to comply with the NSW Government's data, privacy and security requirements and provide supporting evidence when requested
- be able to meet specific technical requirements or certifications (include some examples, e.g. any standards, AS EN 301 549)
- be able to support the agency to meet specific policy requirements (include relevant examples, e.g. open data policy, AI ethics, accessibility, local Content)
- be able to store data within New South Wales
- assess products or services against relevant parts of the AI Assessment Framework (if applicable)
Buying teams may need to communicate some constraints to suppliers that are not strictly requirements. Doing this proactively helps suppliers shape feasible proposals and make an informed choice to participate. The types of constraints buying teams should consider covering include:
- information about the IT ecosystem
- constraints of existing systems
- business process limitations
- user limitations
- security access and control limitations
- limitations relating to the compliance environment (beyond those covered under requirements)
- digital maturity or capability of the host organisation
- availability of resources within the agency, including fluctuations in busy periods.
Once more is known about solutions, some of these constraints might become requirements that solutions need to meet to be considered.
This section outlines what the agency should provide to the supplier to support their delivery of goods and services. For a challenge-based and/or multi-stage procurement, this information would be indicative at the initial market approach. More detail would be provided at later stages, once more is known about solutions.
Buying teams should help suppliers know what to expect by providing high-level information about expectations for each stage and indicating when more detail will be confirmed. Buying teams should also consider whether any of the following support will be provided at each stage of the procurement:
- access to buildings and/or office space
- access to systems
- specialised equipment
- business process flows and/or system architecture
- access to subject-matter experts and/or users
- staff support to navigate certain processes
- sample data
- further detail about related use cases and/or problems
- reports or briefings.
This section details what resources suppliers are expected to contribute to the delivery of goods and services. For a challenge-based and/or multi-stage procurement, this information would be indicative at the initial market approach. More detail will be provided at later stages, once more is known about solutions.
Suppliers would usually put forward resource requirements and costing as part of their proposals. In a multi-stage procurement they may need to refine these estimates at each stage. Resourcing might also be refined and negotiated before entering into an agreement for a stage.
Buying teams should help suppliers plan for the resourcing and specific capabilities they might need to deliver against each stage by providing high-level information and indicating when more detail will be confirmed. Buying teams should identify the responsibilities of the service provider, other than delivering the project within the required cost, quality and timeframe. These include:
- specific capabilities needed
- coordination and management of the work
- liaison with agency personnel
- stakeholder engagement
- security
- travel arrangements
- oversight of other contractors
- provision of equipment, software or data
- third party responsibilities in relation to compliance with organisational policies.
Buying teams might ask to see the resumes of staff resources to be allocated to the project to ensure that capabilities meet expectations, particularly for specialist capabilities.
This section outlines where and how each stage is expected to be delivered. For a challenge-based and/or multi-stage procurement, this information would be indicative at the initial market approach. More detail will be provided at later stages, once more is known about solutions.
Buying teams should help suppliers know what to expect by providing high-level information about delivery locations at each stage and indicating when more detail will be confirmed.
Buying teams should consider covering:
- the location of any in-person engagement (e.g. demonstrations)
- which interactions can conducted virtually
- work that can be completed remotely vs on the premises
- any constraints on where work can be completed and/or data stored
- any jurisdiction-specific compliance matters that might constrain location.
Cost implications of these arrangements should also be clear for suppliers – whether covered in this section, or other sections (e.g. agency assistance, supplier resources).
This section outlines how performance will be defined and measured in an eventual contractual agreement. A performance framework is not required for the earlier stages such ‘Show us'. Buying teams are unlikely to have much detail about performance frameworks for the end solution at the initial market approach.
Buying teams should still aim to help suppliers to refine their proposals and plan their resourcing by giving some indicative information, where possible, about how performance could be measured for deliverables at later stages. These are usually covered by contractual agreements. As a minimum, this section should indicate when more detail will be communicated about performance.
Buying teams can consider matters such as:
- how the team will know if the product or service has performed well
- over what time periods performance will be measured
- measurement of delivery such as speed, timeliness, accuracy, completeness or cost of service delivery or work completion, or attainment of progress milestones
- measurement of solution or service quality through Key Performance Indicators (KPIs)
- penalties or incentives
- satisfaction with the level of service or service provider availability
- ability to deliver in the language of stakeholders
- records or other data the service provider may need to provide to support performance monitoring and measurement.
At the initial market approach of challenge-based and multi-stage procurements, buying teams are unlikely to know which pricing models apply to delivery or ongoing support of a solution. They should therefore avoid commercial evaluation at the initial market approach. Once buying teams know more about solutions, they will be in a better position to set requirements related to solution pricing, and to evaluate them.
Nonetheless, buying teams may want to ask suppliers about pricing models for delivery and maintenance of the end solution. This can inform budgeting and/or business cases. Pricing considerations might also apply to early stages if, for example, suppliers are paid to deliver demonstrations.
Buying teams should be transparent with suppliers about when pricing will be requested and how it will be evaluated. This could be presented as a table showing what will be requested at each stage and how it will be used.