The Digital Services Framework is not fit for purpose

Among the government’s most important priorities is the delivery of a new breed of digital by default public services. This is vital work: it’s not just about making services simpler, clearer and faster. It’s also about making them cheaper, so that we can focus our spending on front-line resources. For some public services, it’s of existential importance. Many will struggle to operate sustainably without technology reform, and that’s something that must be addressed.

The Government Digital Service have made extraordinary and inspiring progress towards this goal, but there’s still a long way to go. And supplier companies are a part of that solution: the problem is too big for any one organisation to tackle alone. From individual services to government as a platform, companies will fill in bits of the picture, providing skills, products, and gubbins in close collaboration with technical and user experience experts inside government.

But nobody wants to repeat the mistakes of the past where large, expensive, inflexible companies on long contracts dominated the market. Government wants SMEs to be 25% of its supply chain: smaller suppliers on shorter contracts, who can do more with less. It wants to embed agile principles and work with suppliers that share them.

A new breed of suppliers to the public sector is growing, based on this need: dxw is one such company. But if the whole of government is to be digitally transformed, we’re going to need more. Supporting the growth of the suppliers that government needs in order to succeed is therefore a critical part of its future success.


One of government’s most successful technology programmes is the creation of the G-Cloud framework. Its streamlined approach makes it quick and easy to procure agile development and cloud services, helping government teams to start delivering quickly. It should be a model for procurement reform across government. But instead, Crown Commercial Services (CCS), who own both G-Cloud and DSF, have removed agile development from G-Cloud, making DSF the sole remaining procurement route.

This is problematic, because DSF is a flawed, failed framework.

DSF divides developers, designers, user researchers and delivery managers into different lots. The vast majority of good companies supplying these services will have people in all of those roles, and generally, those people will work together as a team on many projects.

But that’s not the way DSF works. On DSF, you might win one lot in a project and no others. Developers, but no designers. It’s a way to buy people, not projects. The framework is essentially a mechanism for body-shopping, which is just not workable for most suppliers.


A good company is more than the sum total of its staff’s linkedin profiles. As big a part of the quality and effectiveness of a company as its individuals are its culture and its shared experience. Its collective sense of purpose and mission, and its corporate memory. And the effectiveness of its teams, based on their trust, friendship, mutual respect and understanding. In dxw’s experience, clients value these things as much as they value our technical expertise.

Taking a handful of developers from one company, some designers from another, a delivery manager from a third and co-locating them in an unfamiliar place, with unfamiliar management and unfamiliar process, hoping that they develop the skills of a strong team and then disbanding them after a few months is short-sighted at best, and unworkable at worst. It overlooks the value that can be gained from a close working relationship with an organisation whose skills and values are complementary to those of the buyer.

Instead of contracting with the companies whose experience and culture match or complement those of GDS, CCS have set up a framework which extracts staff from good companies and assumes that the companies themselves have nothing to offer. This bodyshopping approach might solve a short-term problem, but it does so at the expense of weakening the very suppliers who could be government’s most valuable partners.

In so doing, CCS are actively undermining the growth of the market that society needs. If the whole of government is to be digitally transformed (followed shortly by the whole of society) we will need a whole new generation of suppliers to emerge. Helping this market to grow and thrive would increase the number and quality of companies who can supply agile digital services, improving choice for buyers and quality for users.

Not to mention saving money for taxpayers.


We need a framework that nurtures suppliers who share the culture and approach of GDS, helping them to grow, thrive and multiply. We need a framework that’s designed to serve the user needs of buyers and suppliers who are getting things done.

We need to build on the shining example of the G-Cloud framework, using short contracts, open standards, flexible terms and financial transparency to manage cost and commercial risk. Heavy-handed procurement process should be a thing of the past.

We need to abandon DSF, reinstate development in G-Cloud, and get on with delivering.

