 tied to levels of consistency across deployed instances of each CMS; CMS products allow for different kinds of customisation, with some products enabling higher levels of database structure flexibility to customers. This alters the pathway for managing standard data outputs. 9.6. Proven basis for collaborative tool development The project was able to prove the D2I-championed concept of “Build once, use 150 times” for collaborative data work. Tools and scripts written by one LA can be deployed in other LAs, and a small central resource can facilitate valuable sector-led improvement. Scripts for some lists were developed on one system(T-SQL+LiquidLogic) and others concurrently developed on another (T-SQL+Mosaic). The combination of this effort, and any further developments can now be utilised by any LA. 9.7. Scale as a barrier Our project set out to produce data extract code for five CMS products, and did so for two. A standard is only as valuable as its acceptance rate, and so we hope to continue this work for the remaining three products into the coming year. 23 With smaller market share, these three products offer us fewer potential partners for pilot work, requiring us to work at our partners’ pace, not our own, if we wanted to deliver. We found similar learning in our user research: LAs are all different, and different kinds of LA will have different needs, aspirations, and issues with any new work. Some will struggle to contribute time to innovation projects, while others are well equipped to lead the work; but both must be well served by the output if it is to generate real value. A key learning point is that we must consider the full breadth of LA contexts in data innovation work. 9.8. DfE’s role in sector data development Our work discovered and demonstrated suc