Wednesday 29 November 2017

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.

Sunday 5 November 2017

Volvo bug reports, issue #2; SMIDSY

"Sorry Mate I Didn't See You", as uttered by driver to person they nearly just killed due to failure to properly observe/assess the environment so making a decision based on incomplete and invalid data. Saying "sorry mate" is a way to imply that it was something minor like "sorry I didn't open the door, I didn't see you there", rather than "sorry I almost added you to this years KSI statistics, but I didn't look or comprehend the situation properly".

In this instance the driver did actually seem pretty horrified that she'd nearly done it, and she wasn't on her phone. What could be the cause then, on a clear and quiet afternoon with no other distractions in sight?

Tyndall's Park Road; Highbury Vaults is at the end of it. Before they blocked off Woodland Road on the left side of the climb, you could drive straight over. That kept the road a lot more hazardous, as there'd be cars trying to sprint across. Here though, Woodland Road provides an escape route to the side, with the raised section of road some mild traffic calming of the main university halls of residence to study route for students on foot & bike.  Coming downhill would have been a serious issue.

The vehicle is on camera for 4s of visibility before pulling out, but she doesn't actually stop at the give way, just slow down for <1s and then continue. You have to consider whether the fact that the roads were so quiet got her thinking "these roads are empty" and failed to properly stop & assess the situation. Or she was only looking the right, pulled out and didn't do a second check to the left as she came around.


Saturday 4 November 2017

Volvo bug reports, issue #1: MGIF driver

Given some of the Volvo self driving car developers are ex colleagues of Bristol Traffic team members, we get to file bug reports. Not some directly accessible issue tracker where you get to file stuff like "XC90 driver nearly killed me" only for tech support to close as a "works as intended", but at least get to give them cues about how their land-barges get used and abused in the field. Here's one of this week's Volvos. Mid-afternoon, not rush hour but within range of school pickup times. Sunny days to treasure before the miserable season settles in.

First: "MGIF" , "Must Get In Front"

Definition: A driver who is focused on overtaking the bike without looking ahead to consider "What happens next?

In AI terminology a "planning horizon of 1", usually loses to any computerised chess/draughts player with a horizon >= 2 unless the latter is awful about assessing the value of all enumerated moves & countermoves.

In this instance,
  1. the speed limit of the bridge and the rest of the city for the subsequent 1-2+ miles in any direction is 20 mph. You can see one of the signs at 0:01 in the video
  2. the cyclist she chooses to pass is doing 19-20 mph, still accelerating in their underresponsive steel-framed MTB.
  3. The car a safe stopping distance in front is also doing 20 mph
  4. And it'll have to slow down once it gets to the end of the bridge due to the road there (i.e it's 100% predictable, irrespective of time of day & pedestrian/traffic numbers)
  5. the oncoming cyclist is going 15 + mph
Which means that

(a) there's no defensible reason to pass the cyclist "I need to break the law to overtake a bike cycling at the speed limit to get behind the other vehicle going at the same speed before I get into the city proper and really have to slow down".

(b) she's failed to anticipate how long it will take to overtake the bike, even as she speeds up to 25-30.

(c) the closure rate with the oncoming cyclist becomes about 40-45 mph. If the oncoming roadie hadn't been keeping to the far left of the lane, there'd have been a collision.

Looking back at the footage, she's hanging back at the split to two lanes at the tolls to make a late-binding choice of which one to go through -a slight sign of impatience.  She takes the left one; the right hand one is occupied by an SUV whose driver can barely see over the wheel, which is why the cyclist chose to hang back and wait: didn't seem safe to go ahead. As the Volvo comes through fairly rapidly, it's probable she has one of the contactless cards which you top up with prepaid bridge crossing tokens; sign of a regular user. Given time of day, perhaps a resident of N. Somerset doing a late pickup of a child from somewhere in Clifton, someone who cannot afford to be held up by any vehicle doing the speed limit.

Now, what is he dev team planning w.r.t. oncoming collision avoidance, where it assesses oncoming velocity of the approaching vehicle, adds with its own and estimates time-to-impact, so perhaps suggesting some alternate actions? And what to suggest? There's the "massively accelerate, swing in hard and then brake" strategy, which is an extension of this drivers decision (and essentially a reward), the alternative is: brake, swing behind the cyclist they tried to pass, put it off. Which is safer, but not generally that common amongst "legacy" manual-drivers. There's some psychological "we're committed now" decision which interferes with the more rational "braking to survive is a good idea" strategy.


P.S. UK DVLA now gives MOT history over time: can see that GP05RZE used to be a 3K/y child seat equipped barge of Hendon, NW London, then over to bristol to do 15K/y. Where you can see from the repeated warnings "pitted/scored disks, front headlamp deterioration" that the owner doesn't actually do any maintenance. Probably not a good sign. Almost as bad as a MkI Golf GTi with the wheels coming off..