Now. Given a project to manage and an iron determination to drive it to ruination, there are many paths one may take. You could say sod the coding, stuff the budget in a holdall, and whisk the team off on a three month all-inclusive slap-up spree in Great Yarmouth. All the candy-floss, crazy golf and stock-car racing that money can buy. But that would be to miss the point on several levels. First, you can’t just throw the game. That’s cheating. A proper IT shambles has to contain a genuine albeit woefully misconceived desire to produce a useful computer system at its end, and should appear to the casual observer to be attempting to do exactly that. Second, it has to leave a legacy behind it: ideally a completely useless computer system along with widespread collateral damage. Thirdly, emotionally, it should consist of headaches, misery, and suffering, and leave a trail of scarred and damaged lives in its wake. So the Yarmouth trip falls short on all three counts – you’ve not tried, you’ve wasted only the cash and time you were given at the start, and you’ve had a good laugh. Well, probably, weather depending.
So – which way to crash and burn. Your plain vanilla option is massively optimistic planning. Take a two or three year programme and convince yourself you’ll bring it in within six months, easy. Then flog your team to do three-quarters of what was intended in a year. Everyone will hate you. The team will hate you for the long hours, continual pressure and endless corners cut. The users will hate you as they won’t get everything they expected. They’ll hate you even more when what they do get is buggy as testing and fixing got squeezed in the rush. And the top bosses will hate you for being late. Against an end date that was never remotely achievable in the first place. No-one, but no-one, will say thank you.
Impossible schedules are more or less industry standard. Rank incompetence is not universal but is widespread and is the second favourite option. Clearly widespread incompetence is a great boon if you are trying to fashion a balls-up but it cannot be taken for granted. There are established techniques both for finding and nurturing ineptitude, and for targeting and magnifying its effects for maximum drag on software development. We will study these in depth in future posts, but put shortly, if you can fill your team with a couple of handfuls of real eejits, then you’re odds-on to drive off the cliff.
Rubbish planning and hopeless idiocy during execution are all fine and dandy, and will be oft-wielded lump hammers in the toolkit of any shambolic project manager. However, as one becomes a connoisseur of software disaster, they start to seem obvious, pedestrian and uncouth. At that point one finds oneself yearning for commissions that are guaranteed to disappoint even if perfectly organised and executed. These are the pointless projects. The most ambitious of these will deliver something new which nobody wants and can be categorised colloquially as “Shit Sandwiches”. It might arrive on time, it might match the specification exactly, but in the final analysis it’s still a sandwich. With shit in it. And nobody wants to tuck in. NHS Connecting for Health (see post passim and here) is possibly the whiffiest such, but there are many others and they are often government brainwaves. Another recent taxpayer-funded stinker was the National Identity Cards scheme, conceived in 2002 and abandoned after vast expenditure in 2011. Maybe £5bn was spent, or maybe £20bn, nobody is quite sure. Not all of the billions were spent on IT, but stacks were, and produced absolutely nothing of value. An actual shit sandwich could at least have been composted.
A shade less ambitious but still utterly futile are the pointless replacement projects. These take an existing system which is jogging along quite nicely as their starting point, and bin it. A new system is then stuck in which does more or less the same as the old did, but not quite so well. Less reliably. More expensively. Without some of the handy features of its predecessor. With greater levels of user confusion. Much slower. Typically, these projects will be promoted as vital developments to thrust users into a bright shining Modernised, Enterprise-Class, Best of Breed, Web 2.0, 21st Century Technological Landscape. You can try this out domestically when you next visit your parents. Take their seven year old PC running its seven year old software which is absolutely adequate for their needs, and “enhance” it with the very latest versions of Windows and Office. Marvel at how sluggishly it runs, and how brassed off Mum gets when she tries to get to grips with the ribbon controller to send her single weekly email. And then realise Dad is no longer able to reboot into DOS so that the grandchildren can play 3D Tetris.
All of these approaches will work in sowing carnage and chaos, all have an illustrious history in the world of IT cock-ups, and they can even be successfully used in combination. But the ideal calamitous project is one which is foredoomed. Achieving the goal is not simply difficult, time-consuming, expensive and pointless; it is impossible. For example, outside the narrow confines of computing, teaching ravens to fly underwater. You’d be surprised how common these prefabricated black holes are. On the very smallest scale, a mate of mine once worked at a Big International Business Computer Company (hint hint). His very first assignment was to build a geographical information system for a city council. He was briefed by his boss that this was in point of fact nothing scary. It meant scanning and electronically storing a set of charts covering roads, sewerage, water mains and various other utilities, and then building some basic means of updating and searching through them. When he turned up at the council offices he found out the job had been a tad oversold. The council had been led to believe that the product they were paying for was not just going to store maps but also to understand them; it would read a scanned image and automatically identify streets, water courses and utility networks, and store them as vectors. Given a telephone exchange and a subscriber, it could pick out the cabling pathway between the two, or given a set of houses that had brown gunk oozing out of their taps, it would suggest likely sources for the sludge. In these days of Google Maps, GPS and ubiquitous dirt-cheap high-power kit, this doesn’t seem so bad. You could probably knock it up as a smartphone app. Fair bit more time, people and cash required than you originally thought maybe but by no means undoable. But this was back in 1985. Way before the internet, when we were so amazingly primitive we still thought that Elite had pretty neat 3D graphics(*). Quite apart from the technological problems, my pal was 18 and the project team was just him, for the duration of his gap year. With only his A levels and a bit of semi-pro hackery on the BBC Model B to guide him, he was meant to complete the whole thing unaided before starting University. You have to wonder at the wide-lapelled 80s consultant who set up this job, got the contract signed, and then handed it to a teenager on his tod. It’s a whole series of genius moves, brilliantly strung together. If scientifically designed as a 100% guaranteed car crash, then he was the Einstein of IT Shambles. Maybe still is. He’s probably just finished a government debt management system in Greece.
(*) To be fair, Elite was fantastic. Absolutely in its own right, and even more so considering the kit it ran on back then.