Patent Application
20120109706
Within an enterprise, such as a company, educational organization, government agency, and so forth, projects are performed as part of the operations of the enterprise. Often, there can be issues relating to a project that may adversely affect performance of the project.
Some embodiments are described with respect to the following figures:
Personnel associated with an enterprise, such as a company, educational organization, government agency, or other organization, can be engaged in performing various projects. A “project” refers to a collection of activities to be performed by an individual or a group of individuals. Examples of projects include a project to provide information technology support, a project related to development of a product or service, a project related to delivery of a product or service, and so forth. As used here, the term “project” can refer to an individual project, or alternatively, to a portfolio of projects.
During the lifecycle of a project, alerts (e.g., warnings, alarms, or other status indications) may be raised to provide an indication to a decision maker regarding a potential issue, where this potential issue may adversely affect the success of the project. A decision maker has to decide how to react to the issue, by assessing the cause and choosing the most appropriate course of action to address the issue. Typically, a decision maker relies upon the decision maker's experience and other knowledge to manually select the action(s) to take. However, such manual selection of action(s) is time-consuming and may result in an action that does not effectively address the issue. As a result, the project may fail, or the project may not meet customer expectations.
In accordance with some embodiments, techniques or mechanisms are provided to allow for automated generation of recommended action(s) to take for addressing a particular issue faced by a particular project (e.g., an active project that is currently under consideration).
In some examples, the indication that is received (at 102) can be based on a predefined rule, which can describe a condition relating to a status indication for the particular project. For example, the rule can be as follows:
If (ProjectStageCost>ProjectStageCostThreshold) Then SignalRed, where SignalRed represents a status indication (for indicating an alarm), ProjectStageCost is a metric that represents a given stage of the particular project, and ProjectStageCostThreshold is a predefined threshold. In response to the status indication Signal Red, the process of
Although a specific example is provided above, it is noted that other implementations can employ other types of status indications and other metrics. Note also that a metric can be a raw project measurement (e.g., actual cost), or the metric can be a derivative of a raw project measurement (e.g., probability of actual cost exceeding a threshold).
There can also be multiple rules involved in generation of a status indication, where these multiple rules can be chained. In the context of chained rules, the identification (at 104) of information relating to the particular issue can involve backtracking through the rules of the chain to determine a root cause. Moreover, there can be more than one trigger for any particular status indication, where the more than one trigger can involve multiple metrics violating multiple predefined criteria, for example.
In response to the identifying of the information (at 104), the process of
The condition described by the rule can be represented as an expression, where the expression can specify one or multiple metrics associated with the project and a relationship of the one or multiple metrics with respect to one or multiple criteria. The expression can include a logical operator, a conditional operator, or some other type of operator. The operator acts on one or multiple metrics associated with the project. Example project metrics include cost, time, resource, quality, and so forth.
The rule describing the condition that is based on a probability of an issue occurring can be specified by a user, such as a project manager. The rule can be manually or automatically created or adjusted, or alternatively, the rule can be a default rule provided for a particular project type, organization, industry sector, and so forth. As examples, the condition can be based on a probability of a project metric (cost, time, resource, quality, etc.) being a certain value or within a certain range (e.g., between two thresholds, below a threshold, or above a threshold).
Once a condition is satisfied, then a status indication can be produced. The status indication can be set to one of plural states. Based on the condition being satisfied, the status indication is selectively set to one of plural states. Where the condition is deterministic, the plural states may include, for example, a first state indicating that a project is healthy, a second state providing an actual warning (indicating, for example, that an issue has reached a state that is adversely affecting the project) and one or more intermediate states to provide an early warning (to indicate, for example, that an issue that can adversely affect the project has or is about to occur). Where the condition is probabilistic, the plural states may include, for example, a first state indicating that a project's future health state is predicted to be good, a second state providing an early warning (indicating that the project's future health state is likely to be bad, for example, an issue is likely to adversely affect the project) and one or more intermediate states to provide an early warning (to indicate that the project's health state is likely to move to a questionable state, e.g. an issue that can adversely affect the project has a worrying likelihood of occurring). Additionally, a further action can be taken in response to the condition being satisfied.
In some implementations, the generation of the status indication (206) can be accorded to techniques or mechanisms described in U.S. patent application entitled “Providing a Status Indication for a Project,” (having Attorney Docket No. 201000488-1), filed of even date herewith. In other implementations, other techniques of producing the status indication 206 based on a rule (or multiple rules) can be employed.
The status indication (206) produced by the health scoring module 204 is provided to a diagnosis module 210. In some implementations, the diagnosis module 210 is configured to perform tasks 102 and 104 depicted in
Once the information relating to a particular issue (associated with the status information 206) is identified by the diagnosis module 210, the diagnosis module 210 passes such issue information (212) to a recommender module 214. The diagnosis module 210 can also provide the issue information 212 to the project database 202 to update the project database 202.
The recommender module 214 performs the generating task 106 of
Generally, the recommended module 214 is able to assign scores to respective candidate actions generated by the recommender module 214 for addressing a particular issue. The scores can be assigned based on analyzing data from past projects. Alternatively, the scores can be predefined estimated scores associated with particular types of actions.
In implementations in which the recommender module 214 analyzes data from selected past projects to generate candidate action(s), the recommender module 214 finds issue(s) in the selected past projects that are relevant to the particular issue of the active project. For each such issue in the selected past projects found by the recommender module 214, the recommender module 214 also retrieves information regarding actions that were taken to resolve such identified issue(s) in the selected past projects.
The actions relating to the identified issue(s) in the past projects can be scored based on one or some combination of the following: (1) respective impacts of the actions on the identified issue(s) in the selected past projects; (2) relative relevancy of the identified issue(s) in the selected past projects to the particular issue of the active project; and (3) relative relevancy of respective ones of the selected past projects to the active project.
Based on the scores for the actions taken with respect to the identified issue(s) in the past projects, the scores for the candidate actions generated for the active project can be calculated. For example, the candidate actions for the active project produce by recommender module 214 can be the actions taken to resolve the identified issue(s) in the selected past projects. In such example, the scores of the candidate actions are the scores assigned to the corresponding actions of the selected past projects.
In some implementations, a score can also be calculated for each action type based on aggregating the scores of selected ones of the actions of the given type taken in the selected past projects. An action type can be, for example, a type of action relating to increasing resources, a type of action relating to reducing scope, a type of action relating to decreasing costs, and so forth.
In the discussion above, the recommender module 214 analyzes information from selected past projects (e.g., similar past projects) to generate candidate action(s) 216. In other implementations, the recommender module 214 does not look at information associated with past projects. Instead, predefined (or default) candidate action(s) can be associated with each type of issue. Thus, based on issue information (212) associated with a particular issue (which is of a given type), the respective predefined (or default) candidate action is output by the recommender module 214.
Alternatively, candidate actions can include selection or deselection of sub-components of a project. If the project refers to a portfolio of projects, then the sub-components can be the projects within the portfolio. If the project refers to an individual project, the sub-components refer to different stages of the individual project. The effectiveness of an action (selection or deselection of a sub-component) can be determined by ascertaining the effect of adding or removing the sub-component on the particular issue. Once the sub-component is added or removed, the health scoring module 204 can be re-run to determine whether a status indication (206) would be generated. In this manner, the particular action (adding or removing of a sub-component) can be scored, and the corresponding score can be presented to a user to allow the user to make a decision on whether or not to perform the particular action (adding or removing a sub-component).
As further depicted in
The information that can be recorded for an issue can include some combination of the following: an identifier of the issue; a metric that the issue relates to (e.g., cost, resource, time, quality, geographical spread, etc.); the problem with the metric (e.g., too high, too low, out of range, >5% above target, etc.); actions taken to attempt to resolve the issue; outcome of the issue (whether the issue was successfully resolved or not, or a finer grade indication of the degree of success); and/or other details associated with the issue.
By updating the project database 202 with the output of the issue tracker 220, the updated information in the project database 202 can be used by the recommender module 214 to produce candidate action(s) for another issue of the active project indicated by the health scoring module 204.
The project similarity techniques of PCT/US10/30518 extract features of projects being compared, where the features can be extracted from project profiles. The features for the projects are provided to corresponding feature comparators, which output respective feature-similarity values. The outputs from feature comparators are weighted and aggregated by a feature-similarity aggregator(s) to produce a final project-similarity value, which is used to provide a measure of the relative similarity of the compared projects. Further details regarding such project similarity mechanisms are described in PCT/US10/30518. In other implementations, other techniques for finding similar projects can be used.
In task 302, the recommender module 214 can present the identified similar past projects to a user (such as through a user interface) for user feedback regarding whether or not the identified similar past projects are actually similar. Obtaining user feedback to confirm identified similar past projects can improve accuracy of the diagnosis performed by the recommender module 214. Each past similar project can be associated with a score (p). The score for each identified similar past project can be based on an aggregation of a project similarity score and other factors, such as a recency score (to favor projects that occurred more recently in time with respect to the active project).
Next, as depicted in
The recommender module 214 can also identify (at 306) action(s) taken to address the identified similar issue(s) in the identified past projects. The action impact for each identified action can be determined from the information associated with the similar past projects.
The identified action(s) can also be scored (at 308) by the recommender module 214. The score can be based on a combination of various factors. For example, the score can be a weighted and normalized combination of a project relevancy score (p), issue relevancy score (q), and action impact score (r), where the project relevancy score (p) indicates a degree of relevancy of an identified past project to the active project, the issue relevancy score (q) indicates a degree of relevancy of an identified issue (from a past project) to the particular issue of the active project, and the action impact score (r) indicates the impact (positive or negative) of the action with respect to the respective identified similar issue (from a past project).
The score relating to the impact of an action can be manually entered (for example, a project manager can be prompted to rate the action taken or the project manager can be responsible for entering the score a predefined period after the action was taken). Alternatively, the score of the impact of the action can be automatically determined (for example, if the issue has not been resolved, then the score is zero; otherwise, set the score to one). Alternatively, the score can be automatically based on determining a finer degree of impact by examining how the metric value changed after the action. For example, the rate of change of the metric can be considered at the time of the action, compared to the rate of change of the metric after the action.
As further depicted in
The process of
As noted above, the scenario explorer module 218 is able to present candidate actions in a user interface to allow for user selection and/or deselection of the respective ones of the candidate actions. The candidate actions can be presented in the user interface using any one or a combination of the following: the candidate actions can be listed in order of respective scores of the actions; the candidate actions can be grouped in categories corresponding to action types, where the categories are ordered according to the action type scores; the candidate actions relevant to different metrics are provided in respective different groups; candidate actions or action types are having scores below a particular threshold are filtered out; and others.
The scenario explorer module 218 is able to present further information regarding a candidate action, such as more detailed scores or information on how the candidate action may contribute to the metric. The scenario explorer module 218 can represent scores by numbers, colors, graphics, and so forth.
In addition to being able to select or deselect candidate actions, the user interface presented by the scenario explorer module 218 also allows a user to edit a given candidate action. The scenario explorer module 218 can also provide a view of results of actions from information relating to the identified similar past projects, for example.
The graph of
Each action taken may affect more than one issue (e.g., increasing resources may affect issues concerning time and cost metrics). An action ad can be associated with the following information: identifier of the action; a type of action (e.g., increase resources, change suppliers, change scope, etc.) (note that there can be a null action type, which is used to represent that no action was taken to address an issue); timing to indicate when the action took place relative to the start of the issue, or more detailed information such as start and end time points; an indication of an impact of the action on the metric associated with the issue; and/or other details regarding the action.
The recommended action generator 502 can be implemented as machine-readable instructions executable on a processor (or multiple processors) 504. The processor(s) 504 is (are) connected to a storage media 508, which stores the project database 202. The system 500 also includes a network interface 506 to allow the system 500 to communicate over a network 510 with client device(s) 512, such as to report recommended actions according to some implementations.
The processor 504 can include a microprocessor, microcontroller, processor module or subsystem, programmable integrated circuit, programmable gate array, or another control or computing device.
Data and instructions are stored in respective storage devices, which are implemented as one or more computer-readable or machine-readable storage media. The storage media include different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic media including tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices. Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to any manufactured single component or multiple components. The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.
In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some or all of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.
