Project Management

Linking tasks in work breakdown structures in Microsoft Project

Linking tasks into a network and creating initial duration estimates gives the product manager more control over how a project's tasks relate to each other. It's an important step in managing resources in Microsoft Project.


Linking tasks into a network and creating initial work or duration estimates are crucial steps in the work scheduling process when you’re creating work breakdown structures (WBS) in Microsoft Project. Linking tasks gives the project manager greater control over how tasks relate to each other and the order in which they’re completed. I’ll explain how to create and edit links between your project’s tasks, which you need to do before you can assign resources in Project.

Creating predecessor-successor links
All projects, except the simplest, have linkages between tasks dictating that one task can’t start until another one is completed. This type of linkage is the most basic, and most common, of the links you can use to model the way tasks relate to each other within your project. Figure A shows this basic relationship. If you move back the finish date of the task Write Code, the start date of the Test Code task will move back as well.

Figure A


There are three other types of linkages that give you more control over how tasks relate to each other. These are Start to Start, Finish to Finish, and Start to Finish. Figure B shows samples of the Start to Start and Finish to Finish links.

Figure B


Test Code and Fix Bugs definitely have a link in any project, but a Finish to Start link wouldn’t be appropriate in most cases. You wouldn’t want to wait until ALL the testing was done to start fixing bugs. In most projects, you can start fixing the bugs as soon as you find them. So you can use a Start to Start link to show that the Fix Bugs task can’t start until the Test Code task has started. In this case, I’ve used a lag of one day to say that Fix Bugs starts one day after Test Code starts.

Finalize Documentation is closely linked to the Fix Bugs task because changes in the way things work or removing features can affect the documentation. In Figure B we see a Finish to Finish (with a one-day lag). This tells Project that the Finalize Documentation task can’t finish until at least one day after the Fix Bugs task has finished.

The last type of link is Start to Finish, which says that a task can’t finish until another task has started. Honestly, I’ve never found a place where this kind of link was needed. It’s highly unlikely you’ll need to use this link.

Creating links between tasks is pretty easy, and you have two basic ways to do it. The first way is to select the task that you want to be the Predecessor task, the one that will drive the other task. Then, while holding down the Ctrl key, select the task that you want to be the Successor task. Then you must either click the Edit | Link Tasks menu item, click the Link Tasks tool bar button (it looks like a little link of chain), or press [Ctrl][F2].

The second way is to center your mouse pointer over the middle of the Predecessor task and then, while holding down the left mouse button, drag the pointer to the middle of the Successor task and release the mouse button.

Editing links
Both of the above methods create a Finish to Start link between the two tasks. If you want one of the other types of tasks, you need to edit the link. You do this by double-clicking on the link arrow between the two tasks. This will bring up the Task Dependency dialog box shown in Figure C.

Figure C


To change the link type, select it from the drop-down list. As we said earlier, Lag allows you to put in a duration time between the tasks. A Finish to Start link with one day of duration means that the Successor task won’t start until one day after the Predecessor task finishes. You can also have negative lag. A lag of -1 on the same link means that the successor would start one day BEFORE the predecessor task finishes. Lags can be handy to work into your schedule for things that will take time but don’t need to be tracked because they require no resources or specific work. An example might be burning in a new server. Many people like to put an application on a brand-new server that will put its CPU and other system resources under very high demand. Putting a lag of several days between the last of the initial setup tasks and the start of the “install software” tasks during which the burn-in can occur is one way of modeling this situation.

Rules for using links
There are various opinions about the rules for using links when building the logic into a project plan. Some people feel that links should only be used for factual relationships, i.e., “Build Application” as a predecessor task to “Test Application.” We can refer to this as a factual relationship because it is a fact. One can’t test the application before building the application.

A nonfactual or discretionary relationship is one done out of preference or convenience. An example of this is “Write Document A” and “Write Document B.” There’s nothing about these documents that rely on each other for their completion. Either one could be completed first. The project manager might prefer that B be completed first, and the project manager (PM) knows that the same resource will be used to write them both.

So to avoid having resource leveling move A to start first, the PM might link them together so that B is first and A can’t start until after B is finished. This link exists only to enforce an artificial order imposed by the project manager. This is a common practice, but it can cause problems if the PM doesn’t watch out. For example, if another writer is added to the project, it’s possible for both of these documents to be written at the same time because now there are two writers. If the PM doesn’t remember that this linkage was artificial, it could lengthen the project unnecessarily.

If you decide to use these kinds of links, make a note, either in the Notes field of the tasks involved or in a custom field, that the link is not “really” required. That way you’ll be able to refer back to this note and double-check to see if the link is still a good idea.

Next up: Estimating task size
In part 1 of this series, I described how to create work breakdown structures and offered a bit of the theory behind work package sizing. Here we’ve linked tasks into a network and created initial work or duration estimates. The next step before we can start assigning resources is to estimate the size of the tasks in our project. I’ll cover this in the next article in this series.

 

Editor's Picks