Nope, don't use Function points here. But I do have experience in estimating project scope. Here's some ideas:
1) First, get a small upfront check to build the spec. A defined spec will help greatly in creating an estimate for what it takes to complete a project. I typically like to create large scale blueprints outlining the interface flow/design of a project, and they generally don't cost over a couple grand to create. I've found over the years typically more work goes into the GUI and hooking it up, than the back-end. 2) After you have a project blueprint and have gone over it with the customer, you'll need to define the development 'nature' of a project. We prefer a modified Extreme Programming methodology < http://www.extremeprogramming.org/> whereby we set early and frequent milestones with the knowledge things can and will change during the process. At Human Code we generally worked on a different model as a product HAD TO SHIP ON TIME, so we could spec it out, start to finish, at the beginning. Create a schedule and keep to it no matter what. While this did satisfy the customer requirements, it ended up many times creating a less than stellar finished product. 3) If forced to make a not to exceed bid, I generally go over the blueprint, and estimate as accurately as I can how long it will take, then multiply times 3. I typically explain to my customers they get a better and more cost effective project by paying 'by the hour' as opposed to 'fixed bid.' Fixed bids have more detailed specs and a ECN process (Engineering Change Notice) by where we can modify the projected schedule, budgets and deliverables. Lastly, THERE IS NO SUBSTITUTE FOR EXPERIENCE in estimating a project. HTH, Chipp _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
