How does a big project fail? A day at a time

Bristol now has a new museum, Aerospace Bristol, which contains a documentary of the growth of the North Fringe Military-Industrial Complex, from WWI fighters to Polaris missile warheads.

It also has a monument to a classic project failure: Concorde.



Because, yes, Concorde is Bristol's most famous transport disaster. People admire the beauty of the plane, it's elegance, its unrivalled speed, but from a project perspective it failed.

1. It came in years late.
2. By the time it was ready, its economics had changed: the 1973 oil crisis had happened.
3. And it turned out that mass travel was more profitable than premium travel for the elite, and that 747s fulfilled the role.

It was a disaster, but now there is a museum for it, rather than rows of Concordes at every airport. Off the new urban sprawl area of North Filton, east of the empty life wasteland that the Cribbs Causeway consumption complex. Not even on the Waze maps —whose postcode lookup directs you into the parking area of a Ford dealer. And in the museum, a plane, along with the other great innovations of the city.

The question we have to ask is: will metrobus join it? While it's not internationally renowed as beautiful failure, it has the "Came in years late" item checked off. Leaving only relevance.

Big projects go wrong. More specifically, they go wrong more significantly, more dramatically and much more expensively than smaller projects. And, of course, the cost of the failure is bigger: the time wasted, the money wasted, the lives frittered away.

So how do big projects fail? A day at a time.

Often its early up-front time which gets wasted the most. That is, with a two year project, the first 6-12 months are the most frittered away. Why so?

Unclear goals/Nobody knows what the fuck they are doing.

When they do start focusing on a plan, and make progress, management usually change plans, not realising the cost. "You've not built anything yet". Software gets this all the time, because there's nothing tangible, but you look at civl engineering projects and you get the politicans deciding to reroute buses and trains "its not been built yet", not realising the penalty of such a decision. Its political whims like that which make public projects worse than private ones. You get whims, but spreadsheets can usually steer them back on course.

People are over-ambitious about what can be done and how it can be achieved.

People just don't realise how rapidly that time gets frittered away. One of the worst troublespots is when the engineers give management a time estimate "it will take 24-30 months if we start today", the managers only hear the "24" , then immediately apply it to the current time "March 2017" + 24 months = March 2019. Then they fuck about talking and finally give the go-ahead after six months, but still expect that "March 2019" deadline to be met.

In a project with a deadline 2+ years out, nobody worries up front about making efficient use of their time. It's extended "what do we do" meetings, people feel freedom to think up "creative and imaginative solutions" to satisfy themselves: personal aggrandisement of their great idea, fashion over a exciting new technology not yet been shown to work, but which suits the project so well. six months to ship and all that stuff has been junked as unworkable and the surviving team members are scrabbling for proven technology with low risk, while cutting back on all the extraneous features "bike paths", "Border between Northern Ireland and the Republic"

At the same time on trying to crank back on the deliverables, the team is cutting corners, usually on quality. Deliverables may be "done", but that's an "unreliable piece of junk done". Which amplifies the problem, as instead of focusing on future deliverables, everyone is pulled into firefighting the short term problems.

The "little details" put off turn out to be big problems

On a really large project, you also suffer from a postponement of examining the "little implementation details" of the project, which turn out not to be so little. The only reason you didn't know they weren't little is that you didn't look in enough detail.

Examples: Discovery you need more of a bridge over a railway line, that you need more tunnels through politically sensitive regions, that you failed to survey the soil your project will be built over, or that there's a border between the UK and EU country where closing it to through traffic will upset local people and cause them to potentially overreact.

There's also one project killer which can happen even if the goals were right and executed properly: by the time you release the goals are no longer relevant. Examples: Nokia's Symbian OS, Blackberry 10 OS.

What are the warning signs?

Failure to define goals, even as project progresses. If its 12 months in and nobody can clearly define the project, you aren't 12 months in. You have just wasted 12 months and your schedule is still going to be "24 months from today".

New requirements being added. This is often a consequence of the delay and attempting to keep up with a changing world. You announce you will be 12 months late and management say "OK, but here's a new change we'll expect to make up for it".

Missing checkpoints. You miss an early checkpoint and you don't catch up. It's gone. When the goals are finally met, work out how much extra time it took above scheduled as a fraction of of the allocated time. and then multiply the deadlines for the rest. Example: if an 8 week milestone is met in 10 weeks, that's a 25% overrun: multiply the entire schedule by 1.25.

Low quality of intermediate deliverables, What does get delivered sucks. This shows a focus on timelines over quality, and will come back to haunt you as quality will only get worse.

