Agile Attitudes- Let's Look at the Numbers
agileattitudes at agilerules.com
agileattitudes at agilerules.com
Thu Jan 27 11:48:00 EST 2005
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 at 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 at 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 at 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 at 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.
More information about the AgileAttitudes
mailing list