PROJECT CATEGORIZATION AND ASSESSMENT THROUGH MULTIVARIATE ANALYSIS

A system for project categorization and assessment that can employ multivariate analysis techniques to classify a current project by using attributes of the current project to identify project objects representing completed projects similar to the current project. Project data sets of points in a project lifetime can be represented as pictures, having attribute pixels. Pattern recognition techniques can be used on the project pictures. The system can generate eigenprojects for large project object groups or for classification across multiple groups. Aspects of a classified current project can be assessed to suggest project management actions.

DETAILED DESCRIPTION

As used herein, and unless the context dictates otherwise, the term “coupled to” is intended to include both direct coupling (in which two elements that are coupled to each other contact each other) and indirect coupling (in which at least one additional element is located between the two elements). Therefore, the terms “coupled to” and “coupled with” are used synonymously. Within the context of this document the terms “coupled to” and “coupled with” are also used to mean “communicatively coupled with” where two or more devices are able to communicate over a network.

InFIG. 1project analysis system100can include a project interface102through which project attributes110of a project to be analyzed can be received by the system100. The project interface102can be an interface such as a browser, an application, a computer terminal, an http server, etc., through which a project manager or other stakeholder in the project can submit the project attributes110. The project interface102can include communication interfaces with external data sources (e.g., websites, databases, servers, sensors, equipment, machinery, etc.) from which the system100can gather data associated with or corresponding to project attributes110. An example of a type of project for which the system100can be used includes large scale construction projects. Other examples of projects can include financial projects, engineering projects, design projects, construction and construction management projects, software development projects, supply chain projects, maintenance projects, and movie projects. Projects can also be sub-projects of larger, broader projects. For example, one or more of a maintenance project, an electrical project, a structural project, a landscaping project, a zoning project, and a materials project can be a subproject of an overarching construction project. Still further, the projects could represent phases within a project. The network illustrated inFIG. 1can be a data exchange network such as one of the networks listed above.

Projects can be complex affairs having a wide range of project attributes. The project attributes110can be considered to be factors, characteristics, variables, features or parameters associated with a current project. The project attributes110can affect, and be reflective of, the state of the project and the progress or execution of the project. One or more project attributes110can include attribute values, which can be indicative of a magnitude, amount, percentage, probability, state, condition, stage, etc., of a corresponding project attribute110.

Examples of project attributes can include a project purpose, a project type, a project goal, a project size, a project execution approach, a project progress, a project challenge, a project location, a project contract, a project contract detail, a project contract obligation, a project risk assessment, a project work load, a perception of an objective (e.g., global perception, current perception, etc.), a resource metric, a stakeholder attribute, a stakeholder number, a degree of support, a prior history, a project driver, a relationship (e.g., a relationship between project team members, a relationship between a project manager and team members, a relationship with a client, a relationship of the project with other projects, a relationship between attributes, etc.), a budget, a sensor reading, a diagnostic attribute, an operational attribute, a cost, an environmental factor, a complexity attribute, a project sentiment attribute, and a project manager attribute.

Project attributes110can include one or more of: “global” attributes common to all projects, attributes common to similar projects (e.g., projects of a similar type, of a similar class, projects having similar goals or objectives, similar project aspects, etc.), and attributes specific to a particular project, project type or class (e.g., specific to a particular project type or project class, specific to a particular individual project, specific to a particular aspect of a project, etc.). For example, the global attributes can include project size, budget, location, costs, progress, and other attributes that can be reflective of general, high-level, or otherwise universal project characteristics applicable to all projects. At the other end of the spectrum, a large-scale construction project can include project attributes such as construction code attributes, materials attributes, zoning attributes or other attributes that are specific to construction projects, and would likely not be applicable to projects such as a software development project or a movie project.

Project attributes110can be grouped or categorized according to shared commonalities among several attributes, such as attributes common to or contributing to a particular project factor. For example, a group of attributes related specifically to stakeholder aspects of a project can be grouped as stakeholder attributes. These can include a stakeholder identifier, a number, a degree of support, a stakeholder prior history, etc. In some cases, grouped attributes can have established relationships. For example, these relationships can dictate that the inclusion of one of the grouped attributes requires the inclusion of some or all of the remaining grouped attributes, or that a change to a value of a grouped attribute results in a change to one or more of the other grouped attributes according to the rules or parameters of the relationship.

