Patent Application
20090327020
Project managers often use electronic scheduling tools and/or applications, such as electronic project management applications, to plan and run their projects. Project plans are made up of tasks and resources which are assigned to work on the tasks. Electronic project management applications help the project manager determine the relationships between tasks, track costs, and make assignments of resources to the tasks in order to optimize one or more aspects of the project. As the project progresses, some tasks may need to be removed so that time or budgetary requirements are met. However, when a task or set of tasks are removed from a project plan, they are removed completely and without any audit trail. Project managers would like to know and keep track of information of a task that is removed from a project during the project's execution. The project manager must refer to old saved copies of the project file to see what was removed. There is no easy or deterministic way to gain access to this information. In addition, the project manager may also want to make a conditional scheduling to evaluate different scheduling options while maintaining the costs, constraints, dependencies and resource schedule information of a project in one plan.
It is with respect to these and other considerations that the present invention has been made.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended as an aid in determining the scope of the claimed subject matter.
Embodiments of the present invention solve the above and other problems by providing for scheduling tasks via a project management application. According to one embodiment, a project management application is provided in which an “active or not active” (hereafter, active or not active) task state for each task is displayed in a user interface. The active or not active task state indicates whether the task is inactive or active. If the state of a task is active, the project management application treats the active task as a normal task in the project plan. If the state of a task is inactive, the project management application treats the inactive task as having no effect and may ignore the inactive task for scheduling purposes in the project plan. However, the project management application may maintain and display information of the inactive tasks in the project plan.
The project management application may deactivate an active task so that the task becomes inactive. The project management application may reactivate a previously deactivated task and restore the project plan to its previous state. The project management application may display the inactive tasks in a different style from the active tasks in the user interface.
According to one embodiment, the project management application allows a user to perform conditional scheduling by allowing choices of different scheduling options while maintaining the options information of the project in one plan. The user may enter multiple sets of tasks as optional tasks while keeping only one of the multiple sets of tasks to be activated and the rest of the multiple sets of tasks to be deactivated. The user may evaluate the potential alternatives by deactivating the current optional task and activating a different optional task.
These and other features and advantages, which characterize the present invention, will be apparent from a reading of the following detailed description and a review of the associated drawings. It is to be understood that both the foregoing general description and the following detailed description are explanatory only and are not restrictive of the invention as claimed.
As briefly described above, embodiments of the present invention are directed to scheduling tasks via a project management application. In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustrations specific embodiments or examples. These embodiments may be combined, other embodiments may be utilized, and structural changes may be made without departing from the spirit or scope of the present invention. The following detailed description is therefore not to be taken in a limiting sense and the scope of the present invention is defined by the appended claims and their equivalents.
Referring now to the drawings, in which like numerals refer to like elements through the several figures, aspects of the present invention and an exemplary computing operating environment will be described.
Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. In addition, the invention may be practiced in an Internet web-based environment where components of the invention, including rich client user interface components, described and illustrated herein, may be hosted in a website remote from users of the components of any given embodiment of the invention.
Referring now to
The mass storage device 114 is connected to the CPU 108 through a mass storage controller (not shown) connected to the bus 110. The mass storage device 114 and its associated computer-readable media provide non-volatile storage for the computer 100. Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available media that can be accessed or utilized by the computer 100.
By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, digital versatile disks (“DVD”), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer 100.
According to various embodiments of the invention, the computer 100 may operate in a networked environment using logical connections to remote computers through a network 104, such as a local network, the Internet, etc. for example. The computer 100 may connect to the network 104 through a network interface unit 116 connected to the bus 110. It should be appreciated that the network interface unit 116 may also be utilized to connect to other types of networks and remote computing systems. The computer 100 may also include an input/output controller 122 for receiving and processing input from a number of other devices, including a keyboard, mouse, etc. (not shown). Similarly, an input/output controller 122 may provide output to a display screen, a printer, or other type of output device.
As mentioned briefly above, a number of program modules and data files may be stored in the mass storage device 114 and RAM 118 of the computer 100, including an operating system 132 suitable for controlling the operation of a networked personal computer, such as the WINDOWS® operating systems from Microsoft Corporation of Redmond, Wash. The mass storage device 114 and RAM 118 may also store one or more program modules. In particular, the mass storage device 114 and the RAM 118 may store application programs, such as a software application 124, for example, a word processing application, a spreadsheet application, a slide presentation application, a database application, etc.
The mass storage device 114 and the RAM 118 may also store a project management application 150. According to embodiments of the present invention, an example of a suitable project management application 150 is MICROSOFT OFFICE PROJECT manufactured by Microsoft Corporation of Redmond, Wash.
Embodiments of the invention may be implemented as a computer process (method), a computing system, or as an article of manufacture, such as a computer program product or computer readable media. The computer program product may be a computer storage media readable by a computer system and encoding a computer program of instructions for executing a computer process. The computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process.
According to an embodiment, the active or not active task state module 152 is configured to create and support a task property, “active or not active”. The active or not active property is a property that defines a state of a task. The state of a task may be active or inactive. According to one embodiment, the active or not active task property may be a Boolean which may have “yes” for “inactive” and “no” for “active.” The active or not active task property is configured to change between “active” and “inactive” by a menu option, toolbar button, or any other suitable way, as should be appreciated by those skilled in the art.
A project manager or user (the terms “project manager” and “user” may alternatively be used in the discussion herein) may deactivate a task. When a task is deactivated, it becomes inactive. The deactivated task does not disappear from view totally. The inactive state may be indicated in a user interface (e.g., the Gantt chart view 154) of the project management application 150 by coloring the task and its attributes a light grey as opposed to black or dark blue as tasks are traditionally rendered. As should be appreciated by those skilled in the art, many other suitable embodiments may be configured to indicate a state of an inactive task in a user interface or like.
According to an embodiment, an inactive task no longer affects the project plan. Costs and scheduling constraints associated with the inactive task are ignored by the project management application's scheduling engine. In some ways, the project management application 150 behaves as if the inactive task were in fact deleted. However, the benefit of this active or not active task state property is that inactive tasks are not deleted. The inactive tasks remain stored in memory and in the project plan file, along with all of their costs, constraints, dependencies and resource schedules information. Thus, this information is still accessible to the project manager after the task has been deactivated. Additionally, the project management application 150 supports “reactivating” tasks, which allows the inactive task to be returned to active or normal status. Since all previously entered information in regards to the tasks is maintained, the project plan can be completely restored to the state it was in before the tasks were deactivated. Typically, deactivating a task may be done any time the project manager wants to experiment with removing, re-scoping or otherwise altering certain aspects of his/her project, without permanently committing to the removal of the potentially valuable task information. In addition, a project manager may add a buffering task in the project plan. By deactivating and reactivating the buffering task in the project plan, the project manager then may easily see what the scheduling, resources, costs and other information of the project will be with or without the buffering task.
According to one embodiment, subtasks of a larger abstract task may be grouped together under a parent, or “summary” task. A summary task summarizes (totals) the work of the child tasks underneath it. A summary task may have another summary task as one of its children. In this way, tasks groups can be nested to many levels of indent. According to one embodiment, if a summary task is deactivated, all of its child tasks may be automatically deactivated. Similarly, if an inactive summary task is made active, then all of its child tasks will be made active. If an inactive child task is activated, its summary task may be activated as well. However, in that case other children of the summary task may not be necessary to be reactivated. As should be appreciated, many other suitable embodiments, mechanisms and algorithms may be configured to deactivate and activate summary tasks while deactivating and activating their child tasks.
According to another embodiment, inactive tasks are still “live” in the sense that various aspects about them such as their dependencies, constraints and resource schedules information may still be accessible and editable. Scheduling and internal consistency calculations may still be carried out on the inactive tasks which are adjacent. This accessibility and consistency feature of an inactive task allows the project manager to continue to work with the inactive tasks without affecting the rest of the current plan of record, perhaps as a prelude to activating the tasks at a future date. The project manager thus may intelligently interact with the inactive portions of the project.
The functionality of deactivating a task may seem similar to deleting a task, and then later using the “undo” feature of the project management application 150 to undo the delete. However, there are important differences between them. First, when a task is deleted, all the information in regards to the task is removed from the plan. Hence there is no way to see or measure the scheduling information of deleted work. Second, undo only works within a single session of the application. When the project management application 150 is exited, or the project plan file is saved and given to another project manager or user, the other user cannot undo at that point. According to an embodiment of the present invention, inactive tasks may be activated at any time, even between application sessions or between different users over a large period of time. Third, a user may only undo operations in an exact order they were carried out (e.g., “first in first out” order). However, according to one embodiment of the present invention, sets of inactive tasks may be activated in any order.
According to an embodiment, the project management application 150 is configured to support a project manager or user for performing conditional scheduling by making a choice in different options while maintaining information of the project in one plan. For example, a project manager may plan two or more equivalent series of tasks, which all reach a same goal (but perhaps with different resource allocations or task orders). All but one of the series may be deactivated at any given time. This allows the project manager to easily evaluate the potential alternatives over time, and switch to a different option by deactivating the current optional task and activating a different optional task.
According to one embodiment, the project management application 150 may be configured to include a filter (not shown) to filter out inactive and active tasks. For example, in the Gantt chart view 154, a project manager or user may choose filter only active tasks, filter only inactive tasks, or filter to see both inactive and active tasks.
Referring to
Referring to
The task name, duration, start, and finish columns 304, 306, 308, 310 display a task name, duration, start date, and finish date of each task respectively. For example, the task in row 1 is “roofing”. The roofing task has duration of seven (7) days for completing this task. Its start and finish dates are scheduled to be May 5 and May 11 respectively.
The predecessors column 312 displays a predecessor (if any) for each task. A task may start only after its predecessor is finished. For example, the task “insulation” (row 7) has the tasks “roofing” (row 1) and “siding” (row 4) as predecessors. The insulation task may start only after both the roofing and siding tasks are finished.
Additionally, as discussed above, subtasks of a larger abstract task may be grouped together under a parent, or “summary” task. A summary task summarizes (totals) the work of the child tasks underneath it. A summary task may have another summary task as one of its children. In this way, tasks groups can be nested, potentially to many levels of indent. In the example illustrated in
The active or not active column 302 displays the actual value of the active or not active property of each task. As illustrated in the example project of
In the example project, the roofing task is scheduled to start on May 5 and runs for seven (7) days. The siding task is scheduled to start also on May 5 and runs for 14 days. The insulation task has the roofing and siding tasks as predecessors. Since the insulation task depends on both the roofing and siding tasks, the insulation task may start only after both the roofing task and the siding task are finished. The earliest date for the insulation task to start is scheduled on May 19.
Referring to
The insulation task is now scheduled like it has only the roofing task as a predecessor, so it may start on May 12. The predecessor relationship to the siding task, which would have pushed the start date of the insulation task out to May 19, while still maintained in the plan (and visualized), is ignored for scheduling purposes. Still, precedence relationships and scheduling may be maintained within the set of inactive tasks. For example, the child task “siding-sub1” is still scheduled to start on May 5 as it would have had it not been inactive. Another child task “siding-sub2” is still affected by its predecessor task “siding-sub1”, and does not start until the siding-sub1 task finishes. The siding task may easily be reactivated by changing the active or not active property value of the siding task from “yes” to “no” and the situation would return to
In the example housing project illustrated in
The task “insulation” may now be scheduled like it does not have the task “wood siding” as a predecessor. The insulation task may start on May 15 as the insulation task has the stucco task as a predecessor which will be finished on May 14.
The project manager may try it the other way. Namely, the project manager may deactivate the stucco task and activate the wood siding task to choose the wood siding option. As illustrated in
The insulation task is now scheduled like it does not have the stucco task as a predecessor. The start date of the insulation task is pushed out for four (4) days and the insulation task is scheduled to start on May 19 because the wood siding task, which is the predecessor of the insulation task and is scheduled to finish on May 18, is now active.
As illustrated above, the project manager may easily evaluate the potential alternatives (i.e., the “stucco” and “wood siding” options in the example illustrated in
It should be appreciated that various embodiments of the present invention may be implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention. Accordingly, logical operations including related algorithms can be referred to variously as operations, structural devices, acts or modules. It will be recognized by one skilled in the art that these operations, structural devices, acts and modules may be implemented in software, firmware, special purpose digital logic, and any combination thereof without deviating from the spirit and scope of the present invention as recited within the claims set forth herein.
Although the invention has been described in connection with various embodiments, those of ordinary skill in the art will understand that many modifications may be made thereto within the scope of the claims that follow. Accordingly, it is not intended that the scope of the invention in any way be limited by the above description, but instead be determined entirely by reference to the claims that follow.
