Ts and Cs for a local gov tech tender

Eddie Copeland, head of the London Office of Technology and Innovation, reports on a recent call for ideas on what councils should demand in a technology procurement

Back in November 2019, the London Office of Technology and Innovation (LOTI) launched City Tools: London, a database of London boroughs’ major IT systems, contracts and internal technology skills.

A key aspiration for this initiative is to back up anecdotes about what’s good and bad in local government tech with some real evidence. For example, based on data collected to date, the City Tools insight report highlighted that 91% of London local government’s technology spend goes to just 15 suppliers. Furthermore, those boroughs using the fewest suppliers have the highest levels of dissatisfaction. Both points are concerning.

In a LOTI project led by Waltham Forest’s Paul Neville, it’s been clear that boroughs experience a number of common challenges and frustrations with certain technologies and a small number of suppliers. As a result, there’s an appetite to establish some common terms and conditions that could go into every technology related tender and contract to ensure those shortfalls are designed out of future procurements.

With this in mind, I recently posted a tweet asking for ideas for what should go on that Ts and Cs list. Below is my attempt to curate what you said.

(I apologise in advance to anyone whose comment I may have accidentally missed or misrepresented. If you spot omissions or errors, please let me know and I will happily update this article.)

The Local Gov Digital Procurement Checklist

To kick things off, I’d like to thank Paul Oesten-Creasey for pointing me towards The Local Gov Digital Procurement Checklist. It was created by Alastair Parvin and Euan Mills and has contributions from lots of smart people including Gavin Beckett and Gary Todd. It’s still open for comment.

In essence, it sets out a supplier code of conduct, with measures including:

• services should have an open API;

• public data should be public;

• personal data should be personal;

• no advertising (on the services themselves);

• right to data;

• easy to exit;

• inclusion by design;

• secure by design;

• seamless user experience;

• transparent;

• no discrimination;

• use open standards;

• no long lock-ins;

• and no bundling.

The document provides full details on what is meant by all these headings, including examples of what good and bad look like.

Cards on the table, I think it’s brilliant. You should read it.

More terms and conditions

Supporting the ideas above, and offering a range of additional requirements, here’s what else the respondents said was important:

1. Provision of open APIs — This was top of my own list and echoed by Jason Kitkat, who added his wish for “documented APIs according to standards where available.” John McMahon got specific, saying: “Full access to data is a good start. Ideally, a service should: have APIs that conform to [GOV.UK’s] API technical and data standards (v2–2019); APIs should be able to get, post, delete providing the functions of the back office; webhooks can be added to maximise interoperability with other apps”.
2. Adherence to open standards — This came up a lot. Chris Thorpe suggested adopting “open standards for data models, such as those from http://schema.org”. Chris Francis added: “The key is standards… Some sectors have vital established non-open ones.” Julian Tait also pointed out: “There are standards that favour a particular commercial offering and open standards developed to enable a plurality of solutions.” Preference should be given to the latter.
3. Demonstrable adherence to the Service Standard — Dave Briggs, Dominic Campbell and Ben Unsworth shared thoughts on this one. This would particularly include things like the use of open standards, data portability and clear evidence of having done user research.
4. No exit costs — Proposed by Chris Francis. The need for an easy exit was also highlighted by Julian Tait, who commented that public sector organisations need to have something that “de-risks the option of transitioning to an alternative solution at the end or cessation of contract.” Reflecting on this, Adam Jennison pointed out the challenge that: “Procurement rules state that we must test the market every X years. The cost of retrieving, converting and cleansing data from system X to system Y is usually a magnitude more than buying system Y”.
5. Ownership of all data, including resulting AI models — Proposed by Steve Parks, who added: “It’s so important the data doesn’t get privatised or exploited privately beyond its public use”.
6. Access to full developer docs — proposed by Chris Thorpe.
7. Joint ownership of any intellectual property rights created for the implementation — proposed by Simon Reed.
8. No bundling — Proposed by Will Squires, inspired by Alastair Parvin.
9. Open source solutions by preference — This was proposed by several people, including Chris Thorpe. Jason Kitkit added: “If not open source, then at least any new development done on one authority’s behalf [should be…] offered to all other clients at no additional cost; aka no double-dipping.”
10. Ability to co-design — Proposed by María Paz Hermosilla and Roz Davies.
11. Environmentally friendly hosting — Proposed by Chris Thorpe. Chris Adams went further, suggesting that contracts should have “embedded and expected carbon emissions in all spend, to track progress publicly against national targets. This is still a colossal knowledge gap, but there is data from the ONS to get ballpark figures, and suppliers like AWS, Google and MS report emissions intensity already.” Anne Currie went on: “Agreed. Tech is a major user of power so I’d want to know what steps the supplier was taking to ensure their server energy use was renewable.”
12. Accessibility — Carrie Bishop said tech “should work for everyone including those using assistive tech, or those whose first language isn’t English”.
13. Freedom to repair — Proposed by Paul Allen.
14. Cost of tech not to be passed on to citizens — Sarah Schacht was keen that no additional fees should be charged when using a service that is just for the tech platform.
15. Easily ports out data for public disclosure requests — Proposed by Sarah Schacht.
16. Allows for local usability testing with staff and citizens of the product prior to purchase — Proposed by Sarah Schacht.
17. Secure service management processes — Proposed by Chris Francis.
18. SaaS to mean SaaS — Chris O’Connor explained this means having a “subscription and not a five-year contract”.
19. Transparency, accountability — Proposed by Roz Davies.
20. Social value — Also proposed by Roz Davies.