System100can further include a project database103storing multiple project objects111, where each project object111can represent one or more of a known, previously executed, benchmarked, optimized, reference, or historical project. A project object111can represent the entirety of a project, or an aspect or portion of a project (e.g., a division, a task within a project, a sub-project, a project stage, a project state, a project detail, etc.). The project objects111can be considered distinct manageable units of project knowledge having object attributes, preferably in the same namespace as the as the current project's attributes. In embodiments, project objects111can represent complete projects, project phases, simulated or statistical projects, a project's snap shot in time, project states, project stakeholders, project actions, project trends, project objectives, types of projects, or classes of projects. Project objects111can be grouped or categorized. In an embodiment, project objects111can be grouped or categorized according to a reference project class.

In an embodiment, project objects111can include a project object type referred to as an “eigenproject”, which is discussed in further detail below.

Project objects111can represent projects of various levels of success. As such, multiple project objects111can exist for a particular project, where one or more of the project objects111can represent various successful completions of the project (e.g., optimal completion, ideal completion, minimum acceptable completion, etc.), and where one or more of the project objects111can represent unsuccessful completions of a project (e.g., projects that did not reach their goals, projects abandoned or otherwise aborted, etc.). For each of these project outcomes, the project objects can have corresponding object attributes of the project at a particular point in time or other time slices. As these attributes contributed to the project outcome, it enables for assessment of a project and prediction of a degree of success or failure of projects under analysis, and enables a projection of trend data to a measured or pre-determined outcome.

The system100further includes a project recognition engine101configured to analyze received project attributes with respect to the project object attributes for a project currently under analysis in an attempt to identify project objects that could be considered similar to the current project's state. As such, the project attributes110can be considered to represent a snap shot in time or a time slice of the current project. The project recognition engine101can further be configured to assess the current project against identified project objects, such as to identify significant attributes of the current project or deviations of the project from the project objects. The project recognition engine101can be configured to generate, based on the assessments, a recommendation112for presentation to a project manager or other requesting party. In an embodiment, the project recognition engine101can be configured to automatically implement some or all of a generated recommendation112by causing other computing devices associated with a project to perform adjustments of project parameters associated with project attributes (e.g., calibration of equipment, adjusting operational conditions or parameters, adjust a maintenance schedule, sound an alarm, etc.).

The project recognition engine101can comprise computer-readable instructions stored on a non-transitory computer-readable medium that, when executed by a computer processor, carry out functions corresponding to methods and processes of the inventive subject matter. In embodiments, the project recognition engine101can comprise a dedicated computing device, having dedicated hardware and/or software that, when executed by the computing device, carry out functions corresponding to methods and processes of the inventive subject matter. In embodiments the project recognition engine101can comprise a dedicated hardware processor, specifically configured to execute functions corresponding to methods and processes of the inventive subject matter.

The project recognition engine101can be communicatively coupled to the project interface102, enabling the project recognition engine101to receive information (e.g., project attributes110, other information related to functions and processes of project management) from the project interface102and return information (e.g., presentation of identified project objects, recommendations, etc.) to the project interface102for display, presentation, and/or implementation.

In an embodiment, the project database103can be integral to the project recognition engine101. In an embodiment, the project database103can be communicatively coupled to the project recognition engine101, whereby the project recognition engine can exchange information with the project database103for the purposes of carrying out functions and processes associated with the inventive subject matter. The project database103can comprise a non-transitory computer-readable storage medium (e.g., hard drive, server computer, flash drive, optical storage, ROM, etc.) on which project data can be stored.

To present information such as identified project objects, assessments, and/or recommendations, the project interface102can include or be communicatively coupled to an output device. Examples of an output device can include a display, audio output devices, a printer, sensory feedback devices, etc.

The system100can be employed to assist project managers in understanding, categorizing, assessing and monitoring a project based on consideration of a large number of project attributes110.

