Planning a project involves identifying the activities required to deliver the project and the inter-dependencies between those activities. These activities and the dependencies are then modeled onto a network diagram.
Task duration estimates are often padded, as a matter of good practice, but also as a matter of covering one's behind. Things often don't go according to plan and one has to allow for that. If I estimate that task A will take 10 days, and I say it will take 10 days, and then something goes wrong, then not only do I look bad, I might also I end up delaying the next task which was set to begin 10 days later. So the common practice is to be generous with our estimates and pad them for contingencies. Such padding implicitly addresses the risks faced.
There is another approach that integrates project schedules with risk management, and at the same time highlights the possible sources of these risks.
One way to bring this planning to a different level is to first make a realistic and optimistic estimate of how long each task will take. Let's say if a task will take 7 days if no problems occur, then we start with 7. We do the same for each task. Then we study the task and its dependencies and try to understand what could go wrong that can cause its accomplishment to exceed 7 days. Then we try to address those things that can go wrong.
Let's say the person executing the task will normally take 7 days to accomplish the task, but has other stuff on their plate, so may take more that 7 days to complete the task. Why? Because their time and attention could be diverted to the other tasks. If we don't highlight this reason then we can't manage it. Suppose we identified that this person really has other stuff on his plate, then we can take steps. We can schedule his task to be done after he has finished his other stuff, or we can arrange things so that he suspends work on other stuff, or we can just accept things as they are and simply pad the number of days. At the very least, we have identified a possible cause of problems.
There could be other factors to consider: this person could get sick during that time, their machine might break down, they could misunderstand the specifications, or what's required of them and then we will need to redo things, and so on.
By thinking through the possible reasons for exceeding the optimistic estimate, we begin to identify possible causes of delays and we begin to be able to plan for those causes: try to minimize their chances of occurring, minimize the impact if they occur,etc.
***