Thoughts on the procurement approach

Some suggested ideas that are less about the tender specification itself, and more about the procurement approach.

Carrie Bishop made the comment: “On a practical level, there are so few companies with solutions that meet the criteria in these replies [to my tweet]. As a budget holder I would settle for a commitment to meeting the criteria within the first year of the contract. i.e it had better be on your roadmap.”

I asked Carrie if she made this a contractual condition, to which she replied: “Firm assurances mostly, as I generally don’t enter into contracts with vendors I don’t trust. I think about it as buying a relationship rather than ‘deliverables’ as I want partners not scapegoats.” This feels like good advice.

Andy Sandford suggested that public sector organisations should “include full details of what the organisation is trying to achieve as outcomes rather than loads of requirements and… consider holding supplier days to explain in more detail and allow challenge/questions”.

Software developer Tim Hobbs agreed, pointing out: “Too many requirements we get are actually half baked solution designs or lists of functionality, rather than invitations to help solve a stated problem.”

Gary Stuart suggested that public sector organisations need to make “A tangible link to operational requirements, lots of tech is bought because it does great things in great ways, but often how the investment directly helps is less clear.”

Dave Page advised public sector organisations to avoid “the #microservices buzzword”, suggesting we need “modular design with documented APIs between components, allowing them to be replaced individually”.

Paul Connell recommended doing three things: “Publish a story blog of why and what you’re doing; publish a technical blog of how you did it; publish the data and code (if possible) you used in an open repository.” He added: “Tag it as #OpenGovTech so anyone can find it on the web.”

Offering his own list of three, Will Squires requested that procured tech should be: “Accessible to the layperson; harnessable by the technical expert; data/back end as well as (or over) front end focused; community and user led.”

James Trotter stated the need to ensure “SMEs have a chance to be part of the process. Often LG procurement documents preclude SME/Start-ups from participating due to onerous conditions”.

In a similar vein, Mark Williams said that adding “lots of ‘general’ T&Cs is unnecessary and detracts supply” He went on: “Key terms should align to what is bought e.g. terms for service outsourcing, different from building apps. That said two things — be clear on outcomes/measurement — exit arrangements/cost.”

Striking a more dramatic note, Kevin Monk advocated that we: “Dump current procurement practices entirely. Allow a panel to make a subjective judgement. Not everything that matters is measurable and not everything measurable matters. The whole thing is a sham and we all know it.”

And on that uplifting note, may I thank all those above for their contributions. We’ll be discussing these suggestions with LOTI CIOs and CDOs later this month and will keep you posted with developments.

In the meantime, I’d welcome your reactions to the above. And if you’re a supplier, what would be on your list of asks for local government?

This article was first published through the LOTI blog on Medium. LOTI is part of London Councils.