There’s been a lot of support and also debate following my blog post to clarify what is government policy on the best way to deliver IT services.
I thought it would be helpful to provide a follow-up post to go into a bit more detail in some areas.
A colleague of mine recently provided feedback that I like to blog when I notice I’m having the same conversations with different people. Of course making things open makes things better, so when I realised my team and I were each having to provide advice to both suppliers and departments on the best way to disaggregate services as outlined in the service manual, it was time to publish some more detail.
Transparency
We have always been open, but publishing guidance on the internet through a blog is more transparent and accessible than the other channels we’ve been using over the last couple of years (like speaking at conferences). Using the internet also makes it easier for anyone to peer review, discuss and challenge our work, something we always welcome.
Transparency is also crucial if we are to deliver great services to our users (whether inside or outside of government). We, as the technology profession, need to be transparent in communicating to suppliers what we need to build and run those services. This means having fully open conversations and transparent transactions like those through the Digital Marketplace.
Capability
A lot of comments rightly pointed out that capability is key to making IT services work - I couldn’t agree more. As we’ve always laid out in the technology code of practice “adequate capability should be in the organisation - you shouldn’t outsource strategic decision making or service accountability”. As we have historically outsourced a lot of this, growing it again has been a challenge, but one we are overcoming - we now have a great set of digital and technology leaders across government and the GDS Recruitment Hub continues to help departments bring in the right talent at senior levels.
We have also been working to strengthen the digital and technology professions at all levels and a recent example is comprehensive guidance on the digital and technology skills needed to deliver digital and IT services that meet user needs.
Building services that meet user needs
I was also quite interested by the different interpretations in the debate of what is a tower model. To me this highlights the problem of following specific named models, rather than focusing on the substance of what is needed and working out the right way to buy it. Cutting things into arbitrary ‘towers’ is unlikely to get you the right result, in the same way that cutting things into arbitrary small pieces won’t work either. The right size and model will be different for different components. I’m probably repeating myself here, but for some things you might want to purchase them as outsourced services (for example infrastructure), others might be bought as off-the-shelf solutions and some you may want to pay to be developed.
The debate shouldn’t be about different fixed models (and certainly not what is the government model), but how do we, like any other service-orientated organisation, build and buy services to meet the needs of our users? IT based around services, not departmental or contract silos.
Avoid lock-ins to long-term contracts
We should remember that because technology evolves quickly we shouldn’t lock ourselves into long-term contracts. No one can accurately anticipate what we will need to provide our services in 10 years’ time and shouldn’t try to contract for it. Likewise technology will evolve more quickly than a long procurement project to outsource towers.
Our digital marketplace strategy outlines how the Digital Marketplace will stimulate a responsive, evolving market, giving buyers who are transforming public services access to the services they need. We will make it easier to commission to meet user needs and build stronger communities, connecting people transforming public services with relevant experts and resources to deliver the right project outcomes.
In Government we know that we have over-outsourced in the past and moving away from that lock-in is taking time. We will always be pragmatic about how we move away from our legacy and towards a set of services built around our user. We are continuing to evolve and we look to our service providers to do the same.
You can follow Alex on Twitter and don’t forget to subscribe to the Government Technology blog.
3 comments
Comment by Mike Glendinning posted on
Obviously we should not be following a single fixed procurement model blindly without ensuring it is appropriate in each case. I believe there has been a need for more specific guidance in this area for quite some time.
The fact is, however that most complex information services have more than one set of "users" (stakeholders). Those that procure, develop, supply, operate, assure and maintain our services also have valid concerns, needs and requirements. In my experience, focusing on the needs of just one stakeholder community is a recipe for disaster.
Although it may be fashionable to believe that merging "agile" Web software development with techniques from "DevOps" is sufficient, this tends to ignore the wider range of stakeholders and differing needs of more complex information services (e.g. stability, safety) as well as the constraints of procurement in the public sector.
I suggest that GDS would be well advised to explore what can be learned from the best practice of other techniques such as systems engineering and enterprise architecture planning before issuing further guidance on this topic or embarking on the development of such complex information services.
Comment by Alistair Fox posted on
Alex points out that they are recruiting skills to address the new paradigm of IT development in the public sector, but looking at his own experience and that of his colleagues there is a danger that there is a lack of implementation experience in projects - large and small. It's great that they are being open about the policy but blogging isn't the same as providing the service. I can't help being concerned that they are creating a great government IT organisation when government's remit is, as Alex emphasises, to meet user needs.
It's not true that government is "like any other service-orientated organisation". Most private sector organisations will lose customers and go out of business if their IT systems are a disaster. Government won't. So there should be a real emphasis on ensuring projects are successful and cost effective. The later is not achieved by creating a huge internal IT organisation.
And whilst it is true that government has "over-outsourced in the past" that is partly because government was not great at delivering IT projects internally. The real problem was not the level of outsourcing but the type - rather than multi-sourced solutions they bought into massive bespoke projects.
As Mike Glenndinning points out, whilst the technology is moving fast there are some basic requirements and methodologies that should not be overlooked.
Comment by Rohit Bisht posted on
Two things i want to point out:
1. Avoid Lock-ins to long term contract: If we do this then how can we protect the rights of the companies who is working on any project. At any given time one has right to cancel the contract and move with the other service provider? I think there must be a system in place that should take serious actions when project not delivered on time rather avoiding lock-ins. Some projects are time taking and i think dividing a project into multiple milestone will be a solution to this one.
2. Over Outsourced. Does it mean Government is looking for an in-house team for the current and upcoming projects. It includes a lot of time, manpower, infrastructure, resources and various other things. Managing all these would cost time and money. We can monitor the outsourcing and outsource wisely.