These project attributes110can be used to create a pattern definition that can be considered a “picture” of the project. This picture can then be compared with other similar pictures, such as those of existing project objects. The comparison and classification can be performed using pattern recognition techniques utilizing multivariate analysis. Pictures can be similarly grouped and categorized where each category has certain common descriptive features, and can also incorporate anticipated or known project attributes common to particular groups or categories. The project picture for a current project can be retaken over time (e.g., over the project lifetime, potentially including its operating phase) and its strength of correlation with its initially assigned group measured over time, such as to confirm whether the initial assignment was correct.

This pattern recognition approach utilizing multivariate analysis can be used by the system100to perform granular categorization of discrete aspects of the project. As an example, a series of pictures of stakeholder relationships taken over time not only allows for early categorization (thus facilitating strategy identification), but also enables for the identification of subtle shifts and trends that might be leading indicators of problems or success. In this respect, statistically meaningful portions of the picture can be compared for characterization or analysis at a desired level of granularity. As a metaphor, this would be similar to, in facial recognition, looking at the eyes of all Caucasian men to further categorize by shape or color.

To create the project objects111used to categorize and analyze active projects, data sets initially composed of project pictures from different points in time from completed or historical projects can be initially constructed and provide a basis for initial “group” or “classification” definition. These definitions can be strengthened as additional pictures from newly completed projects are subsequently added. In effect, the initial data set can act as a training set for the developed tool. Thus, these pictures become project objects111according to group definitions.

“Pictures” from the same project over time can be stacked to create a multivariate image where time is the third dimension, and each individual image is comprised of rows and columns of “pixels” where columns correspond to similar types or dimensions of project attributes (e.g., client, complexity, environmental factors, stakeholder attributes, etc.) within a normalized attribute namespace. These multivariate images can be used to confirm group classification while individual pictures provide some initial sense of directionality (i.e., classification is getting stronger or weaker). Within a given group, anticipated changes in the multivariate picture over time can be modeled (e.g., after observed behaviors in completed/benchmark/reference projects) and can be employed by the project recognition engine101to assess project evolution. Select defined portions of the picture (which can be thought of as features of a project picture, such as the eyes, mouth, ears, nose, etc., recognized and categorized in an image of a face in facial recognition) can be separately characterized to support a increasingly granular analysis, while trading off some of the insights and assessments that can be made from non-obvious or seemingly unrelated correlations.

“Pixels” are considered to be the variables in the analysis and for a given project these variables are expected to be highly correlated. In project pictures, the pixels can be considered to be the attributes associated with a project. These attributes can correspond to the variables routinely tracked as part of a project management system and reported on project status reports. For example, pictures comprised of all attributes (pixels) from a complete project status report at each period through the project lifetime could be used to create the initial project image database and categorization.

The project recognition engine101can be configured to “unpack” each image column wise such that sequence of parameters would be the same for each project picture so unpacked. This can enable subsequent analysis of select portions of the data set such as stakeholder data, productivity related data, and external factors assessments.

Each picture's data can be considered as a row of unpacked data in a data matrix. The database of unpacked data is cumulative such that as a new picture is added to the database, effectively one additional row is added. The data matrix can be considered to be equal to the number of pixels times the number of pictures.

As current projects are completed, the pictures from the completed projects can be added to the data used in group definitions, and can be added to the project database103as project objects themselves. This allows for the project database103to constantly evolve to incorporate changes in project execution over time.

FIG. 2illustrates an example execution of the classification and assessment of a project, as executed by the project recognition engine101.

The process illustrated inFIG. 2begins with a classification step201, where each given project picture is classified into defined groups of projects. This classification can be independently undertaken utilizing two different but related multivariate statistical techniques. In embodiments, the classification techniques can be employed in parallel, where both techniques are run in parallel. The classification results can then be compared according to priority rules for the techniques, can be normalized for convergence, or can otherwise be used for error detection and correction. In embodiments, the classification can employ either technique.

