Introduction to the basic of scheduling, and DRAG as the metrics for project delays

Why do our time schedules always become longer? In order to make the final delivery date earlier, which part of the schedule should we tackle ? - These are common questions we face in the schedule planning.

There are some basic principles in the scheduling we'd better learn. Plus, there is a metrics that tells us specifically which part to tackle for shorter schedule. Let me explain in this article.

Suppose we have to deliver a system product. This work is comprised of just six (6) activities to be done.

1. Basic design (estimated duration = 20 days)
2.1 Hardware purchase (estimated duration = 35 days)
- preceding activity: Basic design
2.2 Hardware Installation (estimated duration = 5 days)
- preceding activity: Hardware purchase
3.1 Detail design (estimated duration = 10 days)
- preceding activity: Basic design
3.2 Software development (estimated duration = 20 days)
- preceding activity: Detail design
4. System test (estimated duration = 15 days)
- preceding activity: H/W Installation, S/W development

Now, how many days will it take to accomplish this work? It may help us to create a network chart that depicts activities and their relationships. There are a few styles to draw such network diagrams. We here choose the Precedence Diagram which uses boxes for activities and arrows for preceding relations.

(Fig. 1 Precedence diagram of the activity network)

Within each box we write down activity name in the center and necessary duration at the bottom. There are also four small spaces in each box at top-left, bottom-left, top-right and bottom-right. We have to fill in following dates.

top-left: Early Start (ES)
top-right: Early Finish (EF)
bottom-left: Latest Start (LS)
bottom-right: Latest Finish (LF)

These four dates represents “earliest possible start date”, “earliest possible finish date”, “latest possible start date” and “latest possible finish date”. Please remember these terms as they are the four basic parameters used in the scheduling.

If you are smart enough, you may be able to calculate the entire duration after looking at the Fig. 1 just for a few seconds. However, I would like to explain calculation procedure step by step here. Even for very smart persons, it would be not easy to calculate duration of a network containing 100 or more activities.

We start with the first activity “Basic design”. Its ES (earliest start date) is the day 0. Its EF (earliest finish date) is day 20. Then, ES of the following activity “Hardware purchase” should be day 20. And its EF = 20 + 35 = 55. In this manner, we calculate ES and EF of all the activities in the order of precedence. This procedure is called “Forward scheduling”.

By the way, the last activity “System test” has two preceding activities: H/W Installation and S/W development. They have different EF dates (60 and 50). Then which number should we take as the ES value of “System test”? — Needless to say, the system testing cannot start unless the both preceding activities finish. Therefore, we have to take the later date (greater value) of EF as the ES of the next activity. In this case, it is 60.

Rule 1: If there are more than one preceding activities, their largest (latest) ES date becomes ES date of the following activity.

Here we can fill out ES and EF of all the activities. Please see Fig. 2. It tells us that System test will complete in day 75 at earliest. This is the delivery date of this work. However, we have to go on further.

(Fig. 2 Earliest start and earliest finish dates)

Next, we calculate the LF (latest finish) and LS (latest start) date of the final activity, System test. Its LS date is 75. Subtracting the activity duration from EF date gives ES date (75 - 15 = 60). This number should be LF dates for the two preceding activities, H/W Installation and S/W development. In this manner, we can fill in LF and LS of all the activities. It is called “Backward Scheduling”.

Basic design activity has two following activities; H/W purchase and Detail design. LS of H/W purchase is day 20, and LS of Detail design is day 30. This case means H/W purchase has to start at latest on day 20. Therefore, Basic design should finish at latest day day 20.

Rule 2: If there are more than one following activities, their least (earliest) LS date becomes LF date of the preceding activity.

Now, four spaces of all the boxes are filled in. So, let’s pick up activities whose ES equals to LS. It means its earliest possible start date is exactly the date it should start at latest. We call an array of such activities as “Critical Path”. In Fig. 3, the critical path is marked in red.

(Fig. 3 Schedule dates and the critical path)

If ES is less than LS for an activity, it means that the activity have a certain slack in starting date. For instance, Detail design is possible to start on day 20, but it is okay to start even on day 30. This slack is called “Float” in the scheduling theory.

Rule 3: Difference between LS and ES shows schedule float of the activity starting date.

