The traditional scheduler in IBM Rational Team Concert 4.0

Sharoon Shetty Kuriyala, IBM
Last updated: May 18, 2012
Build basis: Rational Team Concert 4.0

This article describes the scheduling capability in Rational Team Concert 4.0 and factors that determine the automatic calculation of project schedule in a formal project (i.e., a project based on the Formal Project Management process template). The component that handles scheduling for formal projects is referred to as traditional scheduler. The traditional scheduler determines the start and end dates and sequence of the plan items in a formal project.

Schedules in traditional plans

A schedule defines the timing and sequence of work items in a release or an iteration plan. As the plan progresses and you change the schedule information, the schedule is adjusted and recalculated. The schedule of a work item in a traditional plan is determined by the following factors:

• Estimated effort of the work item
• Schedule constraints
• Schedule dependencies on the work items
• Actual start date of the work item
• Resolution date of the work item
• Time spent value on the work item
• Project working days and hours
• Work time, absences, and project allocation dates and allocation percentages of the work item owner
• Ranking of the work item

For example, the Online Teaching and Training Solutions project illustrated below uses a traditional plan with the following plan items:

• Create personal Virtual Classroom
• Add support for Group or 1-1 Classes
• Scheduling of classes
• Online collaboration tools to be supported
• Create personal web conference room
• Teach Live Over The Internet
• Share Whiteboards, Audio, Video …
• Record the classes

(Click for full size image)

To schedule the work for the project, team members must add estimates, constraints, and dependencies to work items. They must also specify the hours and days that they will work on the project, and the availability of the people (resources), who will do the work. If team members are assigned work items with conflicting start dates, they can rank the work items to determine the order in which to complete them.

Work item estimates and the schedule

When you add estimates to the work items in a plan, the scheduler automatically calculates the schedule for the work items. In the example, the “Teach Live Over The Internet”” task has an estimate of 3 days. The start date of the work item is 18 June at 9 a.m. The finish date is 3 days after the start date and is calculated as 20 June at 5 p.m. When the start and finish dates are calculated, the interim non-working days are considered in the calculation.

(Click for full size image)

Note: The example uses the default configuration of the project work environment i.e., 8 working hours per day, and 5 days of work, Monday through Friday, in a week and project working hours specified as 9 a.m. through 5 p.m.

Schedule constraints for work items

Schedule constraints are boundaries that you impose on the start and finish dates of a work item. Formal projects support the following constraint types:

• As soon as possible: This constraint is the default constraint type. It schedules the work item at the earliest possible time it can start, based on the project schedule.
• Start no earlier than: This constraint restricts the work item to start on or after a specified constraint date.
• Finish no later than: This constraint restricts the work item to complete on or before a specified constraint date.

You can apply only one constraint to a work item at a time. Schedule constraints take precedence over other attributes that influence the schedule during the schedule calculation for a work item. In the example, the Start no earlier than constraint is added to the “Create personal Virtual Classroom” task with the constraint date of 20 June. The start date of the work item, which was 18 June at 9 a.m, is now 20 June at 9 a.m. The finish date, which was 20 June at 5 p.m, is 3 days after the new start date: 22 June at 5 p.m.

(Click for full size image)

(Click for full size image)

If a conflict exists when a schedule constraint is added to a work item, the conflict is indicated by an error icon in one of the columns. If you hover your cursor over the icon, you can see a detailed message about the error.
In the example, the Finish no later than constraint is added to the “Add support for Group or 1-1 Classes” task with the constraint date of 21 June. The conflict error is displayed with the following message: “The work item has a Finish No Later Than constraint for 6/21/12, but it is planned to finish on 6/22/12.”

(Click for full size image)

Schedule dependencies on work items

Schedule dependencies define the relationships between tasks that are dependent on each other for completion. You can define schedule dependencies by adding predecessor links for a work item.
Currently only one type of schedule dependency is supported:

• Finish-to-start: In this dependency, the start of the successor work item depends on the completion of a predecessor work item.

