A task driver system for explaining the factors contributing to a task's scheduling and for displaying and navigating between related tasks is provided. In one embodiment, the task driver system stores scheduling considerations for a project. First, the system receives information defining a set of tasks for the project. For example, if the project is a construction project, there may be a task for ordering materials, a task for preparing the work site, a task for constructing the structure, and a task for cleaning up the work site. For each task, the system first analyzes scheduling considerations for the task. For example, with respect to the construction project, constructing the structure cannot begin until the materials have been ordered and received. On the other hand, preparing the work site may be able to proceed before materials are available. Based on the analysis, the task driver system generates a schedule for the task that satisfies the scheduling considerations. For example, if constructing the structure cannot begin until the materials have been received, then the constructing task will be scheduled after the ordering materials task. The ordering materials task may also be given a duration that reflects the expected amount of time required to receive the materials once they are ordered. During the generation of the schedule, the system stores information identifying the factors that contributed to the schedule for the task as task drivers. For example, the ordering materials task caused the constructing the structure task to be scheduled later, so ordering materials will be stored as a task driver for the constructing task. Other factors may also be drivers for the task. For example, if there is a hire workers task in the project, this task could also be a task driver for the constructing task, and would be stored with other task drivers. The system can then display the task drivers and allow a project manager to navigate through the scheduled tasks to view the factors driving the scheduling of a particular task.
In some embodiments, the task driver system provides a user interface for displaying task driver information. The system may allow a particular task to be selected by a user, and then display the drivers for the scheduling of the selected task in a task drivers window. For example, if a user selects the “pour foundation” task of a house building project, the task pane may display predecessor tasks (such as hiring workers), resource calendars (such as waiting for a concrete truck to be available), or other factors such as those described above that contribute to the scheduling of a task. The task driver user interface may display a maximum number of task drivers for a selected task. For example, the user interface may only display a maximum of five drivers for a selected task. If the number of task drivers exceeds the maximum number, then the user interface may show the total number of task drivers, e.g., seven, rather than a list of task drivers. The user interface may also display a maximum number of task drivers for each category of task driver. For example, if there are two predecessor task task drivers and seven resource calendar task drivers, the user interface may list both of the predecessor tasks, but summarize the resource calendar task drivers by displaying only the number seven associated with the number of resource calendar drivers.
In some embodiments, the task driver user interface supports selecting a task driver to obtain additional information about the driver. For example, if the driver is the start or end date of a predecessor task, then the user can navigate to that predecessor task to see what drivers are affecting the scheduling for the predecessor task. If the driver is a resource calendar, then the user can select the driver to see a calendar control displaying the dates the resource is available. The user interface may allow users to navigate forward and backward through a chain of related drivers using controls provided by the user interface so that the user can browse through various tasks in the project to understand which tasks have constraints that could be modified to improve the project schedule. This type of navigation allows a project manager to quickly drill down into problem tasks to find the root task that is delaying the project, or to zoom out from a particular task to determine which related tasks are impacting the task's schedule.
In some embodiments, a scheduling component of the task driver system provides a mechanism (e.g., an application programming interface) for registering listeners that are notified when the schedule has changed. The user interface can use this mechanism to automatically update the display when changes are made that affect the scheduling of a task. By integrating this mechanism within the scheduling component, it is not necessary for the user interface to periodically navigate the entire project schedule looking for changed task information. The change notification may also include information about the information or task that changed.
Many factors may affect the scheduling for a task. For example, a task may have a constraint specifying a start-no-earlier date that specifies that the task cannot start before a specified date, a finish-no-earlier date that specifies that the task cannot finish before a specified date, a must-start date that specifies a date that the task must have started by, or a must-finish date that specifies a date that the task must have finished by. These constraints can be set by the project manager, or determined automatically such as by the availability of a resource. Constraints determined based on the availability of a resource generally result in leveling delay being added to the schedule. For example, it may be more costly to rent a needed piece of construction equipment during the month of July, so a project manager may set a must-finish date prior to July 1 for tasks requiring that equipment. Another factor that can affect the scheduling of a task is an actual start date. The project management software is often used throughout the project, and at some point a particular task may have already started such that there is no longer flexibility to move that task around in the schedule, because it would be an error to schedule the task in the past. Therefore, an actual start date indicates when the task actually started. Another factor that can affect the scheduling of a task is a predecessor task, which can be of type finish-to-start, finish-to-finish, start-to-finish, or start-to-start. A finish-to-start predecessor task indicates that the predecessor task must finish before the dependent task can start. Similarly, a finish-to-finish task indicates that the predecessor task must finish before the dependent task can finish, and so on. A predecessor tasks may also have lag time specified between it and the dependent task. For example, the dependent task may not be able to start until the predecessor task has finished and two days have passed. Another factor that may affect the scheduling of a task is a summary/subtask relationship. A set of tasks may be grouped into a summary task that contains each of the subtasks to facilitate scheduling at a higher level. For example, if the project is building a house, there may be a summary task for the plumbing work, and subtasks within that task specifying installation of various bathroom faucets, the kitchen sink, and so on. Summary tasks may have interdependencies, such as electrical work not being able to begin before the walls of the house are framed, that impact each task's schedule. Another factor that can affect task scheduling is leveling delay. Leveling delay is used to spread out work among resources so that a particular resource is not overscheduled. For example, leveling delay can ensure that a single worker does not get scheduled to work over 80 hours a week. Finally, resource calendars may affect the scheduling of a task. A resource calendar specifies when a resource is available to work. For example, for a worker, the calendar could specify normal work hours during a day, or could indicate unavailability of the worker on a holiday. The calendar might also reflect local ordinances. For example a resource calendar for a bull dozer might reflect certain hours during which loud machinery cannot be used. Task and project calendars could also affect the scheduling of a task. For example, during the summer the project calendar may shift to have longer work hours each day and have Fridays off.
In some embodiments, the scheduling component of the task driver system traverses the tasks when any task in the schedule is changed to determine if the scheduling of any task has been impacted by the change. If the change will affect the scheduling, such as the start date, then the reason for the new start date is stored as a task driver. When the scheduling component discovers a new task driver for a task, it examines the previous set of task drivers for the task to see if the new driver will cause an earlier start date. If the new driver will cause an earlier start date, then the previous drivers are replaced by the new driver. If the new driver will cause the same start date, then the driver is added to the existing list of drivers for the task. A task can have many drivers that affect the task's start date. For example, a predecessor task and a calendar could both be driving a task's start date.
In some embodiments, the task driver system provides a programmable object model for obtaining task driver information programmatically. A driver object may allow enumerating task drivers and provide for navigation between drivers affecting the start date of a task. The object model provides information to other programs similar to the information available to users through the user interface.
Turning now to the figures,
The scheduling engine component 105 may determine a schedule for each task based on data received by the input component. The scheduling engine component 105 may also determine a schedule for tasks based on schedule considerations, such as constraints or dependencies relating to other tasks. Other scheduling considerations may include, e.g., task constraints, actual values that have been reported on a task, start or finish dates of the project or its tasks, status dates for the project or its tasks, dependencies on other projects, or dependencies on milestones or phases within the project or other projects. The scheduling engine component 105 may also determine a schedule for tasks based on operations performed by a user, such as when leveling resources. The user may level resources to, e.g., ensure that a resource is not assigned to more tasks than the resource is capable of completing. When the scheduling engine component 105 determines a schedule for each task, it may store an indication of an explanation for the task's schedule. As an example, the scheduling engine component 105 may store an indication of an explanation relating to a primary consideration, or driver, for determining a schedule for the task. A primary consideration for determining a schedule for a task is a consideration that is actually used to determine the schedule for the task from a subset of considerations that could be used. As an example, when a successor task can begin only after three other predecessor tasks end, the primary consideration may be the predecessor task with the last completion date. Primary considerations may include tasks that are on a critical path. A critical path is a subset of tasks that, if delayed, could delay the project with which the tasks are associated.
The task store component 110 stores the tasks that make up the project and information associated with the tasks, such as the determinations made by the scheduling engine 105 about when the tasks should be scheduled and the current list of drivers for each task. The object model component 115 provides programmatic access to the task driver system. The input component 120 may receive data from a user or other software. The user may provide data using any of a number of user interface elements of the project management software. As an example, the user may type information using a keyboard. Alternatively, the user may retrieve information from storage, such as by retrieving a previously stored schedule. Other software may provide data using an application program interface (“API”) of the project management software or through the object model component. The input component may store the received data in a schedule file, such as in primary storage (e.g., random access memory) or in secondary storage (e.g., hard disk).
The user interface component 150 provides a display for interaction with the user. The user interface component 150 contains a task selection subcomponent 155, a task drivers display subcomponent 160, and a task driver navigation subcomponent 165. The task selection subcomponent 155 lists tasks that are part of the project and allows a user to select a particular task for which the user would like more information. The task drivers display subcomponent 160 displays the drivers for the selected task. The task driver navigation subcomponent 165 allows the user to select a task driver to find more information about that driver, and may also allow the user to navigate a chain of tasks and drivers to visually determine the interaction among related tasks. The user interface component 150 may provide output of schedule information in a variety of means. As examples, the output component may provide schedule information in a Gantt chart, report, or table, or by using an API of other software to communicate the schedule information to the other software.
The computing device on which the system is implemented may include a central processing unit, memory, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices), and storage devices (e.g., disk drives). The memory and storage devices are computer-readable media that may contain instructions that implement the system. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, such as a signal on a communication link. Various communication links may be used, such as the Internet, a local area network, a wide area network, a point-to-point dial-up connection, a cell phone network, and so on.
Embodiments of the system may be implemented in various operating environments that include personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, digital cameras, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and so on. The computer systems may be cell phones, personal digital assistants, smart phones, personal computers, programmable consumer electronics, digital cameras, and so on.
The system may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
A user may be able to input information directly into the textual area by selecting a row, e.g., row 203 corresponding to task number 3, and typing information or performing other user interface operations in a manner generally similar to that which would be performed when using spreadsheet software. As examples, the user may be able to type a name or description for a task, a duration for the task, and indicate that the task is a subtask of a summary task 206.
Each task may have one or more resources assigned to the task. These resources may be displayed in the Gantt chart adjacent to the bar for the task, such as resource 207. In the illustrated example, a “G.C. general management” resource is assigned to task number 3.
Tasks may be linked with one another to indicate time-related dependencies. As an example, a successor task may only be capable of beginning after a predecessor task is completed. This relationship between predecessor and successor tasks may be referred to as a dependency. A dependency that causes a successor task to begin after a predecessor task ends may be referred to as a finish-to-start dependency. When tasks have a time-related dependency (e.g., a finish-to-start or other dependency), the project management software may indicate the dependency on the Gantt chart using an arrow, such as arrow 209. Other time-related dependencies include, e.g., start-to-start, finish-to-finish, and start-to-finish (not shown). A start-to-start dependency may be used when two tasks should start at the same time; a finish-to-finish dependency may be used when two tasks should finish at the same time; and a start-to-finish dependency may be used when the start date of a predecessor task determines the finish date of a successor task.
The user may be able to set or modify schedule information relating to a task (e.g., a constraint or dependency) using bars of the Gantt chart. As an example, the user may drag a left or right boundary of the bar 208 to change the associated task's start date or end date. As a further example, the user may be able to drag and drop the bar to indicate that the task is a sub-task of a summary task (e.g., by moving the bar's position vertically) or change the task's schedule (e.g., by moving the bar's position horizontally).
At block 512, the routine may determine a schedule for the selected task. The routine may call a subroutine of the scheduling engine component or an altogether different component to determine the schedule for the task. At block 514, the routine may update schedule information for the selected task. At block 512, the routine may store the schedule determined in a data structure associated with the task. At block 516, the routine may determine whether there are additional tasks to analyze. If there are additional tasks, the routine continues at block 518. Otherwise, the routine continues at block 520. At block 518, the routine selects the next task and then continues at block 508. At block 520, the routine returns to its caller. By performing these steps, the scheduler component may have determined a schedule for each task of a project and may also have indicated an explanation for determining the schedule.
Although one method of recording drivers is described in
From the foregoing, it will be appreciated that specific embodiments of the task driver system have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. For example, similar techniques could be used outside of the scope of project management. For example, drivers contributing to the selection of particular subcomponents for a hardware device, such as a video game console, could be analyzed to determine which components could be substituted to reduce the cost of the hardware device or enable increased performance. Similarly, the system could be used to analyze drivers contributing to routing decisions on the Internet, to select better routes for transmitting a packet. Accordingly, the invention is not limited except as by the appended claims.