Harry Metcalfe


  1. Saul Cozens

    Now I’m no fan of Government procurement practice – and I certainly spent enough time swearing at the DSF2 tender documents (and the horrible portal you have to use), but my travels around various public sector bodies have given an insight about how DSF might be used to do thing right.

    If we start from the premise that digital skills need to exist INSIDE public sector organisations rather than outsourced to agencies, then bodyshopping provides an incredibly effectively way to start the process of getting those skills, filling gaps in teams and introducing new ideas and experience.

    Some of those skills – that are frequently missing from our public sector orgs are around how to buy digital systems and platforms as well as how to build teams that can develop and retain good practice. I believe DSF provides access to skills that complement G-Cloud so that our public bodies are able to better understand when to buy platforms and how and when to build systems and without they will return to the comforting arms of the large systems integrators who promise to take away their all their delivery risks (for a hefty cost).

    Hopefully their will come a day when all of Government understand that developing digital services is not the same as IT, but until then DSF is useful.

    • Harry Metcalfe

      I completely agree about the value of bringing people in to work on site, and its helpfulness in filling gaps in existing teams and changing culture.

      But I don’t think DSF meets that need very well, because the companies it seeks to have on the framework are not ones who are set up to provide individuals on long-term contracts. By and large, we all provide a whole team, to do a whole project (or part of one).

      DSF also doesn’t provide for any other delivery mechanism. It’s bodyshopping or nothing. Which is bad, because although having external staff within your team for long periods can be valuable, it’s obviously not the only way to get things done.

      On the other hand, we have G-Cloud. Its process is a bit rough around the edges, but it’s a proven success, used on many projects to great effect. And it can easily accommodate both approaches. So why are we abandoning something we know works in favour of something clearly less flexible whose first iteration was – by its own measures for success – an abject failure?

      My vote is to have another lot on G-Cloud for dev and let suppliers design the services they provide: if there is a need within government for companies who can provide service design manual roles on long term contracts, the market will surely respond to that.

      And if Cabinet Office want to set some policy that says all dev for government must happen in line with the manual, no matter the delivery approach, I’ll be the first to cheer.

  2. Martyn Evans

    Couldn’t agree more Harry. This is the crux of the matter for me:
    “DSF divides developers, designers, user researchers and delivery managers into different lots. The vast majority of good companies supplying these services will have people in all of those roles, and generally, those people will work together as a team on many projects.”
    These “lots” encourage the silo mentality we’ve all been working so hard to break down. Cross-functional teams working closely together on the same problems have the best possible chance of solving them. It doesn’t mean that you hand over the entire project to an external team. Bring in a “team” and supplement them with your own people but let them drive the project. The best agencies will insist on co-location, establish a great culture around the service, mentor and train your people on the way and be very happy to gradually step away as the internal team grows.

  3. Mike Fox

    I think this comes down to where on the spectrum of disaggregation we want to be

    You may feel that you are a small, agile organisation that shares GDS’s vision, but by aggregating resources up into teams to “add value” how is your argument different to the legacy services vendors? Isn’t that their sales pitch? Where would you draw the line?

    The same applies with Software; don’t procure large integrated systems, buy tools and build agile, solutions with resources from DSF.

    But isn’t there still a place for integrated solutions? Perhaps not in the rapidly changing digital channel but back office systems may benefit. The private sector still buys integrated ERP and CRM solutions as the most effective route to line of business systems – albeit increasingly delivered from the Cloud.

    I think the point you raise is that one size does not fit all; whether that is services, tools or products. However, to challenge the Status Quo, GDS has had to take bold steps and swing the pendulum right across from monolithic offerings to fully disaggregated building blocks. It has downsides, but I guess they thought it necessary to effect the change they felt was needed.

    The question now is, how long will it take for the pendulum to swing back a little and pragmatism triumph over dogma as you propose? Sadly that probably won’t happen until the problems with the current approach are all too apparent!

  4. Chris Gledhll

    Having worked with every variety of public sector procurement and project methodology known to man for over 20 years at both national and local level I find this return to body shopping deeply depressing. In my experience projects on site with inexperienced sponsors and multiple contractors represent the worst of all worlds for a number of reasons:
    there is a lack of commercial accountability,
    suppliers have no real incentive to finish anything,
    there is very unlikely to be any meaningful reuse or investment of IP by the suppliers,
    it inevitably leads to a renewed focus on hourly rates rather than the value created,
    long team maintenance of strategic systems is made incredibly difficult because nobody really owns them….. I could go on.

    Whilst this may seem like a bit of a rant, the truth is that good software engineering is best done by multifunctional teams using well understood tools and techniques. And good value requires clear project accountability, appropriate levels of reuse and a focus on the long term business objectives of the customer.

    Whilst body shopping can be incredibly profitable and low risk for (large) suppliers it discourages innovation and risk sharing and does nothing to support the development of a productive and diverse supplier base in the UK.

Comments are closed.