For example, the “Add support for Group or 1-1 Classes” task is the successor to the “Create personal Virtual Classroom” task. A finish-to-start dependency is created between the tasks. Because the “Add support for Group or 1-1 Classes” task is the predecessor, that task can start only after the “Create personal Virtual Classroom” task is completed.

Before the dependency was added the successor task start date was Jun 18 and finish date was Jun 22.

(Click for full size image)

After the dependency is added, the start date for the successor is 25 June and the finish date is 29 June. The start date of the successor task is calculated after the finish date of the “Create personal Virtual Classroom” task, which is 22 June. The interim non-working days, calculated according to the project work environment as Saturday, 23 June and Sunday, 24 June are considered in the calculation of the schedule.

(Click for full size image)

In addition, a Start no earlier than constraint with a constraint date of 27 June is added on the “Add support for Group or 1-1 Classes” task. The constraint takes precedence over the schedule dependency, and the task now starts on 27 June even though the predecessor is scheduled to finish on 22 June. In this case, the dependency relationship is applied with a scheduling slack of 2 days. However, this slack does not provide scheduling flexibility. When the critical path is calculated, the slack is not considered, and the “Add support for Group or 1-1 Classes” task is on the critical path.

(Click for full size image)

Note: Scheduling slack is the amount of time that a task can be delayed without having to reschedule the plan’s completion date.

Actual start and finish dates

The actual start and finish dates for a work item are determined by the dates when the state of the work item changes. The actual start date is when the state is changed to In Progress. The actual finish date is when the state is set to Resolved. If you change the status of a work item to In Progress on a non-working day, the non-working date is set as the actual start date. If you change the status of a work item to Resolved on a non-working day, the non-working date is set as the resolution date.
In the example, the “Create personal Virtual Classroom” task is initially scheduled to start on 20 June, with an estimate of 3 days and a finish date of 22 June. On 21 June, the state of the work item is set to In Progress. The actual start date of the work item is 21 June. The task is now scheduled to start on 21 June and finish on 25 June.

(Click for full size image)

On 25 June, the state of the work item is set to Resolved. The finish date of the work item is 25 June.

(Click for full size image)

Note: If the work item’s state is not set to In Progress and directly resolved then the actual start date is set to the resolution date.

Time spent on work items

When you enter a value for the time spent on a work item, the scheduled finish date for the work items is calculated by using the current date and the remaining estimate. The remaining estimate is the estimate minus the time spent value.
In the example, on 22 June the “Create personal Virtual Classroom” task has a finish date of 26 June because no value is entered for the time spent. The remaining estimate is still 3 days.

(Click for full size image)

If you enter 1 day in the Time Spent field, the finish date is calculated as 25 June.

(Click for full size image)

Note: If a work item is started and you enter a value in the Time Spent field without changing the state of the work item, the scheduled start date is the current date.

Project working days and hours

You can specify the work hours per day, quitting time, and work days per week for a project in the Work Environment section of the Project Area editor. The scheduler uses the project work environment settings to determine the non-working days and time when the tasks are unassigned.

In the example, if Saturday is included as a working day in the project area work environment the start date for the “Add support for Group or 1-1 Classes” task is 27 June, and the finish date is 2 July instead of 3 July, since it includes 30 June which is a Saturday as a working day.

(Click for full size image)

Resource availability

If a project requires resources, you can search for available resources and add them to the project. You can also allocate resources to a project on the Work Environment tab of the User editor. If a task in the plan is assigned to a resource who is not allocated to the project, an error message is displayed as illustrated below.

In the example, Alessandro Volta is allocated to the project from 25 June through 2 July.

(Click for full size image)

The “Scheduling of classes” task is assigned to Alessandro Volta. Before the assignment, the task was scheduled to start on 18 June. After the assignment, the start date is 25 June, which the date when Alessandro is available.

(Click for full size image)

In the example, Alessandro Volta is available till 2 Jul; however, the task takes 2 weeks to complete and the scheduler calculates its finish date to 6 Jul. On the Resources tab in the plan, a warning is displayed against the resource because the work item dates are outside of the allocation date ranges.

(Click for full size image)

