Creating a Project Schedule

In its simplest form, a project schedule is a list of tasks with their respective due dates. In its most developed form, a project schedule is a dynamic tool that defines not only what needs to be completed and when, but also how the project tasks impact upon one another. For a project to be successful, it generally must be completed as defined, within the estimated time, and within budget. So what happens when one task cannot be completed on schedule? What impact does that have on the completion of subsequent tasks? How does that affect the costs related to the project? Will the resources assigned to the project be sitting around with nothing to do while they wait for a task to be completed? What happens if a task is completed early? Can the next task begin, or must it wait until a prescribed date or time?

Unless you, as project manager, can answer these questions, the success of the project is at risk. Microsoft Project can help you know the answers long before something outside of your control has an impact on the project plan. With this knowledge you can prepare for any possible contingency.

Identifying Predecessor and Successor Tasks

Linking tasks is Project’s way of showing you how tasks are related to each other. By linking tasks, Project can make the necessary adjustments to the schedule whenever there are changes that affect the start or completion of other tasks. No matter how invested you are in a schedule, you can’t move an office if the moving van doesn’t arrive; you can’t train new staff if they haven’t been hired yet. By linking tasks, you create a project schedule that is realistic and logical, updates automatically when tasks are delayed or completed ahead of schedule, and provides you with a clear plan of the resource needs at various points throughout the project.

When tasks are linked, the task that must be started or completed first is called the predecessor and the task that depends on the predecessor is called the successor. In Figure 8.1, it’s clear that before the architectural drawings can be completed, suitable office space must be found. Before offices can be assigned, the drawings must be completed, and before furniture can be ordered, the offices must be assigned. If all these tasks come to completion all at the same time, or in a different order than what is expected, the drawings won’t fit the space, too much furniture might be ordered, and people might be assigned to offices that didn’t even exist. The sequencing of the tasks is essential to each task’s successful outcome, and one task is clearly dependent on the other. The arrow between tasks shown in Figure 8.1 plainly shows the dependency relationship. The arrow points to the dependent, or successor, task. In this example, Task 3 is a successor of 2, Task 4 is a successor of 3, and Task 5 is a successor of 4.

click to expand
Figure 8.1: Linked tasks must be completed in order.

When these tasks are actually underway, the relationships might not be as clear. Figure 8.2 shows the comparison of actual Start and Finish dates with the Baseline (planned) Start and Finish dates. In Figure 8.2, you can see that Task 2, Find Suitable Office Space, took a day longer than planned to complete. As a result, Task 3, Create Space Drawings, could not start on schedule because it is dependent on Task 2. The start of Task 3 was delayed by several days. Because the task started behind schedule, it was decided that as soon as a general sketch of the office was laid out, offices could be assigned (Task 4) and furniture could be ordered (Task 5). This decision actually benefited by the project by putting it about four days ahead of schedule.

click to expand
Figure 8.2: Comparing planned and actual schedules

Not every task in a project may have a predecessor or successor, but defining those that do can help you develop a realistic schedule and keep the project on track.

Using Different Types of Relationships

Defining task relationships is not always as straightforward as the terms predecessor and successor suggest. The most common type of relationship, called a finish-to-start relationship, is a relationship in which one task, the successor, can’t start until the predecessor is completed; however, not all relationships fit this pattern. With Microsoft Project, you can define four types of relationships between tasks.

Finish-to-Start (FS)

A finish-to-start relationship is the default relationship in Project, and it is the most common type of dependency. In a finish-to-start dependency, one task cannot start until another task finishes. For example, you cannot distribute new office furniture until the furniture arrives from the vendor. Figure 8.3 shows a typical finish-to-start dependency.

click to expand
Figure 8.3: A finish-to-start relationship

Start-to-Start (SS)

A start-to-start dependency is a dependency in which one task cannot start until another task starts. In this type of dependency, the successor task may be able to start immediately or soon after the predecessor starts, rather than waiting until the predecessor task finishes. To use an everyday example of a start-to-start relationship, baking holiday cookies is an obvious predecessor to decorating the cookies; however, you don’t need to wait until all of the cookies are baked to begin decorating. By adding lead time to the decorating task, you can start the decorating as soon as the first batch comes out of the oven and cools a bit.

Note 

For more about lead time, see “Allowing for Task Delays and Overlaps,” later in this chapter.

Figure 8.4 demonstrates a start-to-start relationship in the Office Decentralization project. One of the groups of tasks in this project involves hiring staff for the new office. In this example, as soon as the people responsible for hiring begin reviewing resumes, they can schedule interviews with likely candidates. A day of lead time allows the interview team to contact the candidates and set up the interviews.

click to expand
Figure 8.4: A start-to-start relationship

Finish-to-Finish (FF)

When a finish-to-finish dependency is established, one task cannot finish until another task finishes. In this type of dependency, start dates are irrelevant to the relationship. What matters is that the predecessor finishes before or at the same time as the successor. Let’s say, for example, that two interview teams are responsible for interviewing and coming up with a list of hiring recommendations. The team that hires sales staff must finish before the office hiring team finishes, to make sure that appropriate office staff is employed to meet the needs of the sales managers.

In Figure 8.5, the task of interviewing was divided into two separate tasks: interviewing sales staff, and interviewing office staff. Each task has a start-to-start relationship with reviewing resumes. In addition, the two interviewing tasks have a finish-to-finish relationship with each other. Interviewing the sales staff must be completed first, so it is the predecessor task. Interviewing the office staff cannot be completed until the sales staff interviews are complete, so interviewing the office staff is the successor task.

click to expand
Figure 8.5: A finish-to-finish relationship

Start-to-Finish (SF)

The last type of dependency is a start-to-finish dependency. In this type of relationship, the finish date of one task is dependent on the start date of the other task. For example, if painting the new office space is scheduled to start in the afternoon of January 6, the paint should be delivered freshly mixed in the morning of January 6. If the mixing is completed too soon before the painting begins, it may have to be remixed on-site. If the painting is delayed because the painters are held up on another job, the paint should not be delivered at all. Figure 8.6 shows the start-to-finish relationship between these two tasks.

click to expand
Figure 8.6: A start-to-finish relationship

Although the mixing of the paint occurs first chronologically, the process of mixing and delivering the paint is dependent on the start date of the painting. In this instance, painting is viewed as the predecessor and mixing is the successor.

Tip 

To decide which task is the predecessor and which is the successor, ask yourself this question: If the start or finish date of a task changes, will it affect the scheduling of the other task? The scheduling of a successor (dependent) task is always affected when the scheduling of its predecessor changes.



Mastering Microsoft Project 2002
Mastering Microsoft Project 2002
ISBN: 0782141471
EAN: 2147483647
Year: 2006
Pages: 241

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net