Towards sanity in software project estimation: a chat with Steve McConnell

1 2 3 4 5 Page 2
Page 2 of 5

cio.com: Do you think there's a correlation between the distance to the target and managerial ability to plan well to reach it? That is, do you think a moon launch is much less likely to succeed than a jump across the pond?

McConnell: Yes, but the relationship is much more complicated than most people probably think.

The Standish Group has observed, but not really emphasized, that as the industry moved toward more smaller projects in the late 1990s and very early 2000s that success rates went up. They also point to a "trend" in project success rates. I think what they've missed is that it's a lot easier to succeed on small projects than large projects, and we were doing a lot of small projects in the early days of the Internet and for Y2K remediation.

Capers Jones, another estimation guru, has published data that shows a dramatically higher success rate for smaller projects. Larry Putnam has published data showing that as the industry has moved back toward larger projects, as Internet applications mature, that project success rates are going down again.

So I don't see any trend in the data. I see fluctuation from larger to smaller projects and back to larger projects again. Having said all that, we sometimes see organizations estimate better on larger projects than smaller projects because they take those projects more seriously.

cio.com: All that sounds as though it supports the various development methodologies for "small iterative projects." Has anyone compared projects using those methodologies to, say, waterfall?

McConnell: Yes, that research is part of what I was referring to when I commented that small projects succeed more often than large projects. So some people might naturally think, "Let's just do small projects." In fact, I worked with one Canadian company that had defined as its business model that they would only do projects that could be completed by teams of 5 people or fewer and would run 6 months or less.

The limitations to this strategy should be blindingly obvious, but we still see various industry pundits advising people to do nothing but short iterations. The problem is that businesses need more long-range predictability than can be provided by highly iterative 1-3 month development cycles.

So there's a justification for adopting more linear development approaches. I say "linear" rather than "waterfall" because few organizations are still doing true waterfall development. The waterfall model was subject to all kinds of problems, and many people seem to paint all linear development approaches as "waterfall." In fact, for many businesses, the most appropriate development approaches are pretty linear, but that doesn't mean they're subject to most of the problems associated with pure waterfall development, at least not if they know what they're doing!

Related:
1 2 3 4 5 Page 2
Page 2 of 5
Discover what your peers are reading. Sign up for our FREE email newsletters today!