Article Preview
Buy Now
| PDF: |
BKeeney Briefs
Project Estimating
Dealing with the highs and lows of estimating
Issue: 8.2 (January/February 2010)
Article Description: No description available.
Article Length (in bytes): 4,472
Starting Page Number: 53
RBD Number: 8213
Resource File(s): None
Related Link(s): None
Known Limitations: None
Excerpt of article text...
One of the hardest things to do, for me at least, is to come up with good estimates for my consulting projects. Bid too low and you lose money. Bid too high and you might lose the client.
In the ideal world, I would charge every client by the hour. Since most clients want a fixed bid, an hourly project doesn't happen very often -- especially with new clients. Fixed bids are difficult because the client doesn't always know what they want nor understand the process that you go through to create a good REALbasic application.
I put everything into a spreadsheet to make the calculations easier. The first thing I do is have a line item for every major piece of functionality I need in the application. Then I list the windows I know I have to have. I also add some time for testing and for the help system (if the client wants one).
For each of these items I do a baseline hours calculation taking into account if I've done something similar in the past or if I have to do research on it. Then I have another column with my level of uncertainty about that item and there is a multiplier on the base estimate. Things I know very well get a 1 or 1.5 which means I have extremely high confidence that I can do the work (including design, coding, and testing) in that amount of time. Items where there is high complexity or new technology that I need to tackle get a higher number.
...End of Excerpt. Please purchase the magazine to read the full article.
Article copyrighted by REALbasic Developer magazine. All rights reserved.
|
