Once the project network is defined, we must build in the schedule contingency. A better approach is to wait until the schedule is laid out on the calendar, and any constraints have been established, and then include contingency. It is preferable to wait, especially if there are time related constraints, because the flow of activities may change when the constraints are included.
The amount of time contingency that must be included is known from the risk analysis. The question at this point is where this additional time should be included in the schedule.
The options for the inclusion of contingency are similar to those for then inclusion of budget contingency, and some of the issues are the same. We could add the full contingency at the end of the schedule, immediately prior to the due date, to allow the PM maximum flexibility in managing it. However, this would not make sense to the team, as it would be obvious that they were being driven to complete their tasks too early. Some would balk; some would simply procrastinate, feeling that they were entitled to use the contingency to cover for their own problems. And of course, every time during the project that contingency was needed, the PM would have to readjust the full schedule, moving time from the end of the project back to the spot where it was needed. Another approach would be to distribute the contingency time evenly across all activities. This would have the unfortunate, but expected result that every activity would overrun, using up the contingency in bits and pieces for activities that it was not anticipated would need contingency. So this is not a good method of including it.
A better solution is to allocate time in smaller packages, to different locations. These locations should be on the critical path, and they should follow activities that have time risks. It is always wise to put some time contingency at a point where multiple paths feed into the critical path. This allows some room to maneuver if problems do occur.
So, recapping, after we have the activities from the work breakdown structure, and we work through the dependencies, we can create the project network. Next we have to determine the expected duration time for each of the activities. At that point, we can then take the project network, and lay it out along a calendar. We would line up the activities with no predecessors at the beginning of the network, and they will extend along the calendar over the appropriate times. We can work forward one by one, till all of the activities are lined up along the calendar in the optimal configuration according to the dependencies. Then we look at every activity and determine who will do it. Some of these will be clear, because they are skill based. For others we may have some flexibility. At this point the picture starts to get interesting. We can now look at the calendar, and walk through day by day, or week by week, etc. We can look at this from the perspective of the resources. And we can get a resource profile for every resource on the project.
Was this article helpful?
Of course we all have the same amount of time in the day. But some people struggle to get even the simplest of tasks completed while others can work a weeks worth of jobs into one single day. Time can be our worst enemy or our closest friend. If you are struggling to find the time to get everything in order, if you want to find a way to accomplish a few more dreams and release a few of those huge tasks that seem to be forever hanging over your head, then making time work for you is the key.