The CPM Procedure

Finish Milestones

By default, the start and finish times for the different schedules computed by PROC CPM denote the first and last day of work, respectively, when the values are formatted as SAS date values. All start times are assumed to denote the beginning of the day and all finish times are assumed to correspond to the end of the day. If the times are SAS time or datetime values, they denote the first and last second of work, respectively. However, for zero duration activities, both the start and the finish times correspond to the beginning of the date (or second) specified.

Thus, according to the preceding definitions, the CPM procedure assumes that all milestones are scheduled at the beginning of the day indicated by their start times. In other words, the milestones can be regarded as start milestones since they correspond to the beginning of the time period indicated by their scheduled times.

However, in some situations, you may want to treat the milestones as finish milestones.

Consider the following example:

Activity 'A' has a 2-day duration and is followed by a milestone (zero duration) activity, 'B'. Suppose that activity 'A' starts on March 15, 2004. The default calculations by the CPM procedure will produce the following schedule for the two activities:

      OBS   Activity   Duration  E_START      E_FINISH  

       1       A          2      15MAR2004    16MAR2004
       2       B          0      17Mar2004    17MAR2004

The start and finish times of the milestone activity, 'B', are interpreted as the beginning of March 17, 2004. In some situations, you may want the milestones to start and finish on the same day as their predecessors. For instance, in this example, you may want the start and finish time of activity 'B' to be set to March 16, 2004, with the interpretation that the time corresponds to the end of the day. Such milestones will be referred to as finish milestones.

The SETFINISHMILESTONE option in the PROC CPM statement indicates that a milestone that is linked to its predecessor by a Finish-to-Start or a Finish-to-Finish precedence constraint should be treated as a finish milestone. In other words, such a milestone should have the start and finish time set to the end of the day that the predecessor activity finishes. There are some exceptions to this rule:

  • There is an alignment constraint on activity 'B' that requires the milestone to start on a later day than the date dictated by the precedence constraint.

  • Activity 'B' has an actual start or finish time specified that is inconsistent with the predecessor’s finish date.

The alignment constraint that affects the early schedule of the project may not have any impact on the late schedule. Thus, a milestone may be treated as a finish milestone for the late schedule even if it is not a finish milestone according to the early schedule. See Example 4.28 for an illustration of this situation. In addition, while computing the resource-constrained schedule, a start milestone (according to the early schedule) may in fact turn out to be a finish milestone according to the resource-constrained schedule.

Since the same milestone could be treated as either a start or a finish milestone depending on the presence or absence of an alignment constraint, or depending on the type of the schedule (early, late, resource-constrained, or actual), the CPM procedure adds extra variables to the Schedule data set corresponding to each type of schedule. These variables, EFINMILE, LFINMILE, SFINMILE, and AFINMILE, indicate for each milestone activity in the project whether the corresponding schedule times (early, late, resource-constrained, or actual) are to be interpreted as finish milestone times. These variables have a value of '1' if the milestone is treated as a finish milestone for the corresponding schedule; otherwise, the value is missing. In addition to providing an unambiguous interpretation for the schedule times of the milestones, these variables are useful in plotting the schedules correctly using the Gantt procedure. (See Example 4.28).