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.
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.
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.
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.
ALAN: So, I