|
Estimating summaryAt this time the estimating summary looks like this:
The obvious question is "Which estimate is right?" The answer is that you won't know until the project is complete, and in the end, both may be wrong. That being said, here are my final thoughts.
Estimating using FPA and Hours/FPIn practice, if I know my teams, and have historical data to work with, I've found that the FPA estimates based on Hours/FP are the most accurate. Stated simply, when I had to bid fixed-price projects, this is the only way I was willing to proceed. On my first fixed-price FPA based estimate I came up with a projected cost of $45K, and my developers - using WBS - estimated $20K for the same project. I bid $45K, we came in at $42K, and I haven't looked back since then. The hardest part about estimating using the FPA-based approach is knowing what to do when several variables change at one time, including new business analysts, new developers, and new technologies. When this occurs you have to use your best judgment, then keep an eye on the project, trying to see as early as possible whether your estimate is accurate or not. (But this problem isn't any scarier than trying to provide the same estimate using WBS, is it?) I've mentioned in other writings that IFPUG studies have shown that FPA processes add less than 1% to overall project costs, so given their benefits, I can't think of any reason software teams should not to use an FPA-based approach. Estimating using WBSI've found that the WBS approach almost always significantly underestimates the required time and cost for a project, and that you need a multiplier (fudge factor) to make these estimates right. The bad news is that I've seen this fudge factor vary from a low of 1.25 to a high of 2.5, and this factor varies by the person making the estimate. The good news is that people who make WBS estimates are usually consistent in their approach, so if you have to multiply their estimates by 2.0 to make them right, their multiplier usually ends up always being close to 2.0, so you use that same multiplier when estimating their future projects (unless they are making an effort to get better, as I discussed earlier).
|