Recipe for Failure

I don’t know how it is with you guys, but when my wife asks me to go shopping for her, I usually end up buying all sorts of things, but not what she actually asked for. Ok, sometimes I do get a list of everything I have to buy, but even then do I think I need to buy additional stuff, things I like, things I regard as cool and of course all the new stuff – just to give it a try. Sounds familiar? Well, not sure if this is a man thing or because we tend to lose focus on what our wives actually asked us to do? Ending up with useless stuff and overspending the budget?
If you say – yes, I’ve seen that, then you most probably either worked as an IT solution provider or you’re a burned customer. 

I spent my last 30 years in IT departments and IT companies and I’ve seen the same pattern over and over again – as soon these people here the word “new project with budget”, they go out and buy the latest servers, cool gadgets and fanciest development tools – of course including training for the whole team – and spend all day long thinking about how to overcomplicate the architecture for a simple business process. If it’s not complex, then it’s not sexy. The more complex you architecture a system, the less likely you can be replaced and the more likely they send you for another round of training just to understand yourself what you’ve actually architected. 

I’ve seen projects where they started off by buying servers – without even knowing what the actual customer requirements are. But it was all about systems, systems and systems. Isn’t it a good feeling when walking through a datacenter and looking at all your servers blinking?

Unfortunately, most of the projects I’ve seen using such an approach failed – either they run out of budget – or they got so complex that they never managed to finish the development of the system – over time, over budget – not meeting customer requirements. At the end all they had to find is an innocent scapegoat – how about the cleaning lady? 

So my advice to all the poor customers out there: keep the IT guys out until you have a clear view and detailed documentation of what you want. Focus on business processes, functionality and user interaction. Once you use the system you don’t really care if the server is blue or black, blinking orange or green – but the application has to do what you want. These days technology is commodity and as such should never ever – I repeat – never ever – be the driver of a system design, but an enabler only. Lock your doors, keep guys running around with J2EE polo shirts or jumping around full of Hadoop-joy out of your sight. Let them in once the dinner is ready – and make sure they behave well. 

For the IT guys – and I’m one of them – if you present a solution using 20 slides and 18 of them are about the architecture and cool stuff of the system, then go back to the drawing board. No one cares about your libraries and beans except you, coz all you have to do is to translate the requirements into machine code – nothing else. And don’t expect that anyone will applaud you once you’re done. Coz even pilots nowadays don’t get that any longer for a safe landing. Programming was an achievement 30 years ago when every bit counted twice. Nowadays it’s about imagination and delivering systems that match or even exceed the requirements – on time and below budget.