Defensive Driving

Like many people, I’ve recently had the pleasure of attending a Speed Awareness course, having committed the cardinal sin of mistaking the edge of a village for the open road. The key theme of the session, which was incidentally very worthwhile, was that however well you drive there is no way you can stop other people making mistakes that ultimately result in an accident.

This is especially true when driving on a motorway, something that was illustrated graphically by a slow motion analysis of a motorway crash that claimed 10 lives on the M4 in 1991. The initial accident was a fairly minor shunt between two vehicles, but a combination of bad luck, excessive speed and understandable but unfortunate reactions by other drivers resulted in a truly horrendous pile up.

Mulling over the session later it struck me that running an IT project is much like driving. However carefully you drive there’s always a chance an external cause will result in an accident. In the same way, you can set a project up perfectly, have exemplary governance and perfectly skilled staff – but that doesn’t stop things going wrong. Much of the effort that has gone into improving project management methods in the IT industry focuses on creating and managing the perfect project but having worked on the fall-out from many project pile ups, I think that a greater emphasis on how best to deal with problems might be more helpful.

In that spirit here are the 3 main messages I took from that speed awareness course that can, with a little stretching of metaphors, be applied to driving an IT project.

Leave Enough Time for Your Journey

Before setting out on a journey, even with a satnav, it pays to know where you’re going and roughly how long it will take to get there. Aiming to drive from London to Manchester in 3 hours will just result in either excessive speed or a late arrival. Setting out on an IT project without a clear understanding of scope and a realistic timetable can only result in disappointment,

Don’t Ignore Warnings

One of the saddest things about the M4 crash was that some drivers gout out of their cars and ran along the hard shoulder to warn oncoming drivers of the problem ahead. They were ignored and hooted at. Ignoring warnings raised by team members once a project is underway is equally foolhardy. Project managers may be tempted to regard issues raised by techies as excuses or general fud (fear, uncertainty and doubt), but if issues start to pile up the astute PM will recognise that its time to take evasion action.

Don’t Give In to Road Rage

A minor problem on the roads will often pass us all by, but driver behaviour can escalate the most issue into a major incident. Two drivers trying to pass through a single lane tunnel in Maidenhead in 2015 should have been able to sort themselves out within minutes. But neither of them could, or would, reverse and they, and a sizeable chunk of local drives, were stuck there for over 40 minutes.

In project terms this is the equivalent of a both parties digging their heels in and refusing to change their behaviour or accept that they might have some responsibility for whatever issue has arisen. Of course, concessions may have already been made by both sides, and there comes a point when there is no other option. But if you’ve approached every problem professionally and rationally there’s a much better chance of emerging with a successful outcome, so make sure you only escalate when it’s really necessary.

Leave a Reply