The seven deadly sins of IT projects
// IT Quality Improvement, IT-Prozesse &-Organisation
„Quick Nix" – a polemic against the widespread actionism in IT Projects
The CHAOS Report of the Standish Group has been telling us for 20 years already that IT projects in a clear majority of cases do not achieve their objectives. Be it 16 % achievement of objectives in 1994 or 39 % in 2012, IT projects are not a safe bet and whether the increase by 23 percentage points of the last 20 years is actually the result of a stronger focus on objectives can definitely be doubted.
In 1994, the year of the first CHAOS Report, I carried out my first IT project. Back then, the objective was to advertise our weekly film and topics afternoon of the student association of the Faculty of Mathematics and Informatics at the Technical University of Eindhoven. The new web page‘s success was incredible – even today students of „GEWIS" are still meeting every Thursday at the club room. However, by now they are using a Google calendar for the planning.
Since then, the projects have become larger and with the increase in size, the error rate in projects grows, too. For this reason, fewer and fewer IT is placed on a sensible footing – actionism and quick wins dominate the project setting and blur the view towards the achievement of objectives. In this, seven deadly sins are committed time and again at the altar of quick success.
The sin of endless horror
Projects do not fail and are not terminated early. Software licenses purchased must be used (otherwise they might turn into zombies), filled positions will remain filled for all eternity, and systems that are operating – regardless of whether they still provide any benefit or not – continue to be operated. Each system implementation increases the zoo of systems, and a project – once started – is guaranteed to go into production, even if it is going to be implemented with two crutches and eye patches. Which brings us to the 7th deadly sin,
The sin of victory claims
When faced with failure, there is only one way out for any responsible project manager: we declare success and that the objective has been achieved. We leave the further operation to the line organisation (as such, we leave the proof from Sin 5 to the reader so inclined as further exercise), delegate adjustments to the processes to the process owners, and our key user is certainly going to train all other users. Since all parties involved up to here have already committed multiple sins, nobody is going to doubt the success.
Projects do not have to take this path, but unfortunately the consultant/client relationship easily promotes such a progression. Projects decorated with buzzwords, made effective via calculation, and promising the moon are not the only ones suggested by consultants and ordered by customers. Let us counteract committing any such sin by maintaining open and honest communications.