Sometimes, I find it frustrating to get work estimates from colleagues. It is even more difficult to ask for completion dates. It is indeed a difficult task and basically you don't always know what is involved and it is even more difficult to predict what other work will interfere. However forecasting is a necessary task we all have to do at times.
Not everyone is comfortable with making business decisions, since basically that is what you do. I also found that people sometimes misunderstand the context in which these forecasts are asked. Quite often I have to explain that we are in early stages of a project and that a high variation is acceptable or that giving an estimate is not a commitment to deliver any work by a certain date.
I found that the more technical/operational people are, the more reluctant they are to provide estimates. If they give an answer, they want to be exact and accurate. And that is simply not possible when making forecasts. Specifically when high level estimates are required in the early stages of a project. Technicians prefer to give you an answer when they have completed the job.
However, the more frequent people are involved in estimating, the more forthcoming they will become with volunteering estimates. For example, I had a case where a DBA was very reluctant to specify the tasks that needed to be performed. The project manager came to me in despair saying that the DBA was not willing to contribute.
The way I resolved this was by using my little knowledge of what was required. I wrote this down on the white board and asked for confirmation that this was it. As a true techie, the DBA could not stand any inaccuracies and started correcting me. Initially just the minimal information was contributed. Each time I tried to fill in some gaps of information, this was which again corrected. After a while I had a good list of tasks and started adding the expected effort to each tasks. Again these would be corrected. In later planning exercises the DBA was much more forthcoming and learned to contribute and make his how plans.
Identifying task completion dates is another challenge. In some cases you simply get the answer that there are so many unknowns that it is basically impossible to predict. Even project managers at times tend to come with these arguments in order not to give any form of forecast at all. I disagree since you can usually give a best case and a worst case scenario. For any form of planning this is crucial information.
And don't forget that our CEO's, senior management, sales and marketing people have to make predictions of how our business will go, how much money we will earn and how much expenses we have. The uncertainty and consequences they have to deal with is much higher. If they would stop forecasting, just because they can't predict the exchange rate, what the Chinese or what the government will do, we all would be out of a job in no-time.
So, just make a best guess and know that this is not bad at all since you will use much of your experience whether you are fully aware of it or not. The more you do it, the better, or at least more comfortable, you will become.
Not everyone is comfortable with making business decisions, since basically that is what you do. I also found that people sometimes misunderstand the context in which these forecasts are asked. Quite often I have to explain that we are in early stages of a project and that a high variation is acceptable or that giving an estimate is not a commitment to deliver any work by a certain date.
I found that the more technical/operational people are, the more reluctant they are to provide estimates. If they give an answer, they want to be exact and accurate. And that is simply not possible when making forecasts. Specifically when high level estimates are required in the early stages of a project. Technicians prefer to give you an answer when they have completed the job.
However, the more frequent people are involved in estimating, the more forthcoming they will become with volunteering estimates. For example, I had a case where a DBA was very reluctant to specify the tasks that needed to be performed. The project manager came to me in despair saying that the DBA was not willing to contribute.
The way I resolved this was by using my little knowledge of what was required. I wrote this down on the white board and asked for confirmation that this was it. As a true techie, the DBA could not stand any inaccuracies and started correcting me. Initially just the minimal information was contributed. Each time I tried to fill in some gaps of information, this was which again corrected. After a while I had a good list of tasks and started adding the expected effort to each tasks. Again these would be corrected. In later planning exercises the DBA was much more forthcoming and learned to contribute and make his how plans.
Identifying task completion dates is another challenge. In some cases you simply get the answer that there are so many unknowns that it is basically impossible to predict. Even project managers at times tend to come with these arguments in order not to give any form of forecast at all. I disagree since you can usually give a best case and a worst case scenario. For any form of planning this is crucial information.
And don't forget that our CEO's, senior management, sales and marketing people have to make predictions of how our business will go, how much money we will earn and how much expenses we have. The uncertainty and consequences they have to deal with is much higher. If they would stop forecasting, just because they can't predict the exchange rate, what the Chinese or what the government will do, we all would be out of a job in no-time.
So, just make a best guess and know that this is not bad at all since you will use much of your experience whether you are fully aware of it or not. The more you do it, the better, or at least more comfortable, you will become.