In embodiments, the classification techniques can be employed in series, where one of the two techniques is first employed and the other of the two techniques can be used as necessary to verify the classification (e.g., if the classification using the first technique in series fails to properly classify the pictures, if the classification using the first technique fails to meet a confidence threshold, etc.).

FIG. 3provides a detailed illustrative view of an example classification step201, employing the use of both multivariate statistical techniques in parallel.

The first multivariate statistical technique that can be utilized in classification is linear discriminant analysis (“LDA”), illustrated in step301a. LDA is a statistical technique that can be employed in pattern recognition such as facial or voice recognition. LDA can be used to classify patterns based on a calculated Mahalanobis distance. In statistics, the Mahalanobis distance is a distance measure introduced by P. C. Mahalanobis in 1936. It is based on correlations between variables by which different patterns can be identified and analyzed. It gauges similarity of an unknown sample set to a known one. It differs from Euclidean distance in that it takes into account the correlations of the data set and is scale-invariant. In other words, it is a multivariate effect size.

An effect size calculated from data is a descriptive statistic can convey the estimated magnitude of a relationship without making any statement about whether the apparent relationship in the data reflects a true relationship in the population.

Each project picture being analyzed can be classified into the group whose mean is closest to it in the Mahalanobis sense.

LDA relies on key assumptions with respect to normal distribution of multivariate conditional probabilities and equivalence of group covariance matrices. These assumptions allow simplification of the analysis and can be useful in all but truly first of a kind projects where correlation with any defined group is weak at best. At step302, the covariance matrix can be generated. In conducting LDA, a common group covariance matrix can be used, such as for a sufficiently robust common group. In embodiments, a pooled covariance matrix of all the groups in the project database can be used to strengthen the overall analysis using this type of pattern recognition.

For large groups, or for analysis using all groups in a database, the covariance matrix can be exceptionally large, and thus not be feasible to estimate. Techniques such as using principal component analysis (“PCA”) to reduce dimensionality by extracting so called principal components is equally infeasible for such a large covariance matrix.

The data matrix, however, can be recognized as being equal to the number of pixels times the number of pictures and the associated covariance matrix can be considered to consist of a number of non-zero eigenvectors equal to the number of project pictures in the data set. As such, a set of eigenvectors can be derived from the covariance matrix associated with the data matrix at step303.

From this set of calculated eigenvectors, PCA can then be employed to construct one or more “eigenprojects” at step304. In facial and speech recognition technologies, eigenvectors are used to calculate eigenfaces and eigenvoices, respectively.

Any given project picture can be reconstructed at step305by projecting it onto the eigenprojects with reconstruction complete when it has been projected using all the eigenprojects.

In an embodiment, project pictures can be projected onto a desired number of eigenprojects that is sufficiently large for analysis while remaining computationally cost-effective. For example, project pictures can be projected only onto approximately the first 20 eigenprojects and the new variables (principal component scores) used in LDA, such that the data matrix is equal to number of project pictures ×20 eigenprojects. Sensitivity tests of the training data sets can confirm the appropriateness of limiting projection to 20 eigenprojects by calculating the apparent error rate (“APER”), which can be considered an optimistic assessment of the actual error rate.

The second technique that can be utilized in classification is the Fisher discriminant method at step301b. The Fisher discriminant method is similar in objective to PCA in the sense that it seeks to reduce dimensionality. However, the Fisher method does not make some of the assumptions of LDA, such as normally distributed classes or equal class covariances. Utilization of two dimensional Fisher discriminant space plots can be a useful tool to visualize the proximity of various groups in the classification system.

At step306, the execution of the classification technique(s) used for classification results in a determined classification of the current project whose received project pictures were analyzed.

As pictures of a project are taken over time, the project represented by the project pictures can change or evolve. As these pictures are received, the classification process can be performed with each picture, or periodically over the life of a project. Over time it is possible for a project picture to indicate or suggest that the project should be otherwise categorized. This can result from one of two circumstances:

The first would be a significant enough change to the project picture over time such that it no longer ideally fits in the originally assigned group. Such reclassification can be the result of a determination that the project has different common descriptive features and attributes from the originally assigned group, and suggests changed areas of management focus and attention and new project areas of interest.

