Comments for Using the Requirements Creation Process to Improve Project Estimates at http://www.projecttimes.com , comment 1 to 6 out of 6 comments http://www.projecttimes.com Tue, 07 Sep 2010 19:29:07 +0100 FeedCreator 1.7.3 http://www.projecttimes.com/requirements-management/using-the-requirements-creation-process-to-improve-project-estimates.html#comment-486 You are absolutely right sir. And this is hard to do. Hence, some people have adopted the agile approach to compensate. I.e. "we'll figure out the reqs as we go along" - a guest Wed, 11 Aug 2010 08:03:12 +0100 http://www.projecttimes.com/requirements-management/using-the-requirements-creation-process-to-improve-project-estimates.html#comment-485 Of course, this entire method is dependent upon having the right specifications! - Philip Bennett Wed, 11 Aug 2010 07:35:14 +0100 http://www.projecttimes.com/requirements-management/using-the-requirements-creation-process-to-improve-project-estimates.html#comment-314 You guys are all correct. I agree that different organizations will have different percentages - furthermore different classes of projects within the same organization will have different percentages (e.g. marketing projects will differ from software projects). I've always thought requirements was 'the wish list' and specifications were 'what we're really building', but it sounds llike you guys have more developed notions than that. That would make a great article in it's own right and I'd love to write it, referring to your work where relevant. Do you guys have specific things I should read on this issue? - clf99 Fri, 09 Oct 2009 10:33:03 +0100 http://www.projecttimes.com/requirements-management/using-the-requirements-creation-process-to-improve-project-estimates.html#comment-310 "In other words, if it took 60 hours to do the specification, that's probably 6% of the job and the job will be 1000 hours." Yes, yes, yes. As one commenter said, you do have to come to know what is *your* percentage. By tracking how you perform on each of your products/projects, you get the data to make this kind of estimate. I outline how I've done similar over my 30+ year career at: http://pmtoolsthatwork.com/get-schedule-right/ I would also highlight that as you proceed through the project, you can do this same kind of estimating, using a partial results and knowing how it has historically related to the overall results, to help confirm if you are on track. This lets you know if you need to raise an alarm or not. It also helps you to settle down other folks who have a need to panic and declare an emergency at every hiccup. The common "push-back" I've gotten from using this technique is the disbelief that one can "know" how the future will go by "just" knowing a small part. "Every project/product is different!" is the common refrain. The data you collect and use from your past project/product performance gives you the confidence ("the odds are in your favor") even while it may not convince a critic. I've told folks when we would ship a product even before they told me "all" the details of what was going into the product. For folks who didn't know me I'd get the "how naive is this guy" look. When we ship as predicted, I get "hey, that really worked!" You just have to survive to the end of the project with the skepticism. I love this kind of stuff. Bruce http://pmtoolsthatwork.com/ for more on the practical application of this kind of approach (and related topics) - Bruce Mon, 05 Oct 2009 06:23:08 +0100 http://www.projecttimes.com/requirements-management/using-the-requirements-creation-process-to-improve-project-estimates.html#comment-297 Good article. This sounds like a type of parametric model. I agree with the above commenter about making the distinction between requirements and specs. Is there a Business Requirements Document that isolates the business and user requirements?; then a Functional Spec that make up the requirements phase? - planningpro@comcast.net Fri, 18 Sep 2009 06:15:44 +0100 http://www.projecttimes.com/requirements-management/using-the-requirements-creation-process-to-improve-project-estimates.html#comment-282 I'm fortunate to know Bob Grady, and he indeed is really solid. Everyone would benefit from reading all three of his books. I'm sure he would be the first to caution not to overgeneralize from his experience at HP by assuming that everyone has the same 6-8% ratio. No doubt in part thanks to Bob and his folks, most projects at HP followed similar processes, which made the relative portion for requirements fairly consistent. Less mature organizations will have far greater variability. The other not necessarily apparent factor affecting predictability relates to the extent to which what you mean by "requirements" matches what HP means. That involves what you do and also how well you do it. Unfortunately, most organizations do a poorer-than-recognized job of requirements, partly because of poor skills but largely because they think specification is the requirements. Ironically spending more or less time doing the same wrong stuff wrongly may not appreciably change the outcome; and ultimately it's the time/efort to produce an effective outcome that matters. Organizations predictably deliver quicker, cheaper, and better when they learn first to discover the high-level and detailed REAL business requirements deliverable _whats_ that provide value when delivered/satisfied/met and then design/specify a product system, and/or software _how_ that meets those REAL business requirements. You can learn how to do it in my book, Discovering REAL Business Requirements for Software Project Success - RobinGoldsmith Tue, 08 Sep 2009 05:44:23 +0100