Critical path is a series of those activities whose float days equal to 0. Furthermore, duration of the entire work equals to the length of the critical path. Unless we can make the critical path shorter, we cannot deliver work earlier. In other words, even if we work harder to attain shorter duration of an activity with positive float days, such effort does not contribute to earlier delivery date at all. Therefore, managers has to recognize there the critical path resides and concentrate his/her control efforts to it.

The most unique characteristic of schedule control is the fact that there is a clear distinction between “important” and “non-important” activity. This is quite a different situation from the cost control. Cost control is based on the logic of addition. When we can save $1 for an activity, total cost would be saved by $1. In the schedule control, however, making shorter duration for an activity with positive float does not contribute to earlier delivery of the work.

Up to this point is a basic explanation of the critical path method (CPM). Now, we face a question about the "important activity” - how much is it important? A metrics called DRAG is needed to answer this question.

DRAG is a measurement that shows how many days an activity pushes down the entire delivery date. For instance, DRAG of an activity is zero if that activity has float. In the above example, DRAG = 0 for Detail design and S/W development. On the other hand, for an activity on the critical path that has no parallel activity (like Basic design and System test), its duration becomes DRAG value. This is because existence of such an activity pushes down the final delivery date by its duration. Clearly, the shorter the activity’s duration becomes, the earlier the final delivery date comes.

Some consideration is needed for an activity that is on the critical path but has parallel activities running with. H/W purchase and Installation are these kinds. There is a parallel path: Detail design and S/W development, which has 10 days float. If we shorten H/W purchase by 5 days, then final delivery date becomes 5 days earlier. If we shorten by 10 days, delivery date is 10 days earlier, respectively. However, if we shorten H/W purchase by more than 11 days, then the other path becomes now a new critical path and no effects on final delivery date any more. 10 days are the limit. Therefore, DRAG of H/W purchase is 10 days.

H/W installation has only 5 days duration. It is shorter than float of the parallel path, 10 days. Thus, if we can shorten its duration by 1 to 5 days, then delivery date becomes earlier by the same days. DRAG = 5 days for H/W installation.

Let me summarize the rule with DRAG.
(1) For activities with float days: DRAG = 0
(2) For activities on the critical path with no parallel activities running: DRAG = duration of the activity
(3) For activities on the critical path with parallel activities running: DRAG = float of the parallel activity
(4) Nevetheless, in case its duration is shorter than the parallel activity’s float: DRAG = duration of the activity

Fig. 4 shows this results.

(Fig. 4 DRAG values)

Is there any benefit if we know DRAG values? Yes, there is. DRAG indicates how many days the activity pushes down the final delivery date. If you wish to attain earlier delivery date, then you should tackle activities with larger DRG values. Priority is very clear.

DRAG value also measures how the entire work is out of parallelism. If you would like to make the entire schedule shorter, then you had better break down your work into pieces that can be run in parallel. This parallelism principle applies to any kinds of work, even applicable to construction of pyramid or calculation process in the computer. DRAG clearly shows which activity is out of parallelism.

The above example is made up of only 6 activities, so you may easily find out which one to tackle without computation of DRAG. However, you cannot do it easily with 60 or 600 activities. (As to my business field, engineering projects, 600 activities are not a big number)

Of course, there are certain limitations for the critical path method or DRAG. You can criticize that, say, they are no more than static analyses, or, it is difficult to estimate activity duration precisely by one value, or no resource constraints are considered. But here is one point to keep in our mind. The scheduling is a practice to build approximation models based on various assumptions. Modeling always accompanies with simplification. Still, simplification enables us to see structure of time schedule. “Models are all wrong, but they are useful.” Simple tools are powerful as far as we are know its usage in a simple manner. Scheduling is the same. What matters is how and when to use models and methods.

DRAG metrics was first developed and proposed by Steven Devaux in his textbook “Total Project Control: A Practitioner's Guide to Managing Projects as Investments, ” (1999, 2nd Edition 2015). It will be more useful when applied together with costs. However, this article is already long. So, I would like to write it in next occasion.
by Tomoichi_Sato | 2016-02-13 23:56 | English articles | Comments(0)
<< E-BOM(設計部品表)とM-... 書評:「アプリ開発チームのため... >>