Resources can be allocated to different project areas with different allocation percentages. The sum of the allocation percentages for a resource cannot exceed 100%. In the example, if Alessandro Volta is allocated to the project for 50% instead of 100%, the start date of the “Scheduling of classes” task is 25 June and the finish date is 20 July. The duration of the task is extended to twice the amount of time.

Resources can be allocated to the project area with single, continuous allocation periods or multiple, discontinuous allocation periods. The scheduler considers the resource availability for the schedule calculation. In the example, Alessandro Volta is allocated to the project with two allocation periods. The first allocation period is 25 June through 29 June, and the second allocation period is 4 July through 13 July. The resource is unavailable for two working days: 2 and 3 July. As a result, the finish date of the “Scheduling of classes” task is scheduled to finish on 10 Jul instead of 6 Jul.

(Click for full size image)

For details about allocating resources to a project, adding allocation periods for resources, modifying allocation periods for resources, and adding allocation periods for a project see Managing project resources.

The schedule is also influenced by the scheduled absences of resources and their work time, which is determined by their work hours per day, quitting time, and work days per week. The scheduler calculates the start and end dates of the work item such that no work is allocated during the scheduled absence or non-working time for the resource.

(Click for full size image)

In the example, a scheduled absence for Alessandro Volta on 29 June is added. The scheduler considers the resource unavailability for the scheduled absence and calculates the finish date for the “Scheduling of classes” task to the next available working day with a delay of one day, which is 9 Jul.

(Click for full size image)

For details about configuring a user’s work time and scheduling absences see Setting user work environments and Scheduling team member absences respectively.

Work item schedule conflicts

One challenge of the scheduling process is when a resource is assigned to multiple tasks that start at the same time. For example, a resource is allocated to a project for 8 hours a day. In the plan, three 8-hour tasks are assigned to the resource for the same day. This situation requires that the resource work 24 hours in one day. In this case, the scheduler reschedules simultaneous tasks with a delay so that they are scheduled sequentially.

The scheduler uses the Ranking attribute of the work item to generate the sequence. If the parallel tasks are not ranked, the scheduler uses the work item ID. The work item that was created earlier is scheduled first.

In the example, the parallel tasks with the IDs of 13, 14, and 15 are scheduled to start at the same time, 18 June.

(Click for full size image)

The tasks are assigned to one resource, Blaise Pascal. Because the tasks are unranked, the priority of the tasks is determined by the work item IDs. Task 13 is scheduled first, from 18 June through 20 June. Task 14 is scheduled next, from 21 June through 25 June. Task 15 is scheduled last, from 26 June through 27 June.

(Click for full size image)

If the tasks are ranked in the following order, the scheduler uses the ranking attribute for scheduling: task 15, task 14, and task 13.

(Click for full size image)

Critical path of the plan

A critical path is the sequence of scheduled work items that determines the duration of the plan. The critical path is the longest path through an iteration or release, and determines the shortest time needed to close the work items in the plan. The traditional scheduler automatically calculates the critical path of the plan. You cannot disable the critical path. To determine the critical path, the following dates are calculated for the work items in a plan:

• Earliest start date (ES): The earliest start date for the work item plus the estimate that is required to complete the work item.
• Earliest finish date (EF): The earliest start date for the work item plus the estimate that is required to complete the work item.
• Latest finish date (LF) : The latest date when the work item can be completed without causing a delay to the plan, depending on the constraints and schedule dependencies on the work item.
• Latest start date (LS): The Latest finish date minus the estimate that is required to complete the work item.

The dates are used to calculate the slack for a work item. The slack for a work item is the difference between the earliest start time and latest start time. The slack indicates whether the work item can be delayed without affecting the original plan schedule.

If the slack is zero, the work item is on the critical path and cannot be delayed without impacting the original plan schedule. All work items that are on the critical path are highlighted in red in the Gantt chart. To bring a plan onto track, reduce the estimate that is required for the tasks on the critical path.

For more information

• Traditional planning: Managing formal projects in Rational Team Concert 4.0

About the author

Sharoon Shetty Kuriyala is the component lead of the team developing the Planning capabilities for Rational Team Concert. She can be contacted at sshettyk@us.ibm.com.

© Copyright 2012 IBM