Project 3 Feedback

Here are some of the problems I found in p3:

1. Most people are not yet utilizing the Planned Error field in the Time tab window of Hee. This is the field right below the total time value with a plus-or-minus symbol beside it. This is an extremely important field for you to start working with. The reason is because the value changes your estimate for the time involved with the project from a single value to a *range* of values, and this is critical to your future relationship with your manager.

   Let's say you go to your manager and say, I think this project is going to take 500 minutes. What do you think the odds are that your estimate will be correct? Probably almost 0---you might take 510, or 450 minutes, or something reasonably close, but you're almost certain to be wrong. It is never good to start out with an almost 100% chance of error!

   Instead of supplying management with a single value, what you really want to do instead is supply management with a *range* in which you believe the actual time for your project will fall. You want your range to be narrow enough that your manager can plan resources effectively, but wide enough that there is a very high probability that your actual time will fall inside of it. If you say the project will take somewhere between 1 week and 3 years to complete, of course, your manager will be irritated at you.

   The question is, what range to use? Your prior Leap data can help you out here. Look at the error values from previous projects to get a sense for the percentage you've been off previously. Then use that percentage as a guide for calculating the actual number of minutes you think the current project you're planning could vary, plus-or-minus.

   Once you complete the project, look at the difference between your actual and estimated, and see if it did indeed fall within the range. If it did, then you accurately estimated the time for the project. Whether you precisely estimated the time for the project depends upon how big your range was.

2. A few people are coming in with a bogus entry in their size definition table (Aama). Aama should have exactly one size definition, called "JavaSize". Please check and if you have another size definition in there, delete it.

3. A few people have come in with a bogus entry in their document type table (Puaa) called "JavaSize". (This is a good size definition type, but a bogus document type.) If you have a document type called "JavaSize", please delete it.