Very quick reply because I have to get to bed (it's 1:30 am here!). I shouldn't work so hard... :-P
Estimation (i.e. pulling numbers out of your posterier) is not necessary (or usually desirable). What you want to do break down the problems into roughly equal size pieces -- the more the better. Each piece will take a certain amount of time. You can measure this and record the average. This becomes the estimated amount of time for each piece. Obviously the estimate has an error with some kind of distribution (my sleep adled brain is unable to remember what a likely distribution for the amount of time something takes).
It doesn't really matter because the sum of all the pieces will give you an estimate for the overall completion time for all the pieces. This estimate will have a normal distribution.
If you write down a list of all the pieces in priority order, you can draw a line at one piece of functionality and determine when it is likely to be completed, along with error bars.
Of course you are unlikely to actually to do the things on your list because if you were able to correctly guess all your requirements before you started the project then you would be in fantasy land. So what you do is tell the stake holders that this is what you are going to do unless they tell you that they want to change their mind.
Of course when you start they will say, "We're not going to change our mind. We're 100% certain that this is right". To which you reply, "Excellent". Every 2 weeks or so, once you have done some work and can show it to the stake holders, you should also have a list of new ideas. You should explain these new ideas and say, "Do you want to change the list to add these new ideas". Whether they say "Yes" or "No", you should reply with, "Excellent" and carry on.
Often the stake holders will have an "emergency" and decide that they have new opportunities which change your list. To this you should say, "Excellent" and change the list.
You should release whenever your stake holders are happy to release.
In this way, you have given the best estimate you can to help the stake holders plan. Any changes to the plan will be made by the stake holders themselves at the earliest possible time. You don't get caught up trying to deliver at any particular date because the stake holders are aware that they are changing the deliverables. You may have to ask them where they want to draw the line and give them new estimates for completion every time they change something, just to reinforce this idea.
The really tricky bit is breaking the work down into small enough pieces. This is very, very difficult and requires a lot of experience. The sucess or failure of the above will very likely rest on the ability to do this, so expect to pay a lot of money for someone with a proven track record doing it. It is often worth hiring a consultant if you have nobody on staff with this experience.
Estimation (i.e. pulling numbers out of your posterier) is not necessary (or usually desirable). What you want to do break down the problems into roughly equal size pieces -- the more the better. Each piece will take a certain amount of time. You can measure this and record the average. This becomes the estimated amount of time for each piece. Obviously the estimate has an error with some kind of distribution (my sleep adled brain is unable to remember what a likely distribution for the amount of time something takes).
It doesn't really matter because the sum of all the pieces will give you an estimate for the overall completion time for all the pieces. This estimate will have a normal distribution.
If you write down a list of all the pieces in priority order, you can draw a line at one piece of functionality and determine when it is likely to be completed, along with error bars.
Of course you are unlikely to actually to do the things on your list because if you were able to correctly guess all your requirements before you started the project then you would be in fantasy land. So what you do is tell the stake holders that this is what you are going to do unless they tell you that they want to change their mind.
Of course when you start they will say, "We're not going to change our mind. We're 100% certain that this is right". To which you reply, "Excellent". Every 2 weeks or so, once you have done some work and can show it to the stake holders, you should also have a list of new ideas. You should explain these new ideas and say, "Do you want to change the list to add these new ideas". Whether they say "Yes" or "No", you should reply with, "Excellent" and carry on.
Often the stake holders will have an "emergency" and decide that they have new opportunities which change your list. To this you should say, "Excellent" and change the list.
You should release whenever your stake holders are happy to release.
In this way, you have given the best estimate you can to help the stake holders plan. Any changes to the plan will be made by the stake holders themselves at the earliest possible time. You don't get caught up trying to deliver at any particular date because the stake holders are aware that they are changing the deliverables. You may have to ask them where they want to draw the line and give them new estimates for completion every time they change something, just to reinforce this idea.
The really tricky bit is breaking the work down into small enough pieces. This is very, very difficult and requires a lot of experience. The sucess or failure of the above will very likely rest on the ability to do this, so expect to pay a lot of money for someone with a proven track record doing it. It is often worth hiring a consultant if you have nobody on staff with this experience.
Hope this helps.