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.
This is a good post Jon. I’m not so sure about saying two years and allowing six, because that could also be construed as allowing mission creep; but I do agree that resources for such a project should have ample breathing space.
I’m going round in circles myself trying to figure out how best to commission the rebuild of quite a large website: who needs a say, and how are the various voices most effectively reflected?
I certainly don’t think that focussing on ‘the needs and the problem’ is idealistic: it’s pure common sense to me.
I’ve certainly seen this problem arise a few times in my career so far. The main problem always appears to be communication and the lack of it. As you say, a client puts together a brief and people pitch for it. A lot of the time the pitches are simply “here’s some design ideas” and it’s going to cost you this much. Unfortunately very few pitches actually challenge or add to the brief due to a lack of knowledge about the client and their needs and this is where everything starts to fail already. Ideally the pitch needs to be seen as the beginning of a much larger conversation. That conversation needs to last the whole length of the project. So the big question is how to make this conversation much more fluent.
I think your suggestion of throwing away the spec may be a bit extreme, but certainly it needs to be a heavily cut down spec, to give more freedom to the devs and designers, and to only be seen as a starting point.
I am a big fan of the idea of releasing early and often. This gives the client plenty of time to see functionality and say, “That’s good, but if you could make it do this, then it would be great!”. To do this the project needs to be broken down into much smaller pieces, or iterations. These iterations can then be broken down into smaller user stories. At the end of each iteration the client and dev team are expected to review the iteration to decide the user stories for the next iteration. This process brings about a continuous conversation between the client and the team, so at no point does anyone get left out of the loop.
A really important idea for the client is to give the ownership of the project to a small group of individuals. This stops the problem of too many cooks. Clearly if some other expertises are needed later in the project, then someone else from the clients team can be drafted in, but this should only be for the particular iteration(s) they are needed on.
I could talk about this for ages, but if you want to read more, then I’d suggest reading about Agile development processes.
Yes this approach does lead to the potential of the project changing massively from the original brief, however that’s more than likely not a bad thing. Also it means the devs & designers are going to learn more about their client and thus will be able to offer more guidance to the client and the project.
In short, stop hiding things from the client. They know much more about their business and it’s needs than the devs / designers. Get the client involved in everything.
Great write-up. I wouldn’t want to take away anything from your manifesto (you said it was idealistic, so it would be unfair to quibble). But there is one thing I’d like to add.
It seems to me the missing piece in all of this is lack of deliverables. The project was due to run for 7 months. If something had been delivered then it would have been quite acceptable to extend scope and budget, because they would have been able to say “look, we’ve produced something, and now we’re going to produce more”. Then the scope creep would clearly be additions, and the budget creep would be explained clearly. And it would give control to the client who can then walk away after any deliverable.
But a project which was due to complete in 7 months and still hasn’t delivered anything after 33 months…? As long as there are no deliverables in a project the suppliers will have the client held to ransom. Plus, of course, it will look more like mismanagement than a well-considered extension.
So, to add to your manifesto: Regular, timeboxed deliverables.
However, I fear this doesn’t fit with your ethos of being idealistic. It’s not idealistic. It’s called Agile, and it’s practised widely and successfully today. How dull.
@Michael
I’d put some milestones in place that would prevent too much creep, but keep those as flexible as possible. [while I've been writing this two comments have come in about Agile development and phased projects - thanks guys]
The number of years is pretty arbitrary. What I’m getting at with that is if you hired a bunch of bright people, even at full economic cost (desk, light, heating, salaries) you could get years of extra projects for a budget in the millions.
The key thing here is that a budget could (should?) be set at the outset that is affordable to the organisation. Clearly in the Birmingham instance BCC had £2.8 million of budget not £600k. They can;t just magic the extra money from somewhere else. Let the budgets dictate the projects and get as much done as possible, then no one can ever ask why you overspent.
We seem to accept the fact that projects and budgets creep, but we don’t do anything about this.
Sounds like BCC needs to embrace agile development practices – and that will require the leadership to champion it from within. Monolithic bureaucratic organisations don’t tend to be that keen on lightweight project management
.
The root of the problem isn’t the procurement process itself, it’s the attempt to use procurement for old-skool software development contracts – to have everything specified upfront for a fixed sum over a fixed time – coupled with a “command and control” mindset. Agile methodologies place much more trust in the developers and specifically embrace the ideas that requirements change over time and that the client often doesn’t really know what they want until you show them something.
Call me cynical, but I’m not convinced that you can easily hire freelancers who care about your service to solve the problem without also implementing some project management – after all, the freelancers will also care about the fact that you appear to be willing to pay them per day until they reckon the project’s finished
.
I think Nick and John P make very good points about deliverables and early release. It’s a trap I probably fall into myself quite often by being afraid of not getting it right.
I know exactly where you are coming from with this article (having worked with you on our fair share of nightmare tender proposals in the past I share your pain).
I think for the most part you hit a nail on the head- the issue of seeking a good brief from a public sector client is akin to Jason’s search for the Golden Fleece. I would love to think that over time that a good brief will develop from something mythical or impossible even to something more mundane- a clear concise brief with a realistic schedule, realistic budget and realistic expectations.
However, I disagree on a couple of points:
1) Projects of this scale _do not_ have to go off schedule, off budget or scope creep- the simple fact is good solid project management and most importantly managing the expectations of the client so they don’t get carried away are essential to a well run project. Make sure from the start what the rules are and don’t be bullied into backing down should this change. There is an attitude in this country it seems where we expect delay, we expect every public funded project to be painful, but it doesn’t have to be that way. Made have worked on many public funded projects that have gone (mostly!) smoothly so it is possible.
2) Your solution is way too idealisitic, sorry mate. The idea of giving an open purse to some freelancer who “really cares” about a public service and letting them go off on the crazy train to develop new wacky tech is enough to give me nightmares. I’ll admit public tenders do tend to be on the restrictive side, but what you are proposing is tantamount to web anarchy with public money. There are simply no guarantees that pursuing every avenue might ever lead to anything decent. We’ve all met I’m sure our fair share of freelancers with ideas who lack nothing in passion but who when push comes to shove simply cannot cut it in the real world. Erdogan Haas, Jon. Nuff said…
3) You can’t future proof everything- giving someone an open-ended timescale is a bit pointless as you are always to some extent trapped by current web specifications that are ever-changing- screen size, Flash version, browsers used, accessibility issues- assuming that your passionate freelancer could keep coming up over this lengthy project period with new and relevant ideas that also worked in the context of the CMS, site design etc seems a bit too much to ask.
I think you raise some good points though and glad you’ve covered this subject as we think it all the time- only this week I had a ridiculous tender invite where they wanted 4 designed pages, an illustrated walkthrough plus “any other pages you’d like us to see” and this just to start with! Erm, no- hows about instead I go and win some work from people who don’t think I’m a complete mug with nothing better to do than pontificate over their insane tender…
A really interesting post with some equally interesting responses. Is there really a definitive answer? I’m not sure about the 2 years and 6 years to develop. There is an old adage which is build to the specification and then build what they actually need.
Good specification, agile development, clear communication, project board, clear roles, effective decision making the list goes on. All can help but is there really a definitive answer?
Just a quick one – no time to read the other comments, but from experience of public sector tendering if you don’t match the brief fully in the pre-qualification stage then you have no chance of getting shortlisted. So the larger the project, the smaller the chance that the commissioned web company will have to influence the brief they are responding to?
Also – from what I know from this investigation, I think that all (or at least a lot of) IT procurement by the City Council now has to go through their joint venture company Service Birmingham, which is part BCC and part Capita.
Does an authority as large as BCC need a single unified site? If departments could commission their own sites…
Thanks for all the comments.
Stef makes good points re BCC procurement and relationship with Capita, but let’s not be limited by actual circumstances here (remember I’m being idealistic here… using what in horrible management speak would be “blue sky thinking”). Also I’m keen to think about the bigger picture.
I just wanted to pick up on a theme from amongst some of the comments:
Do we really think it is too much to ask for some idealism from web developers and designers?
Why can’t we expect the designer of a website for a public agency to care about the services that are being delivered?
I’m pretty sure that for everyone in the industry chasing money to buy the latest apple gadget or new media trainers, there are people with a real desire to produce work that has some social benefit (while also earning good money).
I really think that you have to become a team, your team and the clients team. Working together, solving problems and helping each other out. We’ve completed a number of public sector projects and the key success factor has been having a great relationship with the client. We work with our clients and not just for them.
Without the good relationship a lot of the process stuff falls away.
Maybe someone should create a TV programme – “when projects go bad”
Really should be bonding with my two-day old child, but couldn’t resist tipping my 2p into this.
Jon, I don’t think the real issue is a lack of web developers caring about the problem. In my experience, the developers and project managers tend to care deeply about the problems they’re solving and feel that they are fighting a daily battle against organisational politics, third-party software vendors, and basic client-misunderstandings to get those problems solved. For that reason all websites are usually a compromise between the ideal, and the practicalities that have to be accepted in order to deliver.
And that last word is key. Steve Jobs said that ‘real artists ship’. Solving the problems in new and innovative ways is nice, but delivering *something that works* is more important. When we work with larger public sector organisations at Made, we sometimes find that delivery is not really at the core of the organisation’s ethos. For that reason it has to be us chasing the client, driving delivery rather than the other way around. That commitment to delivery takes sustained effort and joint experience, which is what would make me sceptical about your ‘hire a bunch of freelancers and give them six years’ approach.
Other than that, what you’re describing is similar to agile software development methodologies. These always appeal to programmers because they saves one from having to think it all through before you start coding. However this methodology is completely at odds with the classic public sector tendering system, which attempts to specify the project in its entirity before even speaking to prospective developers. But then, if you had £600K to spend, wouldn’t you want to know what you were going to get for it before you signed the contract? In addition, agile methodologies do not work well in large political organisations, because they rely on a client sponsor who’s not afraid to take quick decisions when presented with alternatives. Does that sound like Birmingham City Council to you?
Oh sorry, just noticed that I spent some time banging on about the problems, without identifying any solution. This one’s quite simple I think:
Commission a specialist website development company with a track record of delivering complex websites to budget and to timescale, rather than – say – a generic IT outsourcing company.
The irony here is that the reality of the web team putting together the new BCC site is possibly uncannily similar to the ‘ideal’ process Jon outlined.
I’m afraid that much of what is referred to here as “idealism” is not that at all. It is simple professionalism.
There appear to be quite a few errors in the described process here (note, however, that I have not looked at the actual specifics of the project involved; only the references here), the most glaring of which surround what the client is requiring (in their brief or whatever) and how an agency responds to that. The client has no business whatsoever prescribing what should be built and how and the agency has no business responding to an RFP or public tendering of a brief as requested if the requests or details are inappropriate.
The client should simply detail the problems or challenges they need to address and describe the desired result of the project, along with their budget for doing so. In other words, detail what needs to be fixed, not how it should be fixed. It is for the agency to detail the process and components; for they are the experts in this regard and this is their responsibility! If the agency cedes their responsibilities to the client, the project is lost from the beginning. In such cases success is improbable at best and likely impossible. This practice is highly unprofessional and should preclude their being hired in the first place.
It is for the agency to say how long the project will take, according to the requirements, not the client. It is for the agency to determine the client’s involvement in the specific project process components. Unless the agency runs the project, the project is doomed no matter who the individuals are. Unless they are an agency themselves, the client is not in the business of running design projects and will always do so wrongly. An agency or individual who allows the client to run the project is unqualified to be involved. Professional practice demands professional responsibility. And professional standards are not standards if they are negotiable.
The deliverables should be defined at the outset of the project before contracts are signed. If the project is so complex as to make this impossible, only those portions of the project where deliverables can be defined should be contracted …and subsequent portions of the project approached as separate projects as circumstances allow that they can be clearly defined. To do otherwise is to trade professionalism and wisdom for idiocy and guesses. Poor form.
Pingback: Website to cost £2.8m?! « The wonderous world of Adam…
“The developers did not challenge their client’s brief.”
I suspect the reason for that is that Capita were going to get paid however vague the brief. In fact, the less well-defined the brief, the greater the chances of billing extras later on- “Oh, you didn’t make it clear you wanted that- it’s not in the brief.”
So the developers actually did deliver for the people who pay them: They’re employed by Capita and Capita made more money.
The issue with outsourcing IT is that you outsource the expertise you need for sensible procurement to the people you’re procuring stuff from. So you end up more or less with them specifying what you’re going to pay them to do.
Sure, the project costs over-run, but senior people smugly point to their shiny outsourcing agreement and make the point that it’s saving them money somewhere else. It must be- after all, that’s why they agreed to it.
These ‘partnership’ arrangements like Service Birmingham are particularly awful for this, because the council thinks it’s got some cosy, mutually beneficial arrangement that’s much better than just contracting out a service. Meanwhile, the partner nudges the profits up here and there, while delivering the headline ‘savings’ in the agreed areas.
With a normal contract, you can eventually dump an underperforming supplier and get a new one. With a partnership agreement, the tangle of joint arrangements makes getting out a near-impossible nightmare. Which is why Capita like that sort of thing.