CHAOS Report

The Economist in March reported that the Standish Group has recently released its CHAOS Report on the state of software development. This report basically analyses the outcome of the IT Projects. It is quite interesting that "35% of software projects started in 2006 were completed on time, on budget and did what they were supposed to, up from 16% in 1994; the proportion that failed outright fell from 31% to 19%". The Chaos report has a third category: those projects which were a challenge or, to use the report's words: "The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified". Doing the math you can find something very interesting: 65% of the IT projects were either late, over budget, offered less features than expected or have been cancelled at some point. This percentage remained more or less the same over the past 12 years. What does it means?

Which are the causes of such gloomy scenario? The main reason can easily be found in the early stage of the lifecycle when the final user (the customer indeed) requires an application to the IT department. The requirements at this stage are fuzzy! IT's managers try to be vague taking in the requirements, business does not explain very well it's need (sometimes at this stage does not really understand the need). Afterwards the IT department starts its joba while business waits for the outcome.
We know it. It is an old story. The task is: how to stop this? There are several ways to stop this: use cases, behavioural models, requirements analysis and so on.

The idea overall is to have a constant review of what has to be done! The business has to exercise constant supervision on the development or, from the other side, the developers have to interact constantly with the business.

It is not uncommon that business decisions at the application level are taken by the team leader.
This is done to save money! The CHAOS Report shows that you are wasting money.

Big programs always have a Steering Commitee and Project Boards. These deal with high level issues. Under the board level there are several perfect organizations that just do not talk to each other. Again it is a well known problem: the communication and the exchange of ideas in the company is a success key.

It appears to be obvious but often the project plan comes first. Unfortunately there is no way out: you ought to understand that an IT project has two legs: Biz and Techs and during the IT initiative they have to collaborate.