AgileAttitudes Article
 
 
 

Vol 02 Issue 02- Lets Look at the Numbers

  
 
Back to the list of articles Agile Attitudes Volume 2, Issue 2 Jan. 25, 2005 A free bi-weekly email newsletter Brought to you by Agile Rules consulting www.agilerules.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Welcome to Agile Attitudes, a newsletter of ideas, insights and technical tips that help people find better ways to develop software. Feel free to share this with anyone - just be sure you send or print the whole thing, including the copyright notice. Directions for managing your subscription are below. O><O><O><O><O><O XP Day - Toronto is a one-day conference happening on Saturday, Feb 19th. The cost to attend is only $299 (Canadian). For info, see http://www.xpday.info Interested in car-pooling from Boston area? Contact nancyv@agilerules.com O><O><O><O><O><O Let's Look at the Numbers by Nancy Van Schooenderwoert Lately I've been taking a look at some interesting numbers. They are statistics from the Standish Group concerning the success rates of IT projects. No doubt you've seen some of these figures quoted in articles and presentations. I found that the Standish Group began publishing this information in 1994, as part of their “Chaos Report” and they've continued doing this ever since. Success means the project completed on time and within budget; Fail means it was cancelled before completion; Challenged covers all the rest. Here are the numbers since 1994: Percent of IT Project Outcomes Success Fail Challenged 1994 16 31 53 1996 27 40 33 1998 26 28 46 2000 28 23 49 2002 34 15 51 2004 28 18 53 Anytime numbers are quoted, questions spring up about the methodology used. I'll refer you here for those answers: http://www.standishgroup.com/sample_research/chaos_1994_1.php Note the increase of successful projects in 2002. Asked for the chief reasons project success rates have improved, Standish Chairman Jim Johnson said, “The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.” Equally interesting is the drop right back to 28% success rate in the 2004 numbers. Amazing! Did our industry suddenly forget what was learned? Computerworld commentator Frank Hayes reports: “When I talked to Standish Chairman Jim Johnson, the numbers [for 2004] were still being crunched. But he pointed to a few significant details. For one: Projects are getting more expensive, and big projects are more likely to fail. For another: As projects get bigger, we're no longer keeping our work iterative. We've gone back to more traditional development practices -- practices with higher failure rates. For a third: Lack of user involvement has jumped back to the top position among reasons for IT project failure. But lack of executive support is still running a very close second. Without committed executive sponsors and involved users, our projects fail.“ That second observation ties in with another figure that Standish publishes – that project success rate is inversely proportional to project size. Here's how that looks: Project Success Rate vs. Budget Size Over $10 million 2% $6 to 10 million 11% $3 to 6 million 23% $750,000 to 3 million 32% Under $750,000 46% Clearly, the software industry still has a very long way to go in learning how to run large projects. Even smaller projects are no simple matter, with only a 46% success rate. I won't say that Agile methodologies have *all* the answers, but their essential tenets are supported by these figures and Jim Johnson's observations: - Use iterative development - Keep teams and projects small - Keep feedback loops alive between the project team and users and sponsors O><O><O><O><O><O More articles on Agile software topics at http://www.agilerules.com Within our company we have a sub-specialty in embedded systems. Our site has articles on embedded XP and we support a discussion list focused on the use of agile methods for building embedded software. The list signup info is at http://www.agilerules.com/mailinglists.phtml O><O><O><O><O><O To help you get started with in-depth research into Agile Attitudes topics, we have added a Library section to our web site at http://www.agilerules.com/library.phtml Order using our links and receive discounts up to 30%! O><O><O><O><O><O If you enjoyed this issue or found it useful, forward it to a friend! Help spread the word about better ways to build software. Invite your friends and colleagues to join our growing reader community at http://www.agilerules.com/mailinglists.phtml O><O><O><O><O><O Looking for a speaker for your next corporate or society meeting? We present dynamic, informative programs on topics of interest to managers and technical staff in their transition to more flexible, robust ways to create software. O><O><O><O><O><O Want to reprint this issue in your company or society newsletter? For permission to reprint any of the articles, contact us at info@agilerules.com. O><O><O><O><O><O If you would like to receive an email as soon as we know of an event in the Boston area of interest to the agile software community, you can sign up for the announcements list at http://www.agilerules.com/mailman/listinfo/agileannounce O><O><O><O><O><O Your feedback is welcome! Send feedback to info@agilerules.com To manage your subscription: http://www.agilerules.com/mailman/listinfo/agileattitudes O><O><O><O><O><O Brought to you by Agile Rules consulting 162 Marrett Road, Lexington MA 02421 Copyright (c) 2004, 2005 Agile Rules info@agilerules.com O><O><O><O><O><O Privacy notice: We will not release a subscriber's address to any third party for any reason. This is a strictly opt-in newsletter. No one is ever subscribed without their explicit request. </plaintext> </td id="bodytable_r1_c3_body"> </tr id="bodytable_r1"> </table id="bodytable">