My buddy Alec the Geek often makes very sensible and considered posts that get me thinking. Other times he just says stuff that I agree with because it is so simply obvious (and thus it is ridiculous that there should exist a need to comment at all).
Thus Alec’s recent post on Software development the Gordon Ramsay way got my head nodding in agreement and then got me cross that such basic concepts still seem so foreign to builders of software.
I continue to be amazed of how many places just do not have the basic principles and practices of software development in place.
Collectively we have killed forests of trees and wasted centuries of time writing systems development methodologies, software engineering standards, even a Software Engineering Body of Knowledge. Yet still we have the same poor practices and lack of discipline that often makes our industry look like a badly organised team of chimpanzees.
Michael Krigsman cites a litany of examples over at his IT Project Failures blog. Almost without exception, each example shows how the failed project did not follow accepted and documented best practice.
It is very strange to me that one definition of insanity (attributed to Albert Einstein) is “doing the same thing over and over again and expecting different results”. What does this say about the IT industry?
By Carruthers via Aide-mémoire
http://w.sharethis.com/widget/?tabs=web%2Cemail&charset=utf-8&services=facebook%2Cdigg%2Cstumbleupon%2Cdelicious%2Creddit%2Cblinklist%2Cnewsvine%2Cfurl%2Ctailrank%2Cmagnolia&style=rotate&publisher=91b467b0-fcb3-4e42-95e0-1f04ad0c9be9
Aide Mémoire 
Ha ha, sounds like the National Broadband Network (which I blogged about earlier today).It is ludicrous isn’t it.
LikeLike
One of the common mistakes that I see happen all too frequently is underestimating the importance of the training phase at the end (eg to support the introduction of a new system). When the project plan gets pushed back, the release date usually remains fixed – this leads to poor preparation for training (which usually can’t proceed until after UAT) and rushed delivery. The users aren’t as proficient as they should be, and so the project might be deemed a failure on some level. This is unfair to all the people involved who put in the hard work! It boils down to project management.
LikeLike
It is not just the failure of an IT project … it is the failure of an entire system. The pressures of budget and timeframe (and also team performance) necessitate mid-project deviations and changes to scope. These pressures are often external to the project team — coming from finance or from the business units themselves.Of course, it is easy to point towards the project as a failure. But it is a braver executive who looks at the network of deviations that are the root cause of the failure — and then does something about it. Process and knowledge is one thing, accountability another.
LikeLike