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.
Traditionally, issues that may adversely affect projects may not be identified early enough to allow for effective actions to be taken to resolve such issues. Examples of issues that may adversely affect projects include cost issues that may cause a project to be over budget, late delivery issues, and/or poor performance issues, and so forth. Such issues can result in monetary and reputation losses to the enterprise, for example. More generally, an “issue” refers to a problem, an event, an occurrence, a state, or some other circumstance that can affect performance of a project.
In some examples, potential late delivery (of a product or service) is often undetected by or hidden from appropriate personnel, and projects can move from a healthy state to a critical state relatively rapidly and without much notice. As a result, appropriate actions may not be taken to resolve issues until a project has reached a critical state, by which time timely resolution of the issues may not be possible. Without advanced warning of issues, management may not be able to take proactive steps for mitigating or preventing issues that can cause projects to achieve target goals.
In accordance with some embodiments, early status indications can be generated regarding a project to allow for users (e.g., managers, developers, etc.) to take actions early enough to allow for effective resolution of corresponding issues.
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, 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 part of a set of rules. 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) being a certain value or within a certain range (e.g., between two thresholds, below a threshold, or above a threshold).
An example syntax of a condition is provided below:
Condition=Expression{LogicalOperator Expression}
where:
Metric is a label, e.g. a type of measurement for projects/portfolios
ConditionalOperator can be >, <, =, >=, <=, <>, or another operator
Value is a value of the metric, or a richer expression e.g. a set or range of values
In other examples, other syntax for specifying the condition of a rule can be used.
Once a condition of a rule is satisfied, then an action specified by the rule can be taken. Note that the action that can be specified by the rule can be an action to generate a status indication. Alternatively, or in addition, the action can be some other action to be taken in response to the condition being satisfied. The action (or actions) to take in response to satisfying a condition can be specified by a user, such as a project manager.
As further depicted in
Based on the condition being satisfied, the process of
The probability estimator 210 calculates a probability value for a probability of an issue specified in the conditional expression. The probability value calculated by the probability estimator 210 uses information from past (similar) projects to calculate the probability value. The probability value is calculated by mining data from other projects (historical or active projects) within the project database 202. The probability value can also be calculated based on data from the active project itself. The probability estimator 210 returns (at 214) the calculated probability value to the rules engine 208.
Based on the probability returned by the probability estimator 210, the rules engine 208 determines whether a corresponding action associated with the rule is to be executed. The action can include providing a status indication 216 (e.g., report, e-mail, etc.) based on the returned probability from the probability estimator 210.
Although the foregoing refers to just one conditional expression being sent (at 212) from the rules engine 208 to the probability estimator 210, and one probability value returned (at 214) from the probability estimator 210 to the rules engine 208, it is noted that there can be multiple conditional expressions and probability values exchanged between the rules engine 208 and probability estimator 210. Also, although the rules engine 208 and probability estimator 210 are depicted as separate modules, in other implementations, the rules engine 208 and the probability estimator 210 can be integrated into one module.
If multiple rules (in the rule set 206) for the active project have to be processed, the rules engine 208 evaluates each rule in turn, starting from a first rule and continuing on until each applicable rule has been evaluated. If a rule is triggered (a condition has been satisfied), then the corresponding action is taken.
The following provides an example to illustrate some implementations. For a given example project, a tolerance for a particular project stage (a stage from among multiple different stages of the project) is such that the duration of the particular stage should not overrun a target time period by more than 20% and the project should remain adequately resourced throughout (supplied with adequate personnel and/or equipment). An example conditional expression that can be specified in a corresponding rule can be as follows. If the probability of a 20% time overrun is greater than a predefined percentage, or the probability of resources being insufficient is greater than a predefined percentage in a given time window of the project, then generate an early warning alarm. Note that the condition is based on a probability of project metric exceeding a tolerance (e.g. in the near future), and not actually exceeding such tolerance, so that the alert generated is an early warning.
Another example rule is set forth below:
The rule above specifies three conditional expressions: (1) the probability of overspend <=2%, AND/OR <other conditions>; (2) the probability of overspend >2% AND <5%, AND/OR <other conditions>; and (3) the probability of overspend >=5%, AND/OR <other conditions>.
Alternatively, instead of being referred to as three conditional expressions, the collection of the relationships of “probability of overspend” to corresponding thresholds (<=2%, >2% AND <5%, >=5%) can be considered as one conditional expression (or condition). Thus, as used here, a “conditional expression” or “condition” refers to expressed relationship(s) between a probability of an issue with respect to one or multiple thresholds (or other criteria).
The rules engine 208, in addition to processing rule(s) associated with a particular project, can also update the project database 202. The rules engine 208 can update the project database 202 with information regarding issues that have occurred in the active project. Such updated information regarding issues that have occurred in the active project can be used in determining probabilities of issues occurring in subsequently processed projects.
The total time of a project can be split into a number of time periods {t1, t2, . . . tf} each of a particular duration (e.g., hour, day, week, month, etc.), which is configurable by a user, where time period t1 is the first time period of the project and time period tf is the last time period of the project. Note that f can be different for different projects, as project durations may vary.
For every past or active project p (where p can be an individual project or a portfolio of projects) in the database 202, and for each metric mx (x=1 to g, where g represents the number of metrics for each project), a vector Mxp, is created where the vector Mxp, contains values for mx for each of the f time periods when project p was in operation. The vector Mxp can be represented as follows in some examples:
M
xp=(mx,p,t=1, mx,p,t=2 . . . , mx,p,t=f). (Eq. 1)
For an active project pa that is currently in a given time period, tc (where c ranges from 1 to f), time periods going forwards {tc, tc+1, tc+2, . . . , tc+j} are considered, where such time periods are from the current time period tc to a future time period tc+j, where c+j is the last time period. In some examples, each time period tz (z=c, . . . , c+j) is associated with a corresponding time period weight, wz, where the weight wz is larger for closer time periods (closed to tc) to favor metric values in the near future over those in the more distant future, and where the time period weight wz is smaller for farther time periods (farther away from tc). In other words, the time period weights wz vary according to time proximity of a future time interval to a current time interval of the particular project under evaluation
These weights wz are represented by a vector W:
W=(w0, w1, . . . , wJ),
where:
As further depicted in
Each similar project, ps, is associated with a project similarity weight, vs, which is larger for projects with a higher degree of similarity to the current project (in other words, the weight vs has a higher value for a more similar project and a lower value for a less similar project). This weight is derived from information provided by the similarity module 302.
The probability estimator 210 further includes a similar project data processing module 304 to process similar project data from the identified similar projects. For each similar project, ps, the similar project data processing module 304 ensures that the project ps is genuinely similar based on user feedback. For example, a project ps can be identified to a user, such as through a user interface, to prompt the user to indicate whether or not the project ps is in fact similar. Confirming that a project ps is similar can improve the accuracy of the system.
The probability estimator 210 determines a time period ti that represents a similar stage in similar project ps as the current time period tc of the active project pa. In some examples, if projects pa and ps have different durations, one way to identify ti is by setting i as follows:
where fa: number of planned time periods in the active project pa, and fs: number of time periods in the similar project ps.
Consider a rule set for project pa. For each conditional expression, e, in the rule set, the probability estimator 210 finds the metric, mx, upon which the expression e is based, and the corresponding vector of values Mxs, for similar project ps (see Eq. 1). For each time period tk, the corresponding metric value mx,s,t=k is evaluated according to the conditional expression e and the result (condition satisfied or not satisfied) is assigned to ue,s,z. In some examples, the results are compiled in the vector Ues:
U
es=(ue,s,z=0, ue,s,z=1, . . . , ue,s,z=J) (Eq. 3)
where:
Given the data on all similar projects to project pa, the probability calculator 306 in the probability estimator 210 evaluates the probability of a given conditional expression e from the rule set, such as according to the following:
In other implementations, probability values can be calculated using other formulas. Generally, the probability value for a conditional expression e can be based on a weighted sum of true/false results (ue,s,z) (weighted according to time period weights wz and project similar weights vs). This weighted sum can be normalized to the product of the sums of wz and vs, as in Eq. 4 above. In other examples, instead of weighted sums, other types of weighted aggregates can be used.
By producing a status indication (216 in
The early warning generator 402 can be implemented as machine-readable instructions executable on a processor (or multiple processors) 404. The processor(s) 404 is (are) connected to a storage media 408, which stores the project database 202. The system 400 also includes a network interface 406 to allow the system 400 to communicate over a network 410 with client device(s) 412, such as to report early warnings produced according to some implementations.
In alternative implementations as depicted in
The processor 404 or 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.