Applying engineering principles to IT projects

I have spent a small part of my career in the utility world - power, telephones, water and even TV - and one of the interesting splits that you see in these organisations is the way different ways computers are used.

The IT department is usually, until quite recently, flush with cash and are like any other commercial IT department. (You can work that out from reading all my previous posts!)

The engineers, however, who are keeping the revenue earning services running do things a different way. They generally have no money to invest in flash computer rooms and expensive software. They lash PC's together; get them working and bury them in the nearest cupboard or under the largest desk where they whir away for years delivering the service required. The upshot is that they are completely fit for purpose, work and never, and I mean never, go wrong.

This different views of the same world always creates enormous rifts between the two groups and I always feel sorry for those CIO's who have managed to combine ownership of these two warring groups.

So what is the difference, I think fundamentally its caused by the IT worlds' continuing inability to impose any structure to what it does and embrace simple engineering principles for its projects. We rarely design solutions in the same way an architect builds houses or a civil engineer builds bridges - thank god!

When designing a solution:

• we ignore the complexity of the environments we install into
  
• we scope solutions badly
  
• and if we do we allow the scope to creep
  
• if we do change the design we never return and challenge the initial design assumptions
  
• we rarely fully qualify assumptions made about the solution
  
• we never prototype and if we do it's just with pictures
  
• we always make sure proofs of concept work - at all costs
  
• we put development systems into production
  
• we never design for the future, only the present
  

...OK I'll stop now

Now I'm not suggesting we should be running our IT systems on PC's under desks, although if we commit to cloud computing we might be - see my earlier posts - but we should be imposing a more rigid framework around the project work that we do. I know that our "users" and more importantly our project sponsors generally "don't see the value" but I think that's an attitude we have bred because we've been far too lazy at explaining the issues.

A fine example of this is the relentless move to VOIP telephony. The analogue technology required to provide "always on ring tone" was a glorious tribute to the power of early 20th century engineering and was carried through into the digital telephony world. But with VOIP now we see the computerisation of telephony - and I guarantee out goes all that resilience!

Next time you're talking to the guy who is selling you the VOIP solution ask him whether he can guarantee "always on ring tone" with his solution. He'll look a bit sheepish, walk away and come back with a quote that is 2 or 3 times the size of the one he first gave you. All of a sudden that business case doesn't look quite so compelling.