In the previous section, we outlined some of the different procurement tools that can be used to drive innovation in London borough procurement. Here, we describe the general principles and techniques that be used to optimise any technology procurement: striking the right balance between innovation and compliance. Again, our key takeaway is the same as in the last section:
<aside> <img src="https://s3-us-west-2.amazonaws.com/secure.notion-static.com/0e092271-756d-4344-aeb1-2670ce665c1f/Ellipse_2_(2).svg" alt="https://s3-us-west-2.amazonaws.com/secure.notion-static.com/0e092271-756d-4344-aeb1-2670ce665c1f/Ellipse_2_(2).svg" width="40px" /> For any procedure, the most important thing when procuring innovation is to be as flexible, agile and responsive as possible. There is scope within each to be a dynamic, supplier-friendly buyer!
</aside>
Responsible - Procurement Teams Procurement teams are familiar with outcomes-based procurement, and usually have experience of executing a procurement that could be described as 'outcomes-based'. It is is their job to take leadership and drive commercial innovation across the organisation.
Accountable - CIO / CDO The CIO / CDO and their technology team should work with procurement teams to help them understand what a 'technology-optimised' process should look like, and how to best test and evaluate the market.
Consulted - Service Teams Service teams should also think about how they can support more flexible, outcomes-based procurement. This includes sharing information about user needs, target user groups and success metrics across the organisation, and feeding it into the procurement.
On the previous page, we have described some of the under-used procurement procedures which can be used to promote innovation. On this page, we outline how, using any procurement procedure, boroughs can make sure that their approach is optimised for technology
<aside> <img src="https://s3-us-west-2.amazonaws.com/secure.notion-static.com/0e092271-756d-4344-aeb1-2670ce665c1f/Ellipse_2_(2).svg" alt="https://s3-us-west-2.amazonaws.com/secure.notion-static.com/0e092271-756d-4344-aeb1-2670ce665c1f/Ellipse_2_(2).svg" width="40px" /> Technology procurement checklist
</aside>
[ ] Use a procurement tool that is proportionate with the complexity of the required system
[ ] Consider how a tender 'looks' and 'feels': is it something that tech companies would want to apply for?
[ ] Where possible, ask for presentations, decks and product demos, instead of long written answers
[ ] Clearly outline integration and interoperability requirements up front, but only specify requirements that are really need (see our Interoperability Guide for more information)
[ ] Start with a clear outline of who the users of the service will be, what their needs are, and user research done to-date (many procurements through the Digital Marketplace do this effectively, including this recent housing procurement from Hackney)
[ ] Use outcomes rather than outputs wherever you can, and only make technical specifications where you have to
[ ] Consider how you can 'phase' a procurement, so good ideas from the market can be refined and improved: pilots, contests, dialogues and innovation partnerships can be effective here
Outcomes-based procurement is a concept that is familiar to all procurement teams: but it is difficult to execute in practice. And, further, a full 'outcomes-based' approach is not always proportionate and appropriate: a good procurement should find the right balance between outcomes and outputs. However, outcomes-based procurement is still not as common in London boroughs as it should be, so we encourage more procurement teams to consider when they can do it.
The concept is helpfully explained in Croydon's contract management handbook (go to page 26 for more detail):
<aside> <img src="https://s3-us-west-2.amazonaws.com/secure.notion-static.com/0e092271-756d-4344-aeb1-2670ce665c1f/Ellipse_2_(2).svg" alt="https://s3-us-west-2.amazonaws.com/secure.notion-static.com/0e092271-756d-4344-aeb1-2670ce665c1f/Ellipse_2_(2).svg" width="40px" /> Outcome specification: A specification that determines only the desired result (sometimes called a performance specification). The contractor is given the flexibility to decide for themselves exactly how those outcomes should be achieved, using their own specialist expertise and competence to determine how best to manufacture and supply the goods or provide the service. Consequently the contractor bears the greater share of risk in this regard. Tend to be shorter, more succinct documents, because they only set out what is required from a product or service, rather than prescribing in detail how the contractor should go about delivering it.
Output specification: Descriptions or measures of a program’s activities. See outcome specification above – outcomes are the results or changes resulting from outputs.
</aside>
.svg){kind=link}