This guidance will vary depending on the specific suppliers and contract lengths that currently exist in your LPA, but it’s intended to guide your initial thinking when procuring.
Legacy procurement compared to new models
Older and newer procurement models look different:
- The older legacy investment model has newer features like hosting, but is ultimately like investing in a software system for longer terms, and has training and upgrade costs
- The newer browser-based subscription model - is cloud or browser-based, in which users subscribe to a service
Snapshot comparing key elements of the old and new models
What could be offered in the future?
- A place services or built environment framework could be developed with Crown Commercial Services for adopting different services on a modular basis.
- Firstly, however, a central planning register database might be required, as well as data standards for the industry.
Current procurement routes that LPAs use
Considerations for contracts with back-office systems providers
| Item | Considerations | Sources |
|---|---|---|
| Data Handling and Ownership | An exit strategy is important, particularly when considering what happens to data at contract end. | DDAT Playbook page 104 (PDF 110) |
| Intellectual Property (IP) | If paying to build something new with a supplier, ensure your rights are maintained. Integration development work should only be paid for once, and made open to other users. See the DDAT playbook for when councils pay for development of new products or services. | API technical and data standards & DDAT Playbook page 74 |
| Term length | In a fast-changing software market, long investment-style contracts may lock-in users longer than beneficial. A 2 year contract with a year extension option will provide flexibility to investigate newer services. If only a 1 year extension is required, resist supplier-forced longer term extensions, citing the Competitions and Market Authority (CMA). | CMA ESS case of customers being forced into longer term contracts |
| Integration & interoperability | In procuring a back-office system and database, ensuring interoperability is key for taking advantage of new services. Find out if integrations already exist and if there is open documentation on them. | GIIG Information management & interoperability code of practice |
| Cost of consumables | For licences and data storage. There may be hidden costs in data storage so request transparency. |
Resist calls to remove clauses in contracts
In most cases, CCS framework contracts, despite seeming overly long, will cover most of a council’s needs. Resist calls to remove clauses as in many cases they protect the customer’s rights eg, Intellectual Property.
Using non-CCS and G-Cloud contracts might mean signing up to a supplier’s terms and conditions. Ensure data ownership is protected by requesting ‘Arising IP’ clauses to exclude data/clarify what is covered.
Options for procuring open-source software
PlanX and other open source software can be bought in a number of ways. As an open source product, the following options for procurement are available.
- A council pays the original developer or a third-party to install the product on council websites, linking it to a back-office system via an API. This can be done on G-Cloud.
- Hire a digital specialist to install the software. Maintenance and further development of the software is something the council, Open Digital Planning, or the market, will need to resolve.
Considerations for PlanX
LPAs do not currently pay for citizen-facing application services directly (e.g. Planning Portal). This would be another service procured by planning, requiring buy-in from a council’s corporate decision makers and relevant stakeholders.
A case would need to be made on the efficiency savings and how PlanX is also a knowledge product, for example knowledge that planning officers currently hold in their heads can be baked into service flows, and published and updated as code.
Procurement might be uncomfortable with the lack of a party to ‘pin’ contractual liability on if things go wrong with the service (an issue common with open source software). It can be likened to other software ‘tools’ a council might use to assuage these concerns.
Possible future view: procuring modular services
A future place services modular ecosystem could look like this, with all modules that rely on a common data integrating with a council’s planning database via API.
The procurement routes and ‘bundling’ shown are illustrative - LPAs could still purchase all modules on one contract or ‘plug and play’, procuring each software service separately.
Buyers can shape a market by their purchasing habits, although there are internal cultural, technical and corporate barriers to overcome. Data infrastructure would also need to be resolved.
Modular market example
