3 ms·
All estimation techniques follow the same pattern: 1) list all the components and tasks that need to be completed, 2) assign an estimated duration (hours or d
by rmah 16y ago
All estimation techniques follow the same pattern:
1) list all the components and tasks that need to be completed,
2) assign an estimated duration (hours or days) to each task,
3) add them all up and multiply by a fudge factor.
The problem is that none of these are easily done. Step #1 requires a detailed understanding of what you're going to build. Obviously, this is often impossible, but you'll just have to guess. Be sure not to forget categories such as testing, debugging, meetings, etc.
Step #2 relies on experience and your assessment of the client's quality/time trade-off threshold. If you don't have much experience, just guess and then track your time so you can go back and compare reality to your guesses.
The "fudge factor" in step #3 can either be hidden from the client or called "integration phase" or some such. Basically, it is the process of ensuring that all the components are working smoothly together.
Entire books have been written on project planning and estimation. There is no shortcut to doing it well, only experience through the school of hard knocks.
Good luck.
- paulnelligan 16y agomuch thanks. I suppose the answer is to break it into the smallest chunks possible when making an estimation.
- rmah 16y agoThe problem with too much granularity is that you will miss more tasks. This is, of course, offset by each task being easier to estimate. The general rule I use is that the more detailed the requirements/spec and the more static they are, the more granular you make the task list. The more vague everything is, the less granular you make the task list.
- exline 16y agoIf you know yourself, you can find the optimal fudge factor. On projects that I've managed before and currently, I've found 2X is the right multiplier to great developers. The major issue is to a great developer, everything is easy. But its the few tasks that for some reason take up a huge amount of time when they shouldn't. Over time, I've learned to increase my estimated times and decrease my fudge factor because I've done enough estimates. Its always better to under promise and over deliver even if you loose out on a contract now and then. In the long run your reputation will make up for a slightly higher price if people know that you will never go over that price. The major problem is defining the full requirements. Your estimate could be perfect, but it could be an estimate for what the client said, but not what he wants.