Departure of senior staff tasked with delivering it. Especially those with no emotional commitment to the project. Not the visionaries with their grand plans who came up with it, not the people at the bottom for which "it's just a job". It's the more senior people who see the impending trainwreck and think "I have better things to do".

"Unexpected" increases in cost estimates. One or more of: increasing of timeline, increasing staffing, discovery of details they handn't reallised would be so expensive. There's often been a bit of preallocated overrun for "contingency costs", but if that gets burned up early then there'll be need for more.

Rapid changes in the environment which the project is to be delivered. For Nokia and Blackberry, they were: Apple iPhone redefining what a handset was; Google Android saying "in exchange for us collecting personal data from all your users, here's a phone OS and software to compete with Apple"

Now, given these warning signs, the exercise for the readers is to pick one of the following list of projects and see if you can identify all those warning signs.

• Metrobus
• HS2
• Universal Credit
• HMRC customs software needed for brexit.
• Edinburgh Trams
• Brexit

Same fucking signs, every single one of them.

Now, how are such trainwrecks avoided?

In software projects, the general strategy is "don't do this". Big "ocean boiling" projects are very much things to steer absolutely clear of. One or two software consultancies do get involved in them, but they take lots of money and somehow always managed to avoid the blame. Of course, when you are the consultancy wing of one of the big four accounting firms and your colleagues are also the accountants for the company, they'll look out for you.

If you are doing something like this: never say "we're committed now". Just because you've spent lots doesn't mean that the project will work, whether spending more money and time is the correct action. Sometimes it's best to recognise that the world has changed, and the ongoing project isn't relevant. Stop it: focus on something tangible and relevant instead.

That''s just how to get out the hole. The best thing to do is: avoid getting into it.

In software, "agile" development means you do lots of smaller bits of work, with a release schedule of 2-6 weeks, with the goal being "every iteration is a release which puts something into people's hands". There's no more giant release any more, just lots of incremental ones, where features could be some new thing you can do with the code, or just "faster" and "more stable".

With everyone working to a short cycle, there's less of the "three years to go, let's design something grand over many meetings" work, instead pragmatic solutions to current problems. And with that solution in everyone's hands, you can see how it is used and adapt.

As the environment changes, you can adapt on the next iteration, rather than struggle to redefine the grand project -or worse, pretend that reality hasn't changed, and that your work remains relevant.

Ignoring Brexit "don't be so stupid", how does it apply to transport, especially in Bristol?

A key thing: say no to grand metrobus-scale projects. That's underground systems, tramlines, cable cars, etc. They may get everyone excited, but they're risky and not so likely to deliver the benefits promised. And until they ship: useless.

Bike paths, for all their controversy, can be rolled out fairly rapidly, and, if new ones are added adjacent to others, build up an incremental network. That doesn't hold if you just put random bits of paint down where it was least controversial. You do need to have some joined up thinking wth an overall goal "every minor release expands the connected bristol cycle network by 500 metres", and some longer term plans which can motivate people and help define what you are doing in the first place "a way to cycle from Templemeads to the Centre which doesn't abandon you just when it gets scary"

The same for things like footpaths, zebra crossings & c. Pick a mid-term goal "children can walk to school with safe crossings", and work on it by identifying the riskiest crossings, funding zebra crossings, making sure the light timings work, that everyone is stopping for them (i.e. have some police enforcing gloucester road red lights for cyclists on intermittent weekday mornings), that the actions of others aren't hindering things (i.e. have police & council enforcing keep clear and double yellow signs by schools on intermittent weekday mornings).

Roads? Well, what to do? You could present some grand vision of the harbour where the A370 Brunel Way crossing is replaced by something further west, but that will hit up against the pressure to preserve the suspension bridge area, the demand for some for more lanes, for others for fewer, etc. Really, it's not going to satisfy people, so why not look for smaller tactical benefits. At this point some people will be thinking "lets get rid of the bike lanes", but if you look hard, it's often people parked in bus lanes "just for a minute" which cause problems. Special callout: parents doing Colston School dropoff on Gloucester Road. London has embraced the red routes for the "really no parking" roads...yet we haven't. Is it time

Otherwise, well: is it time to consider, if not a congestion charge, a Nottingham-style office parking tax. You can drive through town for free, but you don't get free parking at work. That has the potential to be more transformational to our core than the RPZ has yet delivered. Best bit: you don't need any new bridges or motorway junctions.

To close then: Metrobus is checking the warning signs of classic big project fuckup. Which is obvious to all of us. And so is Brexit. As for the software it'll need, like that HMRC stuff. They have had their deadline pulled forward, the scale of their workload massively increased and still, a year from delivery, nobody know WTF its meant to be managing. Not a chance.