These are some of the basic rules that we find to help project managers avoid issues when trying to manage a project 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. Avoid the temptation to set too many deadlines on tasks. 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. Avoid using too many specific date constraints on tasks. When a schedule change occurs, you will have to edit every task with such constraints. That's too much manual labor! Try to use intelligent scheduling and the "As Soon As Possible" task type 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. Avoid creating predecessor/successor task relationships between summary tasks. We know Microsoft Project's software allows this functionality, but you will find that it causes issues as work progresses and the inevitable project schedule changes occur. A WBS that has dependencies among summary tasks is not recommended by the Project Management Institute's PMBOK (Project Management Body of Knowledge).
4. Avoid assigning 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 about 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.
For more on intelligent scheduling: