Scheduling even the simplest activity is fraught with difficulty. “When are you going to clear all of your bloody crap out of the garage so I can park my car in it ?” asks your nearest and dearest, simmering nicely on the border between vexation and outright physical violence. You consider the task, the customer, your available manpower, any other commitments and the likely risks and issues. “Errr … the bank holiday.” you offer. “I’ll take the Tuesday off too. Borrow Dan’s trailer. Sort it. Yeah.” May Day comes and goes, as does Whitsun, Easter and the summer. One carload of absolute junk has been driven to the tip and two suitcases of valuable heirlooms (old copies of Private Eye and the N.M.E., respectively) moved into the loft. The garage remains stubbornly full of bikes, bits of bikes, unnecessary furniture, electrical equipment in diverse states of disrepair and cardboard boxes of long-forgotten content and provenance. With the autumn leaves you promised to sweep up last weekend lying thickly on the ground and your missed deadline fully five months past, you offer a revised plan to your Sponsor. “Yeah … I should be able to do it before the weather gets too bad. Between Christmas and New Year, eh ? Should be fine.”
Getting round to getting rid of 20 cubic metres of accumulated bloke rubbish does not present a chap with any notable intellectual challenge. However, as illustrated, it can take far far far longer than those involved anticipate, both on the client and supplier side of the fence. Writing software is a fair bit harder than clearing out a garage. Producing a great big chunky software system across a team of a dozen people over many months is harder still. Planning that work, and figuring out what might go wrong and delay it, is even less straightforward. Ergo, estimating when the job will finish is almost impossible to get right.
But in the world of IT Shambles, we do not wish to get it right. We want in fact to make a spectacular arse of it and come up with an end date so insane that even if you had Linus Torvalds, the two lads from Google, Alan Turing, Mr. Spock, Doctor Who, Deep Thought and Jesus on your team, you’d be knackered. To get it wrong drastically and consistently will require a meticulous, scientific approach, and this will necessitate significant study, analysis and investigation. But before we proceed to more advanced topics, may I offer a quick and dirty short cut to shambolic scheduling.
Just as Eccles had the time writted down ‘ere on a piece of paper, so you too can have an instant delivery date at your fingertips. The answer you give for everything is “Two Weeks”. As bald and as brainless as that; simplicity and genius are often two cheeks of the same arse. Two weeks is both near enough to put off complaint, and far enough away to be just plausible, the first couple of times you use it. How long till the credit checking module is ready ? Two weeks. When will Single Sign On be fixed ? Two weeks. Building the Aswan Dam ? Rome ? The Cambridgeshire Guided Busway ? Two weeks again, chief. No worries.
You may doubt that the Eccles Instant Estimation Technique can survive in the wild for any length of time, but I can offer first-hand evidence. It was deployed for over a year without deviation or hesitation by a Development Manager of my acquaintance. So tenacious was he in his adherence to the technique that he was referred to by the entire office as Graham Two-Weeks. People had to check his email signature to remember his actual surname. I can’t in point of fact remember it now. Depending on the vagaries and scale of your particular racket, you can vary the time period for your own personalised piece of paper. Three Months. Six Months. A week on Tuesday. It’s a very flexible algorithm.
So flexible, in fact, that it can be employed even on the largest IT programmes. I was once employed by a firm which had just been purchased by a Really Big Serious Bank. Our new owner was based in the northern part of Britain, and purported to have links to the monarchy. Hint hint. At that time, it appeared to be extremely successful, with profits in the multi-billions every single year. It had grown quickly through a series of aggressive acquisitions, and was hubristically convinced of its world-leading ability to absorb the companies it acquired rapidly and efficiently. A particular strength the Really Big Serious Bank believed it possessed was for amalgamation of all the different systems it picked up on its endless shopping spree. It was, to quote its own hype, Good at Technology Integration. They’d done loads of it. Superbly well. Time after time. It was a solved problem. So, having bought us, they bought the other main player in our field in Europe, and decided to stick the two of us together. Same sort of business, same sort of kit, same continent, everyone spoke English, and slightly less than four hundred staff across the two outfits. Small beer. A breeze, relatively speaking, for a Blue Chip with a best-in-class, market-leading, proven aptitude for Technology Integration. So we were all assembled in front of the MD for him to give us the good news. Senior Management were fired up, buoyed and pumped with enthusiasm, so it was all going to be fantastic. The best of it was that it wasn’t going to take that long. It “felt like an 18-month programme,” to lift a direct quote. The stock phrases that later became obvious as hyperbole, self-delusion and historical falsification were trotted out to us for the first time, and fairly convincingly at that. We (the Large Bank) had done lots of Technology Integrations before. We (the Large Bank) were good at Technology Integrations. We (the Large Bank) had done many Technology Integrations in the past that were fatter, heavier, more complex and riskier than this one. It’d be a cinch. 18 months. Maybe two years, tops.
With sickening inevitability, the estimate pulled from a back pocket turned out to have all the worth of a crumpled bus ticket. 18 months passed, two years passed, and the end was nowhere in sight. Fifty-odd techies had expended 100 man-years of effort on this supposed turkey shoot, and not one of us thought we were even near to completion. There were serious performance problems, all the chunks of coding had been more painful than expected, lots of essentials had been forgotten, lots of pointless detours had been followed and there was bitter internecine strife between the various camps involved in the project. At about the 30 month mark we were called upstairs for another school assembly led by the MD. We’d had some troubles, he admitted, but lessons had been learned and key points of concern addressed. We were now back on track and he could assure us that we would achieve platform integration by Easter with “a confidence level of 99%”. Those of us in the know sighed, giggled into our hands or exchanged significant looks. That Easter passed, and the next one, and finally we were done the following September, 4 ½ years after we started. Or 200% late against baseline, if you prefer. Eccles and Bluebottle could conceivably have made a better fist of it.
But these are examples of ad-hoc, amateur foolishness. What we are shooting for is laser-guided, precision idiocy. For this, we need to understand all the steps that should be taken to produce a realistic, credible estimate. And then, with an intoxicating mixture of arrogance, wild optimism and ignorance at each point, make a calculated bollocks of every one. This will be the topic of our next lecture.