The second instance which can trigger project reclassification can be changes in the composite library of all project pictures such that groupings or the definitions of their characteristics changed as sample size grew.

If a project can be reclassified, a project manager or other user can be notified via the project interface102prior to the project assessment step202, to allow for a decision on reclassification prior to subsequent assessment and analysis. Alternatively, the reclassification of a project can be presented to a project manager or other user as part of a recommendation, as described further below.

After classification, assessment step202is performed to identify areas of the current project that the project manager should focus on given the similarity of this project to some respective group of projects for which insight has been previously determined. In this example, insight can be considered to be observations and/or knowledge gained from the execution of the past project used in generating the project group of a specific type. Examples of insights can include causes, effects, conclusions, trends, project areas or parameters relevant to or associated with other insights, insight significance related to the project as a whole, etc. Insights for the initial eigenproject database (project object database) can come from one or more of a review of contemporaneously prepared project reports, lessons learned from previously executed projects of the type, reports prepared for previously executed projects, interviews with people having involvement with the project (e.g., project manager, executives, employees participating in the projects), market data for similar projects, etc.

The assessment202of initial database projects and other subsequent projects captured in the ever growing project picture database also enables an identification of areas of likely challenge, opportunity areas to explore, and can highlight important project factors affecting a project based on pattern relevant experience that would not otherwise readily evident. The assessment can be performed for a single project picture (e.g., the most current project picture of a current project), or can be performed for a plurality of project pictures (e.g., past project pictures, and can include the most current project picture). This can enable the assessment of areas of interest as described above for a current project's current state, as well as enabling an identification of trends that in turn allow for predictive analysis of a current project in a current state. Utilizing a pattern recognition type approach based on multivariate statistical techniques provides the project manager with an additional tool to manage the project.

At step203, the project recognition engine101can identify subtle but pervasive changes to the project picture from potentially correlated common drivers. Examples of common drivers can include constraint-coupled factors and/or risks that are not readily apparent or easily observable, and systemic factors and/or risks having complex inter-relationships. These pervasive changes can be thought of as a “darkening” or “lightening” of the project picture, where the pervasive changes can collectively affect some or all of the pixels of a project picture. Early recognition of potential common drivers acting on the project provides an ability to seek out, understand and manage these drivers to the advantage of the project. In this case the comparative analysis can be between project pictures taken at different times. Both an absolute comparison (e.g., between the different project pictures of the current project taken at different times themselves) and comparison of respective eigenproject values from the database can be performed.

As described above, the analysis performed in steps202and203can be based on multiple project pictures taken over time. The project recognition engine101can use the aggregated project pictures over time to generate eigenproject “movies” for the current project. Likewise, eigenproject movies can be generated for a correlated group of project objects. The eigenproject “movies” of a current project can then be compared with a similar eigenproject movie for the correlated group, allowing a deeper understanding of how group values change with aging over a project's lifetime, and how those group values can ultimately affect the outcome of a completed project. This allows for the identification of trends for particular aspects of a project as well as for the project as a whole, and the interrelationship of different factors that affect a project's aging. Trends and aging tendencies can be used to predict outcomes of a current project based on current trends associated with current project characteristics as well as predict effects of potential changes to one or more aspects of the current project.

In an illustrative example, the capability to understand project aging patterns and predict their effects can have particular relevance in the operating and maintenance phase of the project. For example, understanding aging patterns as they pertain to operating phases allow for the understanding of a current operating state of a plant or installation, how decisions related to operations can affect the progress and development of a project and/or the operating state of the plant/installation. In a maintenance phase, maintenance needs can be identified and predicted so that maintenance plans can be implemented prior to reaching a critical status, or ultimately, project failure.

