A milestone represents an activity which has no time associated with it, though it can have costs and a resource assigned as responsible for noting this activity as completed. Use these in the case where an activity needs to report when it starts, not its progress or finish date.

An example start milestone would be the beginning of the construction phase of a project once all of the design phase has been completed. In this example, the start milestone serves as a placeholder that marks the end of one set of tasks and the beginning of another.

Another example of a start milestone would be the delivery of a certain item to a job site. The item is scheduled to be delivered at a certain date, and that is the milestone. In this case there may be expenses associated with it, such as the payment for the delivery. There may also be a resource assigned; perhaps a specific person needs to be there to receive the delivery.

Progress payments can be milestones in the schedule, too.

These activities will have a start date, Early Start date and Late Start date. The start date will be calculated as the day after the predecessor finishes work, but can vary based upon calendar settings and settings within the scheduling options. About 5-10 percent of the schedule activities are designated as this type in a typical schedule.

This is very similar to a start milestone, but represents the completion of a set of tasks. The main difference between start and finish milestones is that start milestones cannot have finish constraints and finish milestones cannot have start constraints. (Activity constraints are discussed later in this chapter and within best practices section of this chapter.) These activities will have a finish date, Early Finish and Late Finish date. The finish date will be calculated as the day after the predecessor finishes work, but can vary based upon calendar settings and settings within the scheduling options.

Use these in the case where an activity needs to report when it finishes, not its progress or Start date.

A good metric is that about 5-10 percent of the schedule activities are designated as this type in a typical schedule.

Task dependent activities are those that use the predecessors and successors to derive the sequence of activities. These depend upon predecessors to finish and their successors depend upon them to start. This is most like the natural order of the work and behaves in that way if all settings are correctly set. Choose this setting to have the schedule calculate all dates (Early and Late Start, and Early and Late Finish) based on the progress of its predecessor.

The activity calendar is used to calculate dates in addition to predecessor progress.

About 80 percent of the schedule activities are designated as this type in a typical schedule. Therefore, the most common Activity Type default should be task dependent.

This activity depends on the resource for scheduling. Resource dependent activities are principally used in conjunction with resource loaded schedules where resources have their own resource calendars. Resource dependent activities rely on the assigned resource calendars to calculate all dates (early and late). For this scenario to be successful entirely, the activity should only have those resources with their own calendars assigned to it. This dictates that each resource's calendar be meticulously maintained either as a specific person's or craft's (shared) calendar. The activity can only be scheduled using timeframes in the assigned resources' calendar that was designated as working time. The resource, as a specific person, should have a valid P6 license in order to manipulate their respective calendar. This type of activity is only appropriate when the work simply cannot be scheduled or worked by another person or resource and work will stop and resume only during available timeframes in the resource calendar.

In the following example, a resource dependent activity has several resources, even though the activity duration is 32 days—the Start is July 23, 2012 and the Finish is Sept 6, 2012, an elapsed duration of 45 days. Calendar days would have an earlier Finish. Another link in this chain is that some resources are assigned four hours per day. Non-working time in each resource's calendar is a part of the calculation.

A Level of Effort (LOE) activity is an activity that is not discrete in timeframe, and is supportive of other work in the project. This type of activity automatically expands or contracts with the activities it supports. Typically this activity is related to a Start Milestone as its predecessor and a Finish Milestone as its successor. When the milestones move, the LOE activity duration in between those milestones expands and contracts the duration of the LOE activity.

A good example is security. If you are capturing the time a security team is engaged on the job site, you would tie the Start Mobilization at Job Site Start Milestone activity as a predecessor to the Monitor Security of Job Site activity, and place a Finish Milestone (Complete Job Site Removal) as the successor.

Another good use is for Project Management time. If a Project Manager spends two hours per week in Project Meetings and 4 hours a week in travel, the activity could have a PM assigned for 6 h/w to accommodate meetings and travel. The costs for that travel can be added as resource costs on the Project Management activity with LOE activity type selected. Then, as the project duration lengthens, additional hours and travel are automatically budgeted. Should the project end early, that time is diminished accordingly.

This is shown in the following screenshot. Note the ties to both Project Start and Project Complete milestones and its anchors on either end in the Trace Logic window.

Also note the calculated start and finish dates for the Project Management activity.

This activity is merely a summary of all activities that occur within a given WBS element. The activity Start date is the Early Start of the earliest activity within that WBS and its Finish date is the Late Finish of the latest activity to finish within that WBS element. This is a convenient way to show a higher-level of information for reporting or input without sacrificing the ability to manage or track a lower level of detail in the schedule.

For example, Actual hours are reported via Oracle Progress Reporter or another time sheet application at a higher level than the activities in the schedule. Using a WBS summary activity, the Budgeted or Planned hours will be a sum of all activities within that WBS; but the Actual Units can be input on the WBS Summary Activity. The WBS dates are also derived from the activities within it.

In the following screenshot, the Robot Controller WBS element has an activity called Robot Controller Summary with its Activity Type set to WBS Summary. Note the planned duration of 159 is a sum, the Start is the earliest start within that WBS and the Finish is the latest finish. Since the earliest start is an Actual (indicated by an A after the date) then the WBS Summary activity also shows an Actual Start date. The % complete is also a sum.