After defining the project activities and estimated resources, the next step is to define the dependencies of the activities amongst each other and the sequence of their performance.

Before you proceed, please read chapter 4, pp. 160-194 of the textbook (Wysocki 2009).

Apart from activities at the beginning and at the end of a project, each activity requires a certain input from another activity (predecessor), and provides an output, which will be used as an input for the following activity (successor).

Typically, a project has no set of activities subsequently following each other. This is only true for very simple projects. Mostly, activities are dependent on more than one other activity, or activities are carried out in parallel or partly in parallel. This creates a network of activities instead of a sequence.

There are two common ways to build a project schedule:

• Gantt charts
• Network diagram.

Gantt charts

Gantt charts are a popular type of bar charts; it is quite an old way to illustrate project schedules.

Before you proceed, please Wikipedia (2011), Gantt charts, http://en.wikipedia.org/wiki/Gantt_chart

Wysocki (2009) criticizes Gantt charts for their simplicity and lack of information for the project manager. However, personal experience reveals Gantt charts as useful:

• Gantt charts can be easily created; lacking project management software such as Microsoft Project, they can also be created with Excel or even Word.
• Due to its simplicity, it provides a quick overview to the project manager, as well as to the audience in project presentations.
• Newer Gantt charts have additional features, e.g., showing dependencies (see figure below).
• In project management software tools, Gantt charts can be easily created, using the same data as for creating network diagrams.

Gantt chart example: Diagram - Click here

Gantt chart example, also depicting dependencies: Diagram - Click here

Network diagrams

Dependencies and constraints

Activities are dependent on other activities. There are four types of dependencies:

• Finish-to-start dependency: Activity A has to be finished, before activity B may start
• Start-to-start dependency: When activity A has started, also activity B can start.
• Start-to-finish dependency: Only if activity A has started, activity B can begin.
• Finish-to-finish dependency: Only if activity A has been finished, also activity B can be finished.

The most common and simplest case is the finish-to-start dependency.

Various constraints affect the type of the specific dependency:

• Technical constraints
• Management constraints
• Interproject constraints
• Date constraints.

Critical path and activity slack time

For the repetition of the network diagrams, we will use a simplified example of an IT project, developing new system.

The project starts with a design phase (activity 1). Based on this, a prototype will be developed. The prototype consists of two components (activities 2+3), whereas component A is much more complex and requires much more development time than component B. Both have to be integrated to a common system (activity 4). The prototype has to be tested by the end users, e.g., end users of a tourist information system (activity 5) and the staff that has to administer this system (activity 6). Based on the test result, the prototype will be improved and implemented (activity 7). Closing out of the project (activity 8) targets the documentation of and the training of employees on the new system.

The development of a project schedule basically includes two schedules: the early schedule and the late schedule. Activities have an

• Earliest start date (ES)
• Earliest finish date (EF)
• Latest start date (LS)
• Latest finish date (LF),

Depending on the preceding and succeeding activity or activities. Having a look at the example, which is depicted in the following figure, you will see that activities 1 and 2 are connected by a finish-to-start dependency. Activity 2 cannot start before activity 1 has been finished after 20 days (ES = day 21). And activity has to start on day 21 at latest (LS = day 21), because activity 4 “is waiting”.

The situation is different for activity 3: The development of the prototype of component B is less complex and only requires 20 working days. If activity 3 starts on the earliest possible day (ES = day 21), it can be finished on day 40 (EF = 40). However, activity 3 can be started later, without delaying the successor, activity 4. Activity 3 has to be started latest on day 61 (LS = day 61), in order to be completed on the last date, which has no negative effect on the successor (LF = day 80).

This potential “floating” of activity 3 is called the activity slack time.

Diagram - Click here

As you can see, some of the activities in are critical, some rather not. In our example, activity 2 is critical, because a delay in completing the activity automatically leads to a delay of the entire project.

The critical path is the longest path through all activities of the project. Please see below the longest path = critical path in our example.

Diagram - Click here

Compressing the schedule

This section starts with a contrary approach: de-compressing the schedule. A very simple but highly recommended tool is to plan a “management reserve”. This is simply a buffer in your schedule: You will plan more working days for one of the activities than you really expect, preferably an activity at the end of the project. If something is going wrong during the project, you will have a reserve and still are able to finish the entire project within the planned schedule.

Compressing the schedule can be required in two situations:

• Your customer wants you to finish the project at a certain date, which is absolutely impossible with the current project schedule, or
• You have the luxury of a vague project end date, and you can reserve further tools for compressing the schedule for a time, when something is goes wrong and delays occur during the project. Or to say it the other way around: If you are compressing the schedule during the planning phase of the project, you will have no additional buffer, which increases the risk during the project.

There are four major ways to compress a project schedule. Obviously, most promising is to think first about the activities lying on the “critical path”.

1. A first approach is to think about the finish-to-start dependencies. In our example, activity 5 (testing by end users) has to “wait” until preceding activity 4 (system integration) has been completed. It might be the case, the end user tests already might start together with activity 4, switching the dependency to start-to-start. This is the case, if the system component A includes the major design and user interface for the end users, and testing makes sense without an integrated system. The “earliest finish date” (EF) would be shifted from EF = day 130 to EF = day 120, and shorten the overall project duration by 10 working days.
2. Similar to the first approach, an activity can be divided into two sub-activities. The result of the first sub-activity (which is an intermediate result of the activity) might be sufficient to start with the succeeding activity. For example, activity 4 in our example might have a useful intermediate result: components A and component B are integrated, although the system is not yet running with up-to-date data sets. This might be sufficient for starting the end user tests (activity 5), because for testing usability, it is not relevant if the data sets are up-to-date or outdated.
3. The prototyping of component A (activity 2) is the longest activity on the critical path. It might be possible to engage an additional programmer for this activity in order to reduce the duration of this activity and, thus, of the entire project, by 10 or 15 days.
4. Often done, but for the most part, undesirable: Cut the duration of an activity by minimizing the quantity an