Megaprojects

One of the unique benefits of having been a journeyman for so many years early in my career is that you get to see how many different companies run their IT shops. By and large, these were pretty awful, but from such experiences comes a wisdom of how to do things better. And if there’s one tummy-tightening warning sign that a project is not going to work, it’s when people get excited at the sheer size of it.

The birth of a megaproject.

I find myself between ‘proper jobs’ at the moment, so regularly talk to agents about upcoming freelance appointments that might pay the bills in the interregnum. A couple of days ago one suggested I might be interested in working on a government megaproject, with over a thousand consultants on it. Try as I might I couldn’t get him to see that, for me at least, big is not just bad, but my idea of a living hell. Boasting about having been tangentially involved in The Doom Programme, as featured on When Good Ideas Go Bad is not my idea of fun.

Government projects do seem to have a habit of crashing and burning, or disappearing with a whimper after delivering entirely unfit-for-purpose systems, and I’m pretty convinced that the big-is-good mentality has a lot to do with it. Oh look at me running a major initiative to create a step change in the way dog licenses are dispensed. With my budget of eighteen frillion quid and an army of consultants to spend it on, I am sure to succeed.

It’s hard to believe people can still be so stupid as to think they have a hope of pulling it off. Has any major project on a scale requiring hundreds of consultants ever succeeded? I mean how would you ever get your basic requirements sorted? And even if you could, the layers and indirections in communication, the misunderstandings, politics, power games, would surely conspire to waste most of the cash at the very least.

I have worked on a few megaprojects, mostly when I was too young and too keen to question anything, and what I noticed was that hardly anybody sees them through from start to finish. Any tainting of CVs is avoided by only being there for a comparatively short period of time. If you got in early, then it was the people who took over from you that were to blame, and if you joined later, then you inherited a disaster that unfortunately couldn’t be avoided.

I consider myself lucky that the market is buoyant enough to allow me to be choosy and select something that is both productive externally and spiritually fulfilling internally. But I know that may not always be the case.

My tactics, when forced into such a situation, is to first of all accept that you cannot win the war (or at least the war’s winnability is beyond your control), but you might just win the battle. Draw borders around all the elements you can control and manage them as if they were your own pet project. Whatever your level of authority, you always have some control - if in doubt read Joel Spolsky’s excellent Getting Things Done When You Are Only A Grunt (if you haven’t got time, I can summarise by saying his advice is to stop whingeing and fretting about all the things that could go wrong and get on with things, make your own plan, build your own environment, run your own bug database, talk to everyone frequently, and so on). Turn everything technical into a project management issue.

For example, you feel you can’t get your bits developed because the spec for a key interface hasn’t come from the architects yet. Then go to the Project Manager, get this put on the risk (or issue) register and give them some alternatives: let you work on something else, let you define it yourself, or let you work one step removed, accepting that there will be rework if you make bad assumptions. If you can’t write the core code, go and see the testers and help spec the test cases, scripts, etc. There’s always something that can be done and if you can’t do something to progress the megaproject, do something for yourself.

Control-freak managers will both love and hate this attitude. They’ll say they love the proactive stance, but many don’t like autonomous developers going off and just doing stuff. But the difference to you is that each Friday on your way home you’ll be able to look back on the week and list some things you’ve achieved, you’ll have learned a few things, and you’ll have improved your worth and your self-image. The project may well fail later, but you’ll have done good things, and be able to say that you came out of it a more capable individual.

Hopefully, you’ll also be saying that megaprojects tend to suck, and as your sphere of influence increases, you’ll add to the body of hackers who try not to create them and avoid joining them.