Birmingham City Council has come into criticism this week over the development of it’s new birmingham.gov.uk website. The coverage and the chatter on the topic got me thinking: how could public sector organisations commission these big projects in a way that might prevent embarrassing questions? Could large scale public web projects be done in a more innovative way? Here’s what I came up with.
The background – birmingham.gov.uk
An investigation by Help Me Investigate - a crowdsourcing tool for investigative journalism run by my Birmingham School of Media colleague Paul Bradshaw and a number of Birmingham based social media experts – has obtained information from the Council that indicates the web development project is over budget and significantly behind schedule. The investigation has led to reports in the mainstream media, and discussions within social media communities as to the rights and wrongs of this situation.
Reading between the lines
The response by Birmingham City Council to Help Me Investigate states:
“Since the original report the scope of the website has changed in line with technology improvements and the changing needs of the council and its citizens” (see full response).
While this certainly explains why a project might take longer and cost more money it doesn’t excuse the mismanagement of the project. I’ve managed many web projects (admittedly nothing with a budget of this size) and this comment suggests that there were two key problems at the outset of the project:
- Birmingham City Council did not think through their brief fully. They simply got it wrong. It’s hard to believe that the needs of the City have changed so radically since the project was agreed that they would need to increase their budget to this extent.
- The developers did not challenge their client’s brief. Web professionals are paid for their expertise. The customer isn’t always right, and the customer won’t have considered every eventuality of a project: that’s where the developer’s expertise is supposed to come in. Really this is Year 1 undergraduate stuff (certainly I teach BCU First Year’s to do this) and yet it seems to be a perennial problem in these large IT and web projects.
While both parties here are complicit in the resultant problem, there is a more significant issue at play. This scenario, played out time and time again in projects big and small, suggests that the very nature of procurement for websites is broken.
The brief is the problem
Let’s leave behind the Birmingham situation for now, and generalise the notion of procuring a website.
Every project starts with a problem. A need or set of needs becomes apparent to an organisation. Someone within the organisation, let’s call him Harold, will parcel up these needs, and think about what the organisation should do next. Harold will develop certain preconceptions and then use these to develop an inital brief. It may be something as simple as a side of A4 or an email saying what Harold wants to happen. It might even be a comprehensive specification complete with concept artwork and a site map. He contacts some web companies and invites them to pitch for the work. If it’s a big project he might put the job out to tender.
The web companies respond to Harold’s document. The good ones won’t just respond to what’s in Harold’s brief; they will try to work out what the original needs were. They might then come up with a better set of ideas. But the ability of the web company to challenge the brief is restricted the more prescriptive it is. Tenders can be incredibly restrictive. The bigger the project, the more restrictive the tender is likely to be (in my experience).
Once the project has started it is always structured in terms of that original specification that Harold put together. As the project develops, Harold’s real needs come to the surface and the web company come up with better ways to answer the problem than Harold ever could have come up with. Other issues come up, and the keen designers and programmers at the web company spot new opportunities to help Harold out. This is when we get scope creep, or changes to the brief. This is when the project gets delayed, and becomes more expensive.
Let’s buy developers & designers, not websites
So if the root of the problem is the procurement process, what would I suggest instead? I’m going to be completely idealistic, and I do realise that there are quite huge barriers to this sort of change, but I have an answer. Here’s a manifesto for better procurement of web projects (it would work for IT projects and service design too):
- Let’s focus on needs and the original problem, not best guess briefs by well meaning non-experts.
- Let’s be aware from the outset that your best guess cost is going to be wrong, and the project will be late.
- Let’s allow for changes in a radical way: not just contingency days in the spec, or a change management process.
- Let’s budget for innovation.
- Let’s open up the project and let users shape the end result.
And based on that manifesto, here’s my solution, based loosely on the Birmingham City Council Project (£600k to deliver a project in seven months):
Throw away your specification. Hire the brightest freelancers you can find who care about your service. Tell them the project should take two years, but give them six years to do it. Let them find out how your organisation works, how your users want to speak to it, and build the tools you need. Support them in every random avenue they go down. Some will not work. One might be the best idea you never knew you needed.
I said it was idealistic, but it is possible. We operate this way, on a small scale, on the AHRC Knowledge Transfer Fellowship and it works. When we sit down with partners, we discuss what their organisation is doing, and how we could use the web to do that better (or to do something completely new). We then get together some really simple web tools and put together a prototype. The prototype may be rough and ready, but it means that the partner can see what the solution might look like. They can speak to people about it, test the idea, and then go on to do it bigger and better (bringing in a web development company). We call the whole process “knowledge transfer”. A web based tool is the smallest part of it: the real value is in finding a problem and making it into an opportunity.