At step204, the project recognition engine101can identify subtle but pervasive changes in sub-elements of a project. To do so, project values for a current project associated with a particular sub-element can be identified. In an embodiment, these project values can be additional project values retrieved by the project recognition engine101, which are identified based on their relationships one or more of the received current project pixels. As such, project pictures for sub-elements can be created and analyzed. In an embodiment, one or more eigenprojects can be generated for the combination of sub-elements. In an embodiment, separate eigenproject pictures can be created according to each individual sub-element. This enables for the determination of meaningful conclusions about the sub-elements and their relationship to the project can be drawn. In particular, there might be relevance in evaluating complex stakeholder situations or assumption migration in complex, long duration projects. In an illustrative example, sub-elements of a project can include stakeholder management, assumption and productivity. In this example, the separate pictures corresponding to the sub-elements of stakeholder management, assumption and productivity can be considered a “triple bottom line” for a project. Depending on the nature of the current project, one or more sub-elements may or may not exist in the project or be relevant to the project. In other situations, a particular sub-element may be relevant to the project, but not relevant to a particular project at that particular point in time. As such, step204can be optional for certain project types or certain project states.

At step205, the system100(such as via the project recognition engine101) can generate one or more recommendations112based on the analysis of the identified project object(s) Ill corresponding to the current project attributes110. In an embodiment, the recommendation functions can be performed by a recommendation engine that is a part of or is in communication with the recognition engine101.

In an embodiment, a recommendation112can include a recommendation to alter one or more aspects of a current project so that the project attributes reflecting those aspects are changed in a desired manner, thereby guiding the project towards a desired state (i.e., get the project “back on track”). The recommendation112can be to alter project aspects or parameters such that the project attributes110change to converge with the attributes of applicable project objects111, and so the project as a whole is driven to align with the project object. The recommendation112can also (or alternatively) suggest a modification to aspects of the current project such that the project attributes diverge from corresponding object attributes of project objects111and, consequently, that the project diverges from the identified project objects111(e.g., if the identified project objects correspond to project objects of failed projects or reflect a project having an undesired cost, outcome or other undesired factors).

In an embodiment, the recommendation112can include a recommendation to change the objective, goal or purpose of the current project based on the current state of the project relative to identified project objects. For example, suppose that the classification analysis of a current project picture based on the attributes of a current, active project identifies a project object or project object group corresponding to the predefined or stated original goal or purpose of the current project, whereby the identified project object reflects a desired or optimal state of the current project (e.g., where the current project “should be” at the state reflected by the received attributes). However, in this example, suppose that the assessment of the attributes of the current project with those of the project object show a great disparity between the state of the current project and that of the project object. As such, the corrections required to get the current project “back on track” to an acceptable level can be likely to incur a substantial cost (e.g., financial, resources, effort, manpower, logistical, etc.). In this case, other project objects111(and/or project groups) may be found to be a better fit for the current project in its current state. In this case, the project recognition engine101can identify one or more project objects111(and/or project groups) that are better suited to the current project in its current state than the previously identified project object111corresponding to a previously categorized, predefined or pre-stated purpose of the project. This can be considered a reclassification of the current project. In an embodiment, the reclassification step can be performed, and can be a re-execution of the classification functions described above. The reclassification for a current project picture can be performed if the deviation from the originally identified project object and/or project group exceeds a particular threshold. In an embodiment, the reclassification can be performed periodically during the lifetime of a current project, as over time a project may gradually deviate and evolve into a project better suited to a different classification. When a more suitable project object is identified (e.g. via reclassification), the recommendation112can include a recommendation to shift the goal or purpose of the current project to that of the newly identified, more suitable project object. The recommendation112can include modifications or changes to one or more of the attributes of the current project to better align with the object attributes of the newly-identified project object. Therefore, while modifications may still be required, the cost of applying any changes to align the current project to achieve necessary project objectives is reduced and waste of efforts and progress of the current project to that point is minimized.

In an embodiment, it is contemplated that functions and methods of the inventive subject matter can be implemented across a program or a larger project portfolio, which can have large amounts of unrelated project and/or large amounts of unrelated or uncorrelated variables. In these embodiments, training database would be required to be programmatic or portfolio-oriented in nature.

In an embodiment, it is contemplated that external factors can be incorporated into the database, to facilitate assessments of resiliency. For example, external factors can be incorporated as external attributes, whereby the external attributes are associated with conditions that are not directly related to or typically associated with a particular project or project type, but that can have a ‘one-time’ impact on the current project.