How Tasks Become Dependent in Project 2013
There are two kinds of tasks in Project 2013: scheduled tasks and auto-scheduled tasks. If you allow the auto-scheduling and your network logic (dependencies) to build in timing logic rather than manually assign specific dates to tasks, Project can reflect changes to your schedule and adjust the dates and timing automatically.
For example, if the task of receiving materials in-house is delayed by a week, the dependent task of starting the manufacturing process moves out a week automatically. You can note the change when you’re tracking activity in your plan, and Project makes adjustments accordingly.
The alternative is to change the start date of just about every task in your schedule every time a task is running late; you don’t even want to think about doing that!
As with human relationships, every dependency relationship involves roles: Each task is either a predecessor or a successor. Any two tasks with a timing relationship can be a predecessor-successor pair, even if the timing of the two tasks overlaps or they’re set to happen concurrently. Remember that the predecessor task’s schedule has an impact on when the successor task is scheduled, particularly under the auto-scheduling method.
Task bars in Gantt Chart view graphically depict the predecessors and successors in dependency relationships between tasks. Notice how task bars represent the relationship when a task starts after another task. Also notice the lines drawn between tasks: These lines indicate dependency links.
Here’s some important advice about dependencies: You can have more than one dependency link to a task, but don’t overdo it. Many people who are new to Project 2013 make the mistake of building every logical timing relationship that can exist. If the situation changes and the dependencies have to be deleted or changed, the web of dependencies starts to get convoluted — and can easily create a nightmare.
For example, you must complete the tasks of obtaining a permit and pouring a foundation for a building before you can start framing it. However, if you set up a dependency between obtaining the permit and pouring the foundation, setting a dependency from foundation to framing is sufficient to establish the correct timing.
Because you can’t start pouring the foundation until you have a permit, and you can’t frame until you pour the foundation, framing can’t start before you have a permit. This common mistake is known as having a redundant predecessor.
You don’t have to use dependencies to prevent resources from working on two tasks simultaneously. When you set the availability of resources and assign them to two tasks happening at the same time, you can use tools such as Team Planner view and resource leveling rather than establish a dependency that forces one task to happen after another. This feature delays tasks whose scheduling causes a resource over allocation.