e-Talk Radio: Davis, Alan, 8 March 2001


some projects, where they used...they spent almost no time doing requirements management and other ones they did up to 20-25% of their time spent on requirements. And they found that their overall project cost overrun, when they spent almost no time doing requirements, was up around 80% to 90%. So, almost a double of what they expected the cost to be. When they spent about 20% to 25% of their time on requirements management, it brought down the overall cost overrun for the product down to around 20% to 25%.

CAROL: So, doing the...

ALAN: Those are some very large projects. In the smaller companies, I have found about the same kind of ratio, around 20% to 25% is the right amount of time to spend.

CAROL: Interesting.

ALAN: I'll elaborate on that after the break.

CAROL: And we will. Please join us after these short messages from our sponsors and StickyMinds.com. And if you're just joining us, we're in show number ten. I'm Carol Dekkers and my guest this week is Dr. Alan Davis, who is president of Omni Vista Incorporated, which is a Colorado corporation dedicated to helping companies prevent software disaster. I'd like to give out the toll-free number if anyone is interested in calling us. The number is 866-277-5369, and we absolutely will not cut you off, we will not be rude to you on the phone. If you've got questions for Dr. Davis on requirements management in Internet time, if you're challenged with some of the things we're saying, or challenged with things in your own work environment, please give us a call. We'd love to hear from you.

We've been talking about requirements management in Internet time, and what's the right amount of time you should spend on software requirements. Alan, right before we went to break, you were talking about the NASA study and how much time and the fact that if you spend 20-25% of your time on requirements, that you actually will hit your deadline much better. And I can see how that can happen. One of the things I think that traditional developers are taught in school is that nothing is worth anything unless you've written a line of code. And the TSP and PSP that the Software Engineering Institute has come out with really addresses that, that we should be planning more and spending time up front. Now, I think you've said that there's a balance, that the 20-25%, is that of overall anticipated project effort that you'd spend 20-25%, or what exactly do you mean by that?

ALAN: Let me answer that question too, as one of them is the NASA study and then what my suggestion is.

CAROL: Okay.

ALAN: The NASA study is an after the fact. It wasn't that they planned on each project to spend 20% of the whole time on the project. It was after the fact they went back and looked to see how much time they did spend on planning. They found the optimal to be around 20 to 25%. My recommendation is to spend between 20 to 25%, not because of the NASA study, but because that in my experience over 25 years doing this, when you spend less time than that, you'll have a much higher risk of being in the 71% of projects that fail, which is something that I don't like being involved with.

CAROL: Right.

ALAN: And when you spend much more time than 25%, you end up likely being late on your delivery by you spending too much time planning.

CAROL: Right.


About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

About the author

Carol Dekkers's picture Carol Dekkers

Carol A. Dekkers is President of Quality Plus Technologies, Inc., a management consulting firm specializing in creating peace of mind for companies who want to improve their software processes. Software measurement, software quality, process improvement, requirements, and software sizing (using function point analysis, as an example) are a few of the Quality Plus areas of specialization.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!