As a young chap, I used to have Faith. In many different things, but specifically for my purposes here, Faith in the determinism and predictability of Software Development. So long as one was completely cognisant of the architectural paradigms, governance and processes to be followed, and providing that one diligently itemised the requirements, acceptance criteria and technical tasks in their entirety, and on the strict understanding that all interested parties had contributed thoroughgoing analysis of effort, risks and issues, with all appropriate weightings applied and interactions considered, I was confident that one could forecast with pinpoint precision the end date of a project. I was a Believer.
The marvellous and strange Robert Wyatt covers The Monkees. First wheelchair on Top of the Pops, music trivia fans note.
But I was an idiot when I was young. I am not a Believer any more. Nowadays I refrain from giving all but the vaguest estimates, and will finally, grudgingly proffer a delivery date only when I know for sure that the job in question is already 99.99% done. Even then, I will pad furiously. Estimating, planning, scheduling, forecasting, however you name it, is an attempt to predict the future and as such an undertaking drenched in fraudulence, self-delusion, misery and failure. As noted in earlier symposia, it is, without a hint of doubt in every instance doomed, doomed and thrice doomed. Every time you give the customers a plan and a date, within weeks it will turn out to be patently unachievable nonsense, and then you will be beaten viciously with that original date by your sponsor until the bleeding thing finally limps over the finish line months and months later.
This grim and endlessly replayed scenario is in fact avoidable. With age and experience, and to some extent in response to a long series of savage kickings, come guile and a species of low cunning that it would be over-generous to call wisdom but which nonetheless can save you from ever being so daft as to give your enemies a weapon in the form of a “guaranteed” deadline date. The trick is never to refuse outright to produce a date, but always to have one more condition that those demanding it, or some other handy third party, have to fulfil before you are able to do so. Now. As clients hate exerting themselves in any way, shape or form, and will employ all manner of countermeasures to avoid doing so, and as every other clique involved in the IT racket is equally dodgy, workshy, incompetent and slopey-shouldered, this will almost certainly provide a series of pre-requisites which will never be altogether met. Requirements are obviously the first line of defence. They pretty much always are a pile of crap, so it’s a good start. One clearly cannot even commence design, let alone planning, without superlative requirements signed off by those who commissioned the job. It will take months of refinement with the sharper techies in your team leading the business analysts by the nose before something more or less comprehensible and codable can be extracted from the morass of ambiguous waffle, jargon, inconsistencies and plain rubbish you were given to begin with. The unsophisticated would leave it at that, but the craftier fox will insist that this final draft is endorsed by the Steering Group. Top brass don’t do work as a rule, and they will squirm as hard as they possibly can to sidestep doing work that may require them to take traceable non-deniable responsibility for something in the future. However, your employer’s own bureaucracy will come to your aid at this point. For within the hefty volumes of your Enterprise Delivery Process Handbook, it will assuredly be spelled out many times in many different ways that only the Big Boys can make the Big Decisions as the small fry ain’t got the moxie, and that validating scope is one of those indubitably Big Decisions. It’s there in black and white: they gotta read all the bumph and grudgingly concur that it does represent what they asked for. Millennia will pass, oceans freeze, and mountain ranges rise and fall as they try and wiggle out of that culpability booby trap.
It is tempting to hope that they never do get out of the hole you have pushed them into, but in the end something will give. They might just for once decide to do the decent thing: wade through all the docco, table a motion at their next meeting and carry it nem con. More likely, they will find an underling to do their homework for them and write up a one page summary, and then move to accept on the basis of that recommendation. Less effort, and with the added bonus that a stooge can be conveniently bollocked, blamed and booted out when the need arises. Or it could be that the MD comes down like a ton of bricks and tells them to bloody well get on with it. Either way, your first set of barricades will eventually be breached. But do not be alarmed. You have bought valuable time, and there are several more delaying tactics at your disposal. We will continue to adopt a Judo-esque approach whereby our enemy’s vulnerabilities are used against them, and again we will deploy the company’s own processes and procedures as a lever to get what we want, but this time in the sphere of Architecture and Design.
Architects love to theorise and pontificate, not always to entirely productive effect as has been noted before. This can be vexing, but if you want to stop things happening it can be ruddy handy. You have your assignment and it now has its requirements laser-etched into granite tablets, but self-evidently you cannot hope to plan out the delivery until the technology choices, design patterns and architectural frameworks have been agreed. So line up a bevy of architect types, and set the buggers off to do just that, or rather to argue the toss about it practically forever. Eons will pass. Scotland will drift away from England and connect with Iceland to form a new continent. Mars will be colonised. Bruce Forsyth will finally disappear from British TV screens. They may eventually finish ideating, creovating and squabbling amongst themselves but you can buy another couple of decades by getting them to present their proposal at the Strategic Architecture Review Board for final assent.
And so on. Once the Architects are happy, you can bring in the Boxes and Wires goons. Hardware people despise everything related to software and will flatly reject anything that comes from that direction on principle. The Systems view is that any kit they set up should be used solely for running performance alerts and virus scanners. Bunging some code on it that performs a conceivably useful function poses far too much of a security risk. So they ain’t gonna be nodding anything through. But naturally your officially sanctioned IT rules and regulations mandate that Systems must advise on, assess and approve any and all changes and deliveries to, via, across or upon all group infrastructure. You could be waiting for several years after the Day of Judgement before your Data Centre colleagues consent to the installation of your nasty bit of hackery-pokery on the blessed machines in their sanctified server racks. Thwack. Back of the Net.
Alan Partridge demonstrates the correct usage of the phrase “Back of the Net”.
All of which goes to demonstrate that, with so much governance, so many contributing parties, and so many boxes to be ticked, the wily and devious can slide round Gantt charts and deadlines almost indefinitely. But I am not by any stretch advocating loafing about. Quite the reverse. While all this positioning and dodging is going on, and concerns are being raised and challenges dealt with and issues and risks mitigated, you and the rest of the people who prefer doing stuff to pratting about have the space and time to get on with some actual business. You will obviously pass it off as prototyping or investigation or bug fixing, or maybe knocking off a handful of quick wins before the main event, but in fact you will be making the changes that everybody knows needs to be made, but within a cunningly synthesised pre-project governance-free limbo. Without the ceaseless demands for progress updates, exception reports, risk mitigation strategies, resource requisitions and lemon-soaked paper napkins, it may be possible to have a crack at some code and get moving without having to beg permission for every line typed, critique the productivity of every hour spent, and continually justify with voluminous spreadsheets that what is being done is in complete accordance with the Programme Vision, Project Brief, Technology Budget, Business Case, High-Level Plan, Mid-Level Plan and Quality Delivery Checklist. In short, you have to pretend to be doing all manner of pointless guff while simultaneously pretending not to do what you really are doing which is the necessary or even vital exercise that you were supposed to be doing in the first place.
This is ridiculous but not uncommon, and by no means restricted to the tedious world of an IT Shambles. There is often a huge gulf between what people say they want and what they honestly need. Imagine for a moment if a kindly but foolish parent did absolutely everything that his vocal, egocentric and frankly silly children asked him to do, and if he let them do absolutely everything they wanted to do. Things would not end well. The little blighters would stay up every night until three a.m. playing Minecraft and watching YouTube. They would go to school once a week. They would rarely leave the house, and never do anything resembling exercise. They would exist on a diet composed exclusively of Skittles, Coke, Monster Munch and Pizza. They would love the new regime for a fortnight, but after a year would be dribbling, irritable, grossly obese, friendless, and profoundly miserable.
In the case of shambolic project planning, what everybody needs you to do is whatever gubbins that provided the reason for the project to be initiated in the first place – the enhanced customer billing engine, the new turbine blade modelling package, the improved sonic-death-ray fire direction module, whatever it may be. That is the point. If the blasted thing gets built and runs and can fill the hole it was intended to fill, it was worthwhile. If it isn’t or doesn’t or can’t, then all the Optimised Critical Paths in Christendom will not stop it from being a complete waste of time. What everybody wants you to do, though, is participate in their mass-hysterical fiction that many months of extremely complex and ill-defined technical slog can be planned out as accurately as the sonic-death-ray beam can be targeted, by dint of analysing the bejaysus out of every single risk, story, dependency, milestone and requirement from now until Kingdom Come. They ask you to do this not only because they are bad people, but also because they believe it will help. In fact, they often sincerely believe that it is impossible for things to proceed any other way. They have no conception that doing and planning are two different things, or that the second may get in the way of the first a bit. But as we enlightened few know, in fact the endless preparatory box-ticking will soak up all of the energy that should have been spent on doing the proper job. If you are so naïve as to give them, the Senior Stakeholders and the Programme Office and the Business Sponsor and all the rest of the influential morons what they want, they will never in the end get what they need.
You Can’t Always Get What You Want. The Rolling Stones making the same point with fewer words but far more funky swagger
So there it is. Treat those harassing you as if they were querulous spoilt children, and use every trick in the book to dodge their requests for plans, deadlines, estimates, timelines, schedules and copper-bottomed iron-clad fully certified delivery dates. Any other course of action displays both bumbling ineptitude and a shameful lack of backbone.