Less projects were reported to be successful in 2008
The Standish Group released the most recent version of the Chaos Summary Report 2009 on April 23rd and the results are worst than last year with only 32% of all projects surveyed were reported to be successful (down from 35% in 2006).In the context of this survey, a project is defined to be successful if it was delivered on time, on budget and with the required features.
Along the same lines, 44% of the projects were challenged (did not meat one or many of the success criteria) while 24% totally failed. The Standish Group highlights that costs overrun 54% (+7%) and time overrun 79% (+7%) both went up compared to the 2006 results.
The reports also explains that the probability of success greatly decreases as the size of the project increases where projects costing less than $750,000 have 61% success rate while projects costing over $10 million only have 2% success rate.
The second part of the report present the 10 Laws of Chaos and while the report doesn’t make any correlation between these laws and the Agile principles, it is easy to make some correlations.
- Law of the Two Faces: Successful projects include business-knowledgeable users with good communication skills.
- Cheetah’s Law: Swift decisions are typically better than long, drawn-out analysis.
- Law of the Roads: Clarity and focus are essential to a successful project.
- Law of the Five Deadly Sins: It is how you deal with each of these sins that will determine the success or failure of your project.
- Law of the Long-Tailed Monster: Over- and under-building applications represents the biggest form of software development waste.
- Law of the Edible Elephant: Software should be built in small, iterative steps with small, focused teams.
- Law of the Mad Hatter: Complexity causes confusion and cost.
- Law of the Empty Chair: Keep the project cycles short with continuous deliverable.
- Panda’s Law: Inaction is the purest form of failure.
- Law of the Fools: It is not just having the right tools but the skill to use them that make all the difference.
Can you draw the parallels with the Agile principles?