Best Practices for Basic Project Scheduling

These are some of the basic rules that we find to help people avoid long term problems when trying to manage a schedule in any WBS (Work Breakdown Structure) based scheduling software. These basic practices are often ignored when working in applications like Microsoft Project, but they can become problematic when you attempt to manage a schedule in a highly visible online environment.

1. Don't set deadlines while scheduling. We all have deadlines, but setting them in the schedule before having all of the work defined only makes the process more difficult. Without properly defining the work breakdown structure, deadlines have no value.

2. Remember that setting specific date constraints on tasks sometimes means that you will have to edit every task with such constraints when a schedule change occurs. Try to use "As Soon As Possible" and on most tasks. The "...No Earlier Than" and "...No Later Than" constraints can still allow for some dynamic schedule changes.  For example, "Start No Earlier Than" will still allow the date to move later with a schedule change. "Must..." constraints are normally seen as the last choice because there is never any flexibility on these tasks to change without a direct edit of the individual task by the project manager.

3. Never set predecessor/successor relationships between summary tasks. Software allows it, but you will find that it causes many problems as work progresses and the inevitable schedule changes occur. A work breakdown structure within which summary tasks contain dependency relationships is not recommended by the Project Management Institute's PMBOK (Project Management Body of Knowledge) under any circumstances.

4. Do not assign resources to summary tasks. Summary task resource assignments calculate "level of effort" work to the assigned resource. Level of effort assignments should only be used by advanced project managers who have experience with level of effort work assignments.

5. Only one task in a project should be entered without a predecessor. This would be the task that starts the project. Any task that doesn't seem like it should have a predecessor should have the first task as its predecessor. Remember, we are talking tasks here, NOT summary tasks which should have no predecessors or successors.

6. Only one task in a project should be without a successor. This would be the closing task for the project. Any task that doesn't seem like it should have a successor should have the last task as its successor.

7. All tasks should have a "Work" (hours) value when being assigned to resources. While you may not know how many hours the task will take to complete, it is better to have some work in the task than to have 0. The easiest way to do this is to simply allow the default in the system to assign the resource 100% of the hours during the duration of the task. While this may be an incorrect value (most resources are probably doing more than that one task each day of the task's duration), it is usually better to see that the resource is 100% busy throughout the task's schedule than to have it look like the resource is doing nothing on those days.