Joe Marasco Comments by Email 8/8/05
Joe Marasco is a retired Senior Vice President with Rational Software, now a part of IBM. He spends his time indulging in many hobbies, including writing. You can find out more about him on his web site at http://www.barbecuejoe.com.
Wow. This is a "trick question." Instead of making detailed comments on your document, let me say the following.
The problem is that ideally we would like to do all projects with one small team, say seven people, to use your example. However, a 100 "man-day" project is an extremely small one in the software world. Many software projects are just too big to be done by seven people.
One should always assume an S curve for the resources applied and time to completion. Note that the relatively flat ramps at the beginning and the end will tend to make the project stretch out, but there is not much you can do about those. They represent the fixed overheads of getting started and completing all the messy details at the end.
On the other hand, if you have done a good job during inception and elaboration, you can hope to optimize during construction, the ramp part of the project.
But be very careful about removing inception, elaboration, and transition phases from the estimate, leaving only "construction." The fallacy here is that these activities take significant time. In the old days people used to do this all the time; they would estimate "three weeks" for a job, meaning that they could write the actual code in three weeks. This corresponds to three weeks of what you might roughly call construction; in that model, the actual time to completion from start to finish of the project could easily be several times that. It took a long time for people to be broken of that habit. Note also that sometimes the coding effort is the easiest to estimate, whilst the other activities have variability that is much larger and predictability that is much lower. So an estimate of the "coding" or "construction phase" (please note that these are NOT the same!) is usually a poor predictor of how long the entire effort will take.
There is no one magic formula, no one recipe. On the other hand, starting with 100 man-days as a typical project may lead you to some spurious conclusions. Why don't you ask your correspondent for his typical sized project, and then work backwards from there? I know he used 100 man-days in his hypothetical example to his management, but is that the real size and scope of the projects he deals with? If the answer is that there is no "typical project," then ask him for what constitutes a small, medium, and large project in his world. Then you can come up with three guiding scenarios. Any "one size fits all" approach is destined to fail in this arena.
I think this fellow would profit from reading my book, or at least sections of it. If he hasn't read The Mythical Man-Month, he should read that one first.
Thanks, Joe
Joe Adds Later
Compared to longer, even multiyear efforts, relatively quick-hit projects are a problem too, because the smaller the estimate the higher the intrinsic risk, relatively speaking.
Max's Comments
That looks like sound advice. The books Joe mentions are:
- The Mythical Man-Month by Frederick P. Brooks, Jr., Addison Wesley, 1995
- The Software Development Edge by Joe Marasco, Addison Wesley, 2005
Joe's book contains some delightful anecdotes and wisdom by a mythical hardball pragmatist known as Roscoe Leroy. In particular, after you have figured out how long your project is going to take, you can use Roscoe's "Square root rule" to figure out how late your project will probably be (in Chapter 11 - Scheduling). By the way, the trapezium that I have adopted is a close approximation to the "S curve" that Joe mentions. The trapezium greatly simplifies the mathematics and I am all for simplicity.
|
Max's
Thoughts on the Issue
