I believe one of the best ways to estimate task duration is to find a similar project that accomplished the same goal to understand that if the conditions were the same the task should be completed in the same amount of time. Obviously not all projects are the same, therefore understanding the composition of your team is critical. If a task normally takes 1 week to complete, but everyone on your team is inundated with a heavy load of work that could extend the task duration. Another impediment could be your team experience. For example, lets say a task took a staff engineer 1 week to complete, you can not guarantee a new engineer could finish the same task on the same time line. Considering these factors can help project management decide if a task/project needs more or less slack.

Overall, I think its best to decide the slack allotted to a project by considering the factors above and assigning the most amount of slack to the tasks that have the most variability such as in the instance of cross-functional teamwork or having to wait on upper-management approval.

I agree with the point made above, it is important to find projects of similar quality that you can use to best estimate the duration of the task. While often overlooked, I always found it best to overestimate the time it may take just to provide extra time. Overestimating allows for one to account for any unforeseen circumstances early on which could be incredibly useful down the line. Another great idea is to directly communicate with someone who has years of experience in the field. Often times, they have had to estimate task duration and determine slack so you will be able to uncover additional helpful information that you cannot find in previous projects, resources, reports etc. It is also important to properly communicate to the assembled team and understand everyone's strengths and weakness to be able to relate it to the task at hand and establish some type of correlation.

I too agree with the points made above to consult another project or one that is similar to the project at hand and see how long the project took. Being in the industry I have seen on many accounts projects going over the time allocated and closing in on the amount of slack given to the process. In my experiences I think it is important to effectively plan which process has the highest probability of going wrong. The idea of Murphys law of whatever can go wrong will go wrong should be employed to ensure that a certain time table is met. There are many instances where certain unforeseen circumstances do arise and if there was allocated slack assigned to another process, that slack may be reallocated to the problem that was caused.

 I also think it is helpful to have a stead constant stream of information from all the working parts and to reevaluate with the team on a daily basis. This is to ensure that each person on the team is aware of how the time table is progressing and when to expect a deadline to approach. Many times there is a disconnect between the project manager and the people working on the project in terms of timeline and when a deadline appears, often times the project manager is the last person to hear that a process has gone past the due date and is late.

One way to determine task duration would be to ask previous sources, like any of the team members who have done it before or any past projects, and their “Lessons Learned”. It is better to receive accurate time frames from people who have done it before. Someone could attempt to estimate the timing themselves but at the moment they probably wouldn’t consider all the problems that could arise within certain tasks. And from the experience of others it would be better to determine the total task time and from there calculate the slack and this could help make a better estimate for the project slack.

After reviewing the previous responses for this thread, I agree that one approach to constructing a project timeline and setting task timeframes is to review previous timelines for similar projects/tasks to accurately calculate the time required for each task. However, I think an important point to bring up is that a project typically involves cross-functional teams so in order to most accurately set early/late start and finish dates for a task the team should get together and discuss the timeline, especially so that it is apparent what tasks are dependent on others and so that realistic timeframes can be set which take into account the workload/schedules/skills of everyone involved.