A little over a year ago, I published a blog post which outlined a vision for showcasing “a different way of delivering technology to the civil service”.
Our aim, I wrote, was “to deliver modern, flexible technology services that are at least as good as those people use at home. These services will also be cheaper than those currently in place”.
We have now deployed the new technology services to more than 2,200 users across the Cabinet Office, the Department for Culture, Media and Sport and Crown Commercial Service, with another 800 or so still to come.
Over the next couple of weeks we are going to blog about how we got on: what worked, what didn’t work, and the learnings that can be taken. I’m going to start by talking about how we chose our solutions.
How we chose solutions
IT projects in government often start with a commercial question: what is the best way to buy some new technology for the best price? Commercial analysis is then undertaken, weighing up whether to launch an Official Journal of the European Union (OJEU) tender or use existing procurement frameworks. Commercial documents are written outlining the technology requirements and a competition is launched. Organisations bid for the work, explaining how their solution best fits the requirements for the right price. All going well, a contract is awarded and the project starts in earnest.
The problem in these scenarios is that no-one asks the users what they actually need or want, so the chance of meeting user needs is slim.
At GDS, we talk a lot about putting user needs first, and we wanted to take this approach with delivering a new set of common technology services. To do this, we broke down the service and product components as far as we possibly could. We then recruited technical specialists (Product Managers) in each area to lead the analysis and delivery of the item.
To make solution decisions, the Product Managers considered the following, usually in this order. The conclusions were put into a light “decision document” and taken to the Chief Technology Officer (CTO), Technical Design Authority, Senior Responsible Owner (SRO) and the programme board for a final decision.
1. What is the user need? Is there a single, consistent need or are there different needs for different user types, or personas?
Example: Do users spend most of their day crunching and analysing big data sets (in which case a powerful computer with two large monitors might be best), or are they on the move much of the time (a thin laptop or tablet would be a better solution)
2. What are the best technical solutions based on the user needs?
Example: So user needs analysis has shown a big demand for fast, open WiFi because people are moving around the office a lot. What are the technical advantages now of Aerohive vs Cisco (or any other) access points? How do the physical constraints of putting WiFi into old government buildings impact the decision?
3. How does each fit into the overall technical architecture?
Example: Our architecture is based on keeping the device build as light as possible to simplify support and keeping services disaggregated, that is, not bundled together. All other things being equal, browser-based applications would then be preferable to apps requiring packaging, updates and installations onto multiple operating systems.
4. What is the best value for money?
Example: User needs showed that users still need to print things out, no matter how mobile the technology. From technical solutions and architectural perspectives, several options were available so we selected the most cost effective one.
5. Does the preferred solution meet government security requirements? We based this on the latest CESG guidance on security for OFFICIAL and OFFICIAL-SENSITIVE, covering cloud applications, end user devices and more.
Example: User research and lab testing showed that Google Apps for Work best meet user requirements around document collaboration and flexible working. It was also a good technical architectural fit and strong value for money. We then spent a considerable amount of time testing the products against published and best practice security advice. This included encryption of data, both in transit and at rest; data storage locations and data processing and handling; compliance with the Data Protection Act; two-factor authentication options, and many other measures.
6. How does the solution meet compliance requirements?
Example: After considering user needs, technical analysis, architectural fit, price and security, the team determined that the Adapt “Infrastructure-as-a-Service” solution was a strong fit for our needs. A detailed assessment then needed to take place to understand things like how long different types of data could be stored, data disposal schedules etc.
7. What is the best way of procuring these products or services through government frameworks to ensure the widest number of suppliers can respond?
Example: Following all of the above, we decided to build a new intranet on the WordPress platform. We then needed a specialist organisation to build, design and configure it for us. Our commercial team searched the Digital Marketplace for a cloud-based solution that met our requirements. Take a look right now: if you search Digital Marketplace for “Wordpress Intranet” you get six great companies in the results, one of which is “Helpful Technology Ltd”, the organisation we selected. It’s really that simple.
So did we end up picking the right solutions? Well, time will tell. What we do know is that the combination of short contracts (we’ve tried to do nothing longer than a year or two) and a loosely coupled architecture means it won’t be a disaster if we haven’t. If London is flooded with 5G next year, we can reduce our WiFi without breaking a contract. If our IaaS provider doubles their prices, we can easily move to another.
All of which is the real point of agile technology.
Follow Tom on Twitter and don’t forget to sign up for email alerts for the Cabinet Office technology blog.
1 comment
Comment by Alistair Fox posted on
Interesting, but I can't help thinking that the examples for the starting point "What is the user need?" are about user 'wants' not 'needs'.
For example, if "users spend most of their day crunching and analysing big data sets" they may need a better report generator, or a data mining or BI tool and not a lot of hardware. Equally, if they are "on the move much of the time" maybe they need access to, and training on, conferencing software?
Silly examples maybe, but IT isn't doing it's job if it's just automating poor processes. Reducing costs (manpower requirements) and sustainability (reducing travel) should be just two of the criteria.