SG192659A1

SG192659A1 - Method and risk management framework for managing risk in an organization

Info

Publication number: SG192659A1
Application number: SG2013060025A
Authority: SG
Inventors: Ramasubramanian Vasudevan Valliur; Haragopal Mangipudi; Balamukund Sripathi; Anu Cherian
Original assignee: Infosys Ltd
Priority date: 2011-02-07
Filing date: 2011-12-26
Publication date: 2013-09-30
Also published as: AP2013007050A0; WO2012107933A1

Abstract

The present invention provides a method, system, and computer program product for managing the overall risk associated with any aspect in an organization. The method enables defining the focus areas associated with each context, and the change management dashboard attributes for each focus area of the context, risk profiling of at least one entity of one or more entities associated with each context, registering each profiled risk associated with the at least one entity, administering each registered risk associated with the at least one entity, and determining a risk score associated with the at least one entity. Further, an integrated visual management dashboard is generated for focusing management's attention on the right set of entities and patterns on a continuous basis, for managing the overall risks and actions associated with each context of the organization. The one or more entities include software applications, programs, strategic initiatives, operational interests, financial interests, legal interests or business interests. Further, managing also includes continuous learning from the experience of the periodic implementation of the framework in every period, and applying the learning for a better framework and risk management for the organization.

Description

METHOD AND RISK MANAGEMENT FRAMEWORK FOR MANAGING RISK IN AN

ORGANIZATION

FIELD OF INVENTION

The present invention relates, generally, to risk management in an organization and, more specifically, to a method and a system for determining and managing overall risk associated with any aspect in an organization.

BACKGROUND

Risks are omnipresent in almost all aspects of businesses, including the

Information Technology (IT) or software development companies. There are multiple dimensions in risk management that need to come together for a business leader, so that he/she can make effective business decisions. Some of these dimensions are mentioned below.

In a business unit, risk management involves tapping into the intelligence of its stakeholders’ ecosystem to understand risks and also understand their ability to mitigate it. While past adverse events provide indications of how not to repeat them in the future, they cannot predict new risks that could happen in the future. Typically, the risks associated with a lifecycle’s each subsequent stage are higher than that of the previous stage. As a result, the ability to recover from risks associated with the later stages, which are the near completion stages, are much lower than the initial stages. Early identification and appropriate action on risks significantly improve the chances of success and reduce the cost of mitigation.

Risk management needs to focus not only on the identification of risks but also on the action’s discipline and effectiveness to manage risks.

A business leader may have different risk priority for different types of entities in his/her organization. Each of these types of entities would have a different business - visibility lens. A low-value proposal with high execution challenges and a high-value project with high execution challenges are both important for business leadership visibility and decision making.

The frequency at which a business leader needs risk information has to be flexible as it could vary from one type of entity to another and from one entity to another.

The business leader would need both top-down (for example, large program) and bottom-up view of risks (for example, of all its projects). :

A business leader would need both vertical (function or department) anda horizontal focus on risks. A strategic initiative cutting across multiple business functions necessitates a horizontal focus.

The parameters and questions on which a risk is assessed need to be contextual and frequently updated based on learning and experience. This brings in the dimension. of continuous learning from experience of framework implementation, including audits, to ensure that risk management is contextual and relevant.

The existing risk management processes fall short in one or more of the above dimensions, which include integrating all these different dimensions on a periodic basis for timely business visibility and effective decision making by the business leadership.

In light of the above discussion, there is a need for a method, system, and computer program product for managing the overall risk associated with any aspect in an organization For instance, organization such as an IT company can model the above dimensions and integrate them into a visual management dashboard for the business leadership towards effective business decision making.

SUMMARY

The present invention provides a method, system, and computer program product for managing the overall risk associated with any aspect in an organization. The method enables defining the focus areas associated with each context, the change management dashboard attributes for each focus area of the context, risk profiling of at least one entity of one or more entities associated with each context, registering each profiled risk associated with at least one entity, administering each registered risk associated with at least one entity, and determining a risk score associated with at least one entity. Further, an integrated visual management dashboard is generated to focus management's attention on the right set of entities and patterns on a continuous basis, for managing the overall risks and actions associated with each context of the organization. The risk levels and hence business leadership visibility is also sensitive to action discipline on addressing the risks, including human intelligence of risk levels in the future and current lifecycle stage. The dashboard brings to visibility of the business leadership, both top- down (higher level entities such as programs) and bottom-up views (lower-level entities " such as projects in a program). The dashboard also enables bringing multiple entities (proposals, development projects, maintenance projects, strategic initiatives) into one dashboard for business leadership decision making. The one or more entities include software applications, programs, strategic initiatives, operational interests, financial interests, legal interests, or business interests. Further, managing also includes continuous learning from the experience of the framework’s periodic implementation in every period, and applying the learning for a better framework and risk management for the organization.

BRIEF DESCRIPTION OF THE DRAWINGS

The file of this patent contains at least one drawing executed in color. Copies of this patent with color drawing(s) will be provided by the Patent and Trademark Office upon request and payment of the necessary fee.

The various embodiments of the invention will, hereinafter, be described in conjunction with the appended drawings provided to illustrate, and not to limit, the invention, wherein like designations denote like elements, and in which:

FIG. 1 is an environment in which the invention can be practiced, in accordance with various embodiments of the invention;

FIG. 2 is a table illustrating one or more categories associated with at least one focus area, in accordance with an embodiment of the invention;

FIGs. 3A and 3B are tables illustrating risk questions associated with a focus area, in accordance with an embodiment of the invention;

FIGs. 4A and 4B are flowcharts for defining the PRAC model, in accordance with an embodiment of the invention;

FIGs. 5A and 5B are flowcharts for profiling each risk associated with an entity, in accordance with an embodiment of the invention;

FIGs. 6A—6F are tables illustrating change management dashboard attributes of an exemplary entity associated with a focus area, in accordance with an embodiment of the invention; oo

FIG. 7 is flowchart for generating a visual dashboard representing each profiled risk, in accordance with an embodiment of the invention; : )

FIGs. 8A-8D are tables illustrating change management dashboard and exemplary entity risk levels of one or more entities associated with at least one focus area, in accordance with an embodiment of the invention;

FIGs. 9A-9C are tables illustrating exemplary entity dashboard, in accordance with an embodiment of the invention;

FIGs. 10A-10C are tables illustrating exemplary category risk scores, category risk levels of the one or more categories associated with each of the one or more entities associated with a focus area, and exemplary category risk pattern for the focus area, in accordance with an embodiment of the invention;

FIG. 11 is a table representing the exemplary entities, categories, focus area and context of an organization in the visual dashboard, in accordance with an embodiment of the invention;

FIG. 12 is a table illustrating exemplary current risk level, past trends of the risk level and future forecast of the risk level for an entity, in accordance with an embodiment of the invention; BN

FIG. 13 is a table illustrating exemplary current category risk pattern and, past trend of the category risk pattern associated with one or more categories, in accordance with an embodiment of the invention;

FIG. 14 is flowchart for registering each profiled risk associated with the at least one entity, in accordance with an embodiment of the invention;

FIGs. 15A and 15B are flowcharts for administering each registered risk associated with the at least one entity, in accordance with an embodiment of the invention;

FIG. 16 is flowchart for determining a non-compliance score of the at least one entity, in accordance with an embodiment of the invention;

FIG. 17 is flowchart for managing the overall risk associated with each context in an organization, in accordance with an embodiment of the invention;

FIG. 18 is flowchart for periodically governing the risk and the one or more actions associated with each context, in accordance with an embodiment of the invention;

FIGs. 19A and 19B are flowcharts for updating the PRAC model for managing the overall risk associated with any aspect in the organization, in accordance with an embodiment of the invention;

FIG. 20 is a block diagram of a profiling module for profiling each risk associated with an entity, in accordance with an embodiment of the invention;

FIG. 21 is a block diagram of a visual dashboard module for generating a visual dashboard representing each profiled risk, in accordance with an embodiment of the invention; :

FIG. 22 is a block diagram of a registering module for registering each profiled ~ risk associated with the at least one entity, in accordance with an embodiment of the invention; . | Bh

FIG. 23 is a block diagram of an administering module for administering each registered risk associated with the at least one entity, in accordance with an embodiment of the invention;

FIG. 24 is a block diagram of a compliance determining module for determining a non-compliance score of at least one entity, in accordance with an embodiment of the invention; oo - FIG. 25 is a block diagram of a governance module for periodically governing the risk and the one or more actions associated with each context, in accordance with an embodiment of the invention;

FIG. 26 is a block diagram of an updating module for updating the PRAC model, in accordance with an embodiment of the invention; and

FIG. 27 is a block diagram of a PRAC model for managing the overall risk associated with each context in an organization, in accordance with another embodiment of the invention.

DETAILED DESCRIPTION OF THE DRAWINGS

The invention describes a method, system, and computer program product for =~ managing the overall risk associated with any aspect in an organization.

Terms “determination”, “estimation”, and “generation” have been used interchangeably in association with managing the overall risk associated with any aspect in an organization within the entire scope of this patent application. Similarly, terms “software application”, “application”, “software”, and “software solution” have also been used interchangeably within the scope of this patent application. Further, it is well known that software may be defined as the combination of one or more computer applications or computer programs for storing data or performing certain tasks.

For the purpose of clarity, the following terms used, herein, are defined below:

Entity: An entity is a unit of management of risk. An entity could be a software application or a program, a strategic initiative, an operational interest, a financial interest, a legal interest, or a business interest. For example, an entity may be a browsing : application for mobile phones or banking software for financial institutions or a strategy track.

Context: A context is the subject of management of risk. It is, generally, identified by the business leaders of an organization. The context may include one of a business unit in the organization such as a sales unit, development unit, a large business transformation program, a strategic initiative, or a group of business units. The context comprises one or more entities such as banking software, library management software, and inventory management software. The context of risk management is predetermined by a user based on his or her requirements. For example, if the user is the business head of a sales unit of an Information Technology (Im) company, he or she may be interested in managing the risk associated with one or more entities associated with the sales unit. A program could be an entity for the sales unit. Accordingly, the context would be the sales unit. On the other hand, if the user is a program manager responsible for managing a particular large program, then the context would be the program and the projects in the program could be the entities.

Focus Area: A focus area is a grouping of one or more entities of a particular type. For example, a focus area may include development projects, maintenance projects, implementation programs, and government projects. Further, a focus area includes one or more entities. Thus, the context has one or more entities belonging to multiple focus areas. For example, if the user is a business head of a sales unitof an IT company, then he or she may be interested in managing the risk associated with one or more entities in the sales unit. Further, he or she may be interested in managing the risk of only maintenance projects in the sales unit. In such a scenario, the context would be the sales unit; the focus area would be maintenance projects, while the entities would be all software applications or programs which are included in the maintenance projects.

The change management attributes of an entity are defined at focus area level. Some - risk patterns are also analyzed at focus area level, for example, category risk pattern.

The actions on such risk patterns are directed to a senior business leader owning that focus area.

Category: A category is an aspect on which an entity is evaluated to identify if there is any risk associated with that aspect. There may be one more categories (aspects) on which an entity is evaluated. Examples of categories include client relationship, country, product stability, and third-party dependence. As stated earlier, an entity may be evaluated on one or more of the above-mentioned categories. For example, one of the categories for evaluating the risk associated with the entity may be the client relationship. If the client relationship is cordial then it is beneficial to the IT company and leads to a decreased risk associated with the entity. However, if the client relationship has somehow worsened then it is detrimental to the IT company (a client may not wish to continue the relationship or may want to scale-down the relationship) and results in an increased risk associated with the entity. Both business outcomes (for example, profitability) to be achieved and the key business parameters (for example, client relationship) that enable achieving the outcomes may be defined as categories. A category is defined for a focus area. It applies to all entities belonging to the focus area.

The category (for example, a strategic organization initiative) may also be used for horizontal risk analysis across entities, focus areas, and contexts. The risk questions associated with the same category may also vary from one focus area to another focus area.

Risk question: A risk question is based on the tacit knowledge of the organization or context or focus area, and on which one or more entities associated with a focus area are evaluated. Each risk question corresponds to a category (aspect or business parameter) and relates to a focus area. A category may have one or more risk questions. A number of risk questions are, generally, defined for a holistic evaluation of the risks associated with an entity corresponding to a focus area. The answer to each risk question helps in evaluating the risk associated with the entity. For example, the category may be project delivery timeline and one of the risk questions associated with the project delivery timeline may be “is there any expected delay in the project delivery due to internal reasons?” Another risk question may be “is there any expected delay due to client readiness issues on dependent deliverables, for which the IT company is not responsible for?” Further, risk questions may also be of singular risk nature. For example “has the profit margin fallen by >=10 % from the previous period?” If the answer to any of the singular risk is yes, the corresponding entity risk score, being at a minimum, would be placed in a predefined risk score.

Each risk question has a risk question weight associated with it. The risk question weight is a predefined numerical weight that denotes the importance of the risk question to the overall evaluation of the risk associated with the entity.

Risk answer: A risk answer is the input provided by a user to a risk question. A risk answer may take a simple Boolean value or objective values, or a subjective text entry. For example, a risk answer may be “yes”, “high/medium/low”, or “client is satisfied and he/she is looking forward to receiving the final software application” as its value.

There may be more than one risk answers associated with the risk question. The user selects one of the risk answers for a particular risk question. Further, each risk answer has a risk answer weight associated with it. The risk answer weight is a numerical weight on a scale of 1 to 100 (with 100 being the highest) that denotes the impact the risk answer has on the evaluation of the overall risk associated with the entity.

Entity risk score: The entity risk score is a numerical determination of the risk associated with an entity and is based on a set of predefined formulae determined from: the risk answers to all risk questions for the entity, a co-efficient factor and one of the change management dashboard attributes. Each risk question belongs to a category.

Entity risk score indicates to the entity manager, the magnitude of challenges related to the entity. Higher entity risk score implies that there is a higher possibility of materialization of a combination of large, medium or low risks and/or a possibility of _ materialization of a significantly large or critical singular risk and/or a lower ability to recover from the risks. While entity risk score is directed more at entity manager's focus and action, the entity risk level is directed more toward senior manager's action and business leadership’s focus.

Entity risk level: The entity risk level is an indicator of the level of senior manager "action and business leadership focus required for the entity. The entity risk level may be depicted as green (low), yellow (medium), amber (high), and red (critical). The entity risk level is a function of entity risk score and one of the change management dashboard attributes. Higher entity risk levels imply higher focus and action required by the senior manager and/or business leadership. For a better understanding of the focus required by business leadership, a forecast input is provided by the senior manager on when the current entity risk level will move to the lowest risk level (for example, green). It may be evident to any person skilled in the art that the entity risk level may be depicted on a scale of “very critical”, “critical”, “very high”, “high”, “medium”, “low” and “very low”, wherein each element of the scale is represented using different colors.

Category risk score: The category risk score is a numerical determination of the risk associated with category of an entity and is based on a set of predefined formulae determined from the risk answers to all risk questions for the entity and the corresponding category, a co-efficient factor and one of the change management attributes. For example, the category may be client relationship, and a client relationship risk score may be determined to assess if there are any risks involved in the evolution of the client relationship for the entity.

Category risk level: A category risk level for an entity is based on the category risk score corresponding to the entity and one of the change management dashboard attributes. The category risk level may be depicted as green (low), yellow (medium), amber (high), and red (critical). The “high” scale value in the category risk level implies that the risk associated with a category is high and requires further action by the manager and the senior manager of the entity, while the “low” scale value in the category risk level implies that the risk associated with the category is almost negligible and does not require any special attention. It may be evident to any person skilled in the art that the category risk level may be depicted on a scale of “very critical”, “critical”, “very high”, “high”, “medium”, “low”, and “very low”, wherein each element of the scale is represented using different colors.

Category Risk Pattern: Category risk pattern is an aggregate risk and is based on the category risk level of each of the entities of the focus area to which the category belongs. The risk pattern may be depicted as green (low), yellow (medium), amber (high), and red (critical). This risk pattern is determined by applying a set of pre-defined formulae on the category risk level for each of its entities. For example, referring to FIGs. 10A-10C, if the non-functional requirements of category risk pattern for a focus area “Development projects” is critical (or red), more attention and action by senior management of the focus area on non-functional requirements is required.

Change management dashboard attributes: The change management dashboard attributes comprise two main attributes: Ability to recover and business leadership visibility. : a. Ability to recover attribute: The ability to recover attribute further includes the following: o Life cycle stage attribute: This attribute is defined by the ability to recover factor corresponding to the current lifecycle stage of an entity. This is defined at the focus area level and is applicable for all entities of the focus area. For example, FIG. 6B depicts exemplary life cycle stage attribute. o Risk Action attribute: This attribute indicates risk action discipline and effectiveness of the entity for the past period. It is defined by the ability to recover reduction factor corresponding to the non-compliance score of an entity. For example, FIG. 6F depicts exemplary risk action attributes. o Human risk intelligence attribute: This attribute brings in the human risk intelligence aspect into the entity risk score. This attribute is based on analysis of the past, present and future aspects of the entity risk by the independent risk manager. Based on this intelligence, an independent risk manager could override the derived and calculated ability to recover factor for an entity. b. Business leadership visibility attribute: The business leadership visibility attribute includes the following attributes:

~ o Impact or strategic value of the entity - Impact is defined for a focus area and is applicable for all entities of the focus area. The basis of impact / strategic value includes, but is not limited to, one or more of revenue, size, reputation factor, and market analysis or analyst ratings of an entity. o Visibility matrix scale: Visibility matrix scale defines the X Axis and Y Axis scales of the Change Management Dashboard for each focus area. It contains the strategic value mapping table to Y axis (for example, to each of Y1, Y2,

Y3, Y4, and Y5) and the entity risk score mapping to X axis (for example to each of X1, X2, X3, X4, and X5) as depicted in FIGs. 8A-8C.

FIG. 1is an environment 100 in which the invention can be practiced, in accordance with various embodiments of the invention. Environment 100 includes a user 102 that accesses a system 104. User 102 may be an employee of an organization entrusted with the responsibility of managing the overall risk associated with any aspect in the organization. For example, the employee may be a business leader of the sales unit of an Information Technology (IT) company and the context may be the sales unit.

System 104 allows user 102 to assess and manage the overall risk associated with each context in the organization.

In accordance with an embodiment of the invention, user 102 accesses system 104 to select the aspect for which user 102 wants to manage the risk. The aspect may be a business unit of the organization or even an entity, i.e., a software application. This aspect selected by user 102 is, hereinafter, referred to as the context. For example, the business leader of the sales unit of an IT company wants to manage the risk associated with the sales unit. In such a scenario, the business leader selects the sales unitas the “context. ;

The overall risk associated with each context is managed by defining the focus areas associated with each context, and the change management dashboard attributes for each focus area of the context, risk profiling of at least one entity of one or more entities associated with each context, registering each profiled risk associated with the at least one entity, administering each registered risk associated with the at least one oo 12 entity, and determining a risk score associated with the at least one entity. Further, an integrated visual management dashboard is generated for focusing management's attention on the right set of entities and patterns on a continuous basis for managing the overall risks and actions associated with each context of the organization. The one or more entities are associated with the at least one focus area; and the at least one focus area in turn is associated with each context. Further, management of the risk associated with the each context in the organization is explained in detail in conjunction with FIGs. 4-19.

In an embodiment of the invention, user 102 may be a business leader of a sales unit in an IT company and he or she is responsible for managing the risk associated with the sales unit. User 102 accesses system 104 to determine the risk associated with the one or more entities. Here, the entities may be software applications or programs in the sales unit. According to the determined risk, user 102 may decide the nature of his or her intervention and monitoring for one or more of the entities.

FIG. 2 is a table illustrating one or more categories associated with at least one focus area, in accordance with an embodiment of the invention. As defined earlier, a category is an aspect on which an entity is evaluated to identify if there is any risk associated with any of those aspects for the entity. Further, FIG. 2 also depicts the one or more categories along with an exemplary category risk score for an exemplary entity. - In an embodiment of the invention, examples of categories are client relationship, country, technology domain, effort estimation and schedule, finance, company obligations, non-functional requirements, overall delivery comfort, partner dependency, positive risks, product stability and fitment, program and product management, scope and requirements, and resource staffing. It may be apparent to any person skilled in the art that the above-mentioned categories are only for illustrative purposes and other aspects that impact the risk associated with an entity may be included without deviating from the scope of the invention. Further, these mentioned categories are explained in detail below.13

In accordance with an embodiment of the invention, the one or more categories are predefined by an expert in the domain of management of risks in an organization such as a risk manager, a business leader, an engagement manager, and a delivery manager. In accordance with various embodiments of the invention, a category risk score for an entity is associated with a category and entity, and corresponds to a predefined time period, such as a week or a month in a calendar year. _ For the sake of clarity, the one or more categories are explained in detail below:

Client relationship: This category is defined to cover the risks related to the client relationship for an entity. For example, the impact of the poor client relationship or a high risk score in client relationship is to lose the client and hence revenue from the client. All other risk influencing factors being equal, an entity with an excellent engagement level feedback (client relationship) from the client will have a lower risk score, as compared to an entity with a poor engagement level feedback from the client.

Country: This category refers to the country of the client. Different countries have different cultural values and different styles of conducting business. Different countries have different regulatory requirements. The impact of a high risk score in country implies higher business risks in the country. All other risk influencing factors being equal, an entity where the client's country’s regulatory requirements are fully understood and its impact clearly managed internally and externally, would have a lower country risk score, as compared to an entity where the client's country’s regulatory requirements are not fully understood and not clearly managed internally or externally.

Technology domain: This category is defined to cover the risks related to technology domain of the entity, if applicable. The high technology risk score for the entity would affect quality and hence revenue or margin. All other risk influencing factors being equal, an upcoming technology domain with no technology experts available for the entity would lead to a higher risk score, as compared to an existing technology domain with required number of technology experts available for the entity.

Effort estimation and schedule: This category is defined to cover the risks related to the effort estimation and client schedule associated with an entity. The impact of high risk score in effort estimation and schedule implies higher chances of not meeting the deadline set for the entity and as a result may lead to client dissatisfaction or loss of revenue for the company. All other risk influencing factors being equal, effort estimation and schedule category of a new type of project for the organization with little or no prior organization capability baseline data available, would have a higher risk score as compared to that of a type of project where there is extensive organization experience and reliable capability baseline data available.

Finance: This category is defined to cover risks related to the financial aspects of an entity. The impact of high risk score in finance implies higher chances of not meeting the revenue objectives expectation from the entity. All other risk influencing factors being equal, a program with large-value milestone payments, and at the same time no regular reviews by senior management toward these milestones, would have higher finance risk score as compared to a program with a low-value milestone payments and regular reviews by senior management for each milestone.

Company obligations: This category is defined to cover risks related to the contractual obligations of the company. The impact of high risk score in company obligations implies higher chances of not meeting legal or contractual obligations for this entity. All other risk influencing factors being equal, a program where there are many open-ended contractual clauses would have higher contractual obligation risk score as compared to a program with no open-ended contractual clause.

Non-functional requirements (NFR): This category is defined to cover requirement gaps related to non-functional requirements—which may not be explicitly stated by the client for various reasons. Examples of non-functional requirements are application response time, availability, etc. The impact of high risk score in non-functional requirements implies higher chances of the client not planning for required hardware or software infrastructure, resulting in the project not meeting the client's user's expectation. All other risk influencing factors being equal, a program where the non- functional requirements are not clearly articulated and agreed upon with the client, would

"have higher NFR category risk score as compared to a program where this has been done.

Overall delivery comfort: This category is defined to get the manager's subjective view of control over the risks of the program. The impact of high risk score in overall delivery comfort implies lower confidence of the manager for the success of the program. All other risk influencing factors being equal, a program where the manager has a low confidence of success of the program will have a higher risk score, as . compared to the manager with higher confidence of success of the program.

Partner dependency: This category is defined to capture risks due to dependencies with internal and external partners. The impact of high partner dependencies would lead to higher complexities of the project and thus increasing the chances of failure of the project. All other risk influencing factors being equal, a program with experienced partners and a clear documented understanding of inter-partner dependencies for the overall program success would have lower risk score, as compared to a program with inexperienced partners and poor documented understanding of inter-partner dependencies for the overall program success.

Positive risks: This category, when defined, is not scored but leveraged to get the opportunities in the program.

Product stability and fitment: This category is used to understand the risks related to the quality of the product and its fitment to the customer program. Low product stability and fitment implies higher defects and higher customization for the fitment gaps, - leading to an adverse impact on the quality, schedule or cost expectations of the client.

All other risk influencing factors being equal, a customer program associated with a new product release and having client requirements at a high level could have higher product stability and fitment risks, as compared to one which is on an existing release and with requirements which are at a detailed level.

Program and product management: This category covers the program and product management aspects, which are not covered in the other categories. This covers risks to specific explicit program business outcomes/performance metrics (for example revenue or profit target, number of IPs, etc.). This could also cover risks related to program management process such as the number of reviews done by senior manager. The impact of high risk score for program management is seen in its process and change management aspects, thus increasing the chances of failure of the project.

All other risk influencing factors being equal, a customer program associated with a weak and inefficient program management practices could have higher chances of failure, as compared to one which has strong program management practices.

Scope and requirements: This category covers the risks related technical and functional scope of the program in terms of completeness and correctness. The impact of high risk score for scope and requirements is multi-fold and could adversely affect other aspects of the program such as effort, schedule, finance, etc., and also result in the program not meeting the client's expectation. All other risk influencing factors being equal, a program where the scope and requirements are not clearly articulated and. agreed upon with the client would have higher scope creep related issues, as compared to a program where this has been done.

Resource and staffing: This category covers the risks due to infrastructure and talents. For example, risks due to lack of appropriate skills or required number of staff or software licenses needed by the program. The impact of high risk score for resources and staffing could be in terms of not meeting the agreed upon schedule or poor quality of work due to stretch hours and low employee morale. All other risk influencing factors being equal, a program with a high risk score for resources and staffing would have low delivery comfort, as compared to a program where this has been addressed.

In addition to the risk influence factors of a category being equal, following are some other reasons, due to which category risk score may also vary between two entities: : a. An entity with an excellent track record of action on risks (measured by non-compliance score in the previous period) would have lower risk score, as compared to an entity having poor track record of action on , risks.

b. An entity which is in an advanced stage of its lifecycle would have a higher risk score than the entity which is early in the lifecycle stage. c. An entity with a higher strategic value (customized for each focus area), would have higher risk score, as compared to an entity with a lower strategic value. d. Two entities having the same risk score could have different levels, if their corresponding focus areas are mapped to a different row and/or column in the change management dashboard for the same risk score as customized to the business leadership’s requirement. e. Two entities with similar risks could have different risk levels, if the risk manager, based on his/her analysis of the risk forecast, senior manager's forecast accuracy and/or other factors, feels that the ability of the one to recover is lower than the other.

In addition to depicting categories, FIG. 2 depicts an exemplary category risk score for an entity corresponding to each category. The category risk score is a numerical determination of the risk associated with category of the entity and is based on a set of predefined formulae determined from the risk answers to all risk questions for the entity and the corresponding category, a co-efficient factor and one of the change management attributes.

It may be apparent to a person ordinarily skilled in the art that the category risk score for each of the categories may be measured in a numerical value (example 10, 20) or grades (example, a, b, c, d), scale (1-10, 10 being the highest), rating (high, medium, low), and the like. For exemplary purposes, we have used numerical value measurement in the description.

FIG. 2 also depicts exemplary category risk score for an entity, corresponding to each shown category, for predefined time periods — “Jan 2010”, “Feb 2010”, “Mar 2010”, and “Apr 2010”. The entity may be “banking software 2” belonging to focus area “development projects”. Additionally, the exemplary categories depicted in FIG. 2 correspond to the focus area “development projects”. For example, the category risk score for client relationship is 0.00 for “Jan 2010”, and for country it is 24.13 for “March 2010".

FIG. 3A and 3B are tables illustrating risk questions associated with a focus area, in accordance with an embodiment of the invention. A risk question is based on the tacit knowledge of the organization or context or focus area, and on which one or more entities associated with the focus area are evaluated. Each risk question corresponds to a category (aspect or business parameter) and relates to a focus area. The category may have one or more risk questions. A number of risk questions are, generally, defined for a holistic evaluation of the risks associated with an entity corresponding to a focus. area. The answer to each risk question helps in evaluating the risk associated with the entity. : In accordance with an embodiment of the invention, the risk questions are defined by an expert in the domain of management of risks such as a risk manager, a business leader, an engagement manager, and a delivery manager. In accordance with various embodiments of the invention, the risk answer associated with a risk question is input once at a predefined time and is considered valid for a predefined time period, such as a week or a month of a calendar year. The predefined time and the predefined time period are predefined in system 104 by an expert in the domain of risk management.

FIG. 3A depicts an exemplary set of risk questions and corresponding risk - answers for category “effort estimation and schedule”. The set of risk questions include the following: 1. Confident on effort estimation and realistic timelines? 2. Are the effort estimate and timelines decided (change in the fig also) after getting a high level of clarity on the requirements? 3. Is the effort information available for each of the tracks and is it reviewed? oo 19

4. Does any of the projects / tracks have high effort overrun or schedule slippage that can impact it at a program level?

Each of the risk questions has more than one risk answers, and one of the risk answers is selected by a user. Typically, the user is an employee of the organization who is in charge of the timeline and delivery of the entity which is being evaluated. For example, the risk answers corresponding to the risk question “Confident on effort estimation and realistic timelines?” include the following: 1. “Yes with 90-100% confidence” 2. “No (confidence less than 50%)” 3. “Yes with 50-90% confidence” 4. “Not applicable”

FIG. 3B depicts another exemplary set of risk questions and corresponding risk answers for category “change management”. The set of risk questions include the following: 1. Has a change management process been identified? 2. In case of changes required for existing application, have : ownership/responsibilities been clearly defined and assigned? 3. Is the IT company responsible for any organization change management activity and / or communication management activity at the client side?

Please provide the details.

The risk answers corresponding to the risk question “Has a change management process been identified?” include “Yes” and “No”.

It may be apparent to any person skilled in the art that the above-mentioned risk questions and corresponding risk answers are only for illustrative purposes and other risk questions associated with a category and relevant to each context may be included without deviating from the scope of the invention.

FIGs. 4A and 4B are flowcharts for defining the PRAC model, in accordance with an embodiment of the invention. A PRAC model is defined as a risk management framework for managing the risk associated with any aspect in an organization. “PRAC model” is an acronym for Profiling, Registering, Administering, and Compliance model.

Profiling of a risk is defined as the identification of the risk associated with any aspect in the organization. Registering is defined as the detailed description of each profiled risk associated with any aspect in the organization. Administering is defined as taking one or more actions to handle each registered risk associated with any aspect in the organization. Compliance is the measure of the ability of the one or more action steps to successfully administer the risk associated with any aspect in the organization.

At 402, a plurality of contexts is defined in the organization. A context is defined . as the subject of risk management. lt is, generally, identified by the business leaders of an organization. The context may include one of a business unit in the organization, a strategic initiative in a business unit, and a strategic unit in the organization. The context of risk management is predetermined by a user based on his or her requirements. For example, if the user is the business head of a sales unit of an Information Technology (IT) Company, he or she may be interested in managing the risk associated with one or more software applications or programs associated with the sales unit. Accordingly, the context would be the sales unit. Further, if the user is a program manager responsible for managing a particular program, then the context would be the program.

At 404, at least one entity associated with each context is defined. An entity is defined as a software application or a program. The entity may include one of a project, a program, a strategic initiative, an operational interest, a financial interest, a legal interest, and a business interest in the organization. For example, an entity may be a browsing application for mobile phones or banking software for financial institutions. A strategic initiative is defined as an initiative to improve the competitive advantage ofa business unit of the organization, for example, the management strategy of a product.

An operational interest is a program which needs the attention of the organization's management on its operational parameters. A business interest is a program which is critical to the success of the organization. For example, large transformation software for a new strategic market is a business interest for the IT company.

At 406, at least one focus area for each context is defined. A focus area is defined to be a grouping of one or more entities of a particular type. For example, a ) focus area may include development projects, maintenance projects, implementation. programs, and government projects. Further, a focus area may include multiple entities.

Thus, a context may have multiple entities belonging to multiple focus areas. For example, if the user is a business head of a sales unit of an IT company, then he or she may be interested in managing the risk associated with one or more entities in the sales unit. Further, he or she may be interested in managing the risk of only maintenance projects in the sales unit. In such a scenario, the context would be the sales unit; the focus area would be maintenance projects, while the entities would be all software applications or programs which are included in the maintenance projects.

At 408, one or more change management dashboard attributes are defined for the at least one focus area. The one or more change management dashboard attributes are the set of factors used in the graphical depiction of the risk associated with the at least one entity for timely business visibility and decision making. The one or more change management dashboard attributes include the ability to recover attribute and the business leadership visibility attribute. The impact or strategic value is defined based on the importance of an entity. For example, the impact is determined based on the financial revenue associated with the entity. For example, banking software with higher financial revenue will have a higher value for impact, as compared to a library management system for a school with significantly lower financial revenue. The ability to recover is defined as the ability of an entity to recover from any major risk associated with the entity, and it is based on the lifecycle stage and the action discipline and effectiveness of the previous period. The action discipline and effectiveness is determined by the non-compliance score for the entity. For example, if the lifecycle stage for banking software is “planning stage” (an initial stage of the SDLC) then the ability to recover is higher, as compared to “testing stage” (one of the later stages of the

SDLCQ) as the lifecycle stage for the banking software.

At 410, at least one category for each focus area is defined. A category is defined as an aspect on which an entity is evaluated to identify if there is any risk associated - with that aspect. There may be one or more categories (aspects) on which an entity is evaluated. Examples of categories include client relationship, country, product stability, and third-party dependence. As stated earlier, an entity may be evaluated on one or more of the above-mentioned categories. For example, one of the categories for evaluating the risk associated with the entity may be the client relationship. If the client relationship is cordial then it is beneficial for the IT company and translates to a decreased risk associated with the entity. However, if the client relationship has somehow worsened then it is detrimental to the IT company (a client may not wish to continue the relationship or may want to scale-down the relationship) and may result in an increased risk associated with the entity. : :

At 412, a plurality of risk questions for the at least one category are defined to assess the risk associated with the at least one entity corresponding to the at least one category. A risk question is based on the tacit knowledge of the organization or context or focus area, and on which one or more entities associated with a focus area are evaluated. Each risk question corresponds to a category (aspect or business parameter) and relates to a focus area. A category may have one or more risk questions. A number of risk questions are, generally, defined for a holistic evaluation of the risks associated with an entity corresponding to a focus area. The answer to each risk question helps in evaluating the risk associated with the entity. For example, the category may be the project delivery timeline, and one of the risk questions associated with the project delivery timeline may be “is there any expected delay in project delivery due to internal reasons?” Another risk question may be “is there any expected delay due to client readiness issues on dependent deliverables, for which the IT company is not responsible?” Further, risk questions could also be of singular risk nature. For example, “has the profit margin fallen by >=10 % from the previous period?” If the answer to any of the singular risk is yes, the corresponding entity risk score, being at a minimum, would be placed in a pre-defined risk score.

At 414, an entity risk score formula is defined. The entity risk score formula is the mathematical formula to determine the risk associated with the at least one entity. For example, the entity risk score formula is: (Z (first parameter x second parameter)/Z (third parameter x 100)) x (100 x 0.66 x (fourth parameter/fifth parameter), where first parameter, second parameter, third parameter, fourth parameter, and fifth parameter are factors corresponding to the at least one entity.

FIGs. 5A and 5B are flowcharts for profiling each risk associated with an entity, in accordance with an embodiment of the invention. Profiling of a risk is defined as the identification of the risk associated with an entity based on an input corresponding to each of the risk questions. | : ~ At 502, an input corresponding to each of the at least one risk question is received. The input includes at least one of a risk answer, a freeform remark based on the risk answer and a generic input.

The freeform remark is a subjective input by the user in addition to the risk answer. For example, consider a risk question “Is the effort information available for each of the tracks and is it reviewed”, the risk answer is “No” and the freeform remark associated with the risk answer is “Effort information duly reviewed”. The generic input is also a subjective input by the user for a generic question associated with each category.

A generic question is a question associated with a category in addition to the one or more questions. For example, consider a generic question “Is there any other risks associated with this category” associated with the category “client relationship”, the generic input associated with the generic question is “No”, implying that there are no additional risks associated with the category “client relationship” associated with the banking software.

At 504, one or more change management dashboard attributes associated with the entity are received. In an embodiment of the invention, the one or more change management dashboard attributes include the impact or strategic value and lifecycle stage. FIG. 6A illustrates an example where the impact is USD 450,000 for an entity “banking software” in the “planning” lifecycle stage, the focus area is “development projects” and the risk associated with the entity “banking software” is to be evaluated for the predefined time period “Jan 2010”. Further, the lifecycle stage is the SDLC stage of the entity, i.e., development stage, testing stage, etc. FIG. 6B illustrates an exemplary relationship between the lifecycle stage and the ability to recover attribute.

At 506, a category risk score and category risk level associated with the at least one category corresponding to the entity is determined based on the input corresponding to each of the at least one risk question of entity associated with the category and the change management dashboard attributes.

For example, referring to FIGs. 6A—6C for the entity “banking software” for predefined time period “Jan 2010”, the associated first risk question for category “effort estimation and schedule” is — “Are the effort estimate and timelines defined after getting a high level of clarity on the requirements?” The associated risk question weight is “12”, the risk answer received is “No”, the risk answer weight is “1007, and the freeform remark received is “The clarity was lacking when the effort timelines were drawn”. The second risk question associated with category “effort estimation and schedule” is— “Is the effort information available for each of the tracks and is it reviewed?” The associated risk question weight is “12”, the risk answer received is “No”, the risk answer weight is “0”, and the freeform remark received is “Effort information duly reviewed”.

In accordance with an exemplary embodiment of the invention, the category risk score corresponding to a category may be determined as follows:

(Z (risk question weight corresponding to each risk question associated with the category x risk answer weight corresponding to each risk answer associated with the category)/Z (risk question weight corresponding to each risk question associated with the category x 100)) x (100 x 0.66 x (co-efficient factor/ability to recover), where the co- efficient factor is a mathematical factor used for the computation of the category risk score, and it is based on the impact value of the entity. FIG. 6D illustrates the relationship between the impact and the co-efficient factor.

The ability to recover factor is based on lifecycle stage and non-compliance score of the entity. Referring to FIG. 6B, range of values of lifecycle stage of the focus area to which the entity belongs is associated with a corresponding ability to recover value.

Referring to FIG. 6F, the ability to recover reduction factor is a mathematical value selected based on the range of values of the non-compliance score of the entity for the previous predefined period. Since, the non-compliance score is the measure of the inability to successfully administer the risk associated with an entity, therefore higher the non-compliance score, greater are the chances that the entity will not be able to recover from the one or more risks associated with it.

Therefore, the category risk score for category “effort estimation and schedule” is (((12 x 100) + (12 x 0))/((12 x 100) + (12 x 100))) x 100 x 0.66 x (0.80/ 1.50) => 17.6

Similarly, the category risk score for category “change management” is ((25 x 70)/(25 x 100)) x 100 x 0.66 x (0.80/1.50) => 24.64

A non-zero category risk score implies that there are one or more risk questions in the category with a non-zero risk score. Each of these risk questions is a profiled risk associated with the entity and the category.

Based on the current example, both the categories “change management” and “effort estimation and schedule” have one or more profiled risks associated with “banking software” entity.

Category risk level is derived from the category score and the business leadership visibility attribute. For example, category risk level for country category for “banking software 2” in FIG. 2 is depicted in red color for Jan 2010.

In the above example of “effort estimation and schedule”, the category has a category risk score of 17.6. Assuming the impact or strategic value of the entity is 2 m

USD, this corresponds to X3 and Y3 in Fig 8A, based on mapping provided in Fig 8B and 8C, respectively. This corresponds to the category risk level denoted with yellow color. Co

At 508, the entity risk score and the entity risk level associated with an entity, are determined based on the input corresponding to each of the at least one risk question of the entity, and the one or more change management dashboard attributes.

In accordance with an exemplary embodiment of the invention, the entity risk score may be determined, based on the entity risk score formula, as (Z (risk question weight corresponding to each risk question associated with the category x risk answer weight corresponding to each risk answer associated with the category)/Z (risk question weight corresponding to each risk question associated with the category x 100)) x (100 x . 0.66 x (co-efficient factor/ability to recover).

Thus, based on the current example, “banking software” risk score is: (((12 x 100) + (12 x 0) + (25 x 70))/((12 x 100) + (12 x 100) + (25 x 100))) x 100 x 0.66 x (0.80/1.50) => 21.2, where the co-efficient factor is a mathematical factor used for the computation of the entity risk score, and it is based on the impact value of the entity. FIG. 6D illustrates the relationship between the impact and the co-efficient factor.

The ability to recover factor is based on the lifecycle stage and non-compliance’ score of the entity. Referring to FIG. 6B, range of values of the lifecycle stage of the focus area to which the entity belongs is associated with a corresponding ability to recover value. Referring to FIG. 6F, the ability to recover reduction factor is a mathematical value selected based on the range of values of the non-compliance score of the entity for the previous predefined period. Since, the non-compliance score is the measure of the inability to successfully administer the risk associated with an entity, therefore higher the non-compliance score, greater are the chances that the entity will not be able to recover from the one or more risks associated with it.

At 510, a forecast input corresponding to the entity risk level associated with the entity is received, the forecast input being received for the predefined time period. The forecast input is defined as the input specifying the predictive timeline for the reduction in the entity risk score. For example, the forecast input for entity “banking software” is - “banking software risk will reduce to the lowest risk level in Feb 2010”. :

At 512, the entity risk score and the entity risk level are updated based on the forecast input. In accordance with an embodiment of the invention, the one or more change management dashboard attributes are also updated based on the forecast input.

For example if the forecast input is not favorable for “banking software” entity, the ability to recover factor can be updated from 1.5 to 1. Accordingly, the banking software entity . risk score would increase to 31.8.

In accordance with an embodiment of the invention, the input corresponding to the one or more questions and the one or more change management dashboard attributes are received from a submitter (an employee of the IT company), for example, a program manager of a program tasked with the timeline and delivery of the program.

In accordance with another embodiment of the invention, the input corresponding to the one or more questions and the one or more change management dashboard attributes are reviewed by a reviewer (another employee of the IT company), for example, a delivery manager of the IT company’s delivery unit. In accordance with yet another embodiment of the invention, the input corresponding to the one or more question and the one or more change management dashboard attributes are approved by an approver (a senior employee of the IT company), for example, a group manager of the

IT company’s maintenance business group.

It may be apparent to a person ordinarily skilled in the art that other mathematical operations may be applied to the input corresponding to the one or more risk questions 28 oo and the one or more change management dashboard attributes to determine the category risk score and the entity risk score.

FIG. 7 is flowchart for generating a visual dashboard for each profiled risk, in accordance with an embodiment of the invention. The visual dashboard provides the overall risk picture for business leadership decision making by visually depicting each - profiled risk associated with an entity.

At 702, a change management dashboard for each context is generated based on the entity risk score and the one or more change management dashboard attributes.

The change management dashboard represents entity risk levels of the one or more entities associated with the at least one focus area.

In accordance with an embodiment of the invention, the change management ~ dashboard for each context is depicted as a two-dimensional X-Y graph denoting the entity risk score with the visibility matrix scale for X Axis mapped on the same in the X

Axis and the strategic value with visibility matrix scale for Y Axis mapped on the same in the Y-axis for a predefined time period. Each entity is depicted on the two-dimensional

X-Y graph based on the values for the entity risk score associated with the entity and the change management dashboard attributes. FIG. 8B is a table illustrating an exemplary . X-Axis visibility matrix scale, mapping entity risk score and change management dashboard X-Axis, in accordance with an embodiment of the invention. FIG 8C is a table illustrating an exemplary Y-Axis visibility matrix scale, mapping strategic value and change management dashboard Y-Axis level, in accordance with an embodiment of the invention. FIG. 8A is a table illustrating an exemplary change management dashboard with exemplary entity risk levels of the one or more entities associated with the at least one focus area associated with at least one context, in accordance with another ‘embodiment of the invention. In the illustration, green color represents entities with low entity risk levels; yellow color represents entities with intermediate entity risk levels, amber color represents entities with high entity risk levels, and red color represents entities with critical entity risk scores.

It may be apparent to any person skilled in the art that the one or more entities may be periodically viewed by a senior manager of the organization based on the associated entity risk level. FIG 8D is a table illustrating an exemplary review frequency based on the entity risk level in the dashboard.

In accordance with another embodiment of the invention, the change management dashboard for the organization may be displayed to a user with the help of a generic graphical user interface (GUI) (not shown in the figure) as a consolidated view of the change management dashboard for each context of the plurality of contexts. This provides an organization level perspective on the risks.

In accordance with another embodiment of the invention, the change management dashboard represents to a business leader both a top-down view (for example, risk level of a large program entity) and a bottom-up view (for example, risk levels of all projects belonging to the program entity) in the same dashboard.

In accordance with another embodiment of the invention, the change management dashboard also represents to a business leader risk levels of different types of entities (for example, programs, projects, proposals, etc.) in a single dashboard.

In accordance with another embodiment of the invention, the change management dashboard for a category may be displayed to the user as a consolidated view of all entities associated with the category. The category is an aspect on which the risk for the entity is evaluated. The risk levels shown are category risk levels corresponding to the entity. The entities shown may belong to the one or more focus areas associated with the one or more contexts of the plurality of contexts.

In accordance with another embodiment of the invention, the context risk pattern representing percentage of entities in green, yellow, amber, and red risk levels can be derived from the change management dashboard for the context. In the example depiction of FIG. 8A, the risk pattern for context 1 is 28 % entities in green, 44 % in yellow, 22 % in amber, and 6 % in red risk levels. : :

At 704, an entity dashboard for the at least one entity is generated. The entity dashboard displays the category risk levels for previous and current period for the entity.

It also displays entity risk levels for previous period, current period, and the forecast input for the future periods, including the period when the entity risk level would reduce to the lowest risk level. FIGs. 9A—9C are tables illustrating exemplary entity dashboard, in accordance with another embodiment of the invention.

In the illustration, green color represents categories with low risk scores, yellow color represents categories with intermediate risk scores, and red color represents categories with high risk scores.

In accordance with an embodiment of the invention, the change management dashboard for each context allows the user to select an entity from the one or more entities. Thereafter, the entity dashboard for the selected entity is generated. The entity dashboard allows the user to select a category of the entity. Thereafter, the risk questions and their answers and freeform text, are displayed for the current and the past periods. This enables a business leader to better understand assumptions and reasons for the current and past risk levels of the entity and the corresponding category. Such an approach is known as “drill down approach”. This enables better decision making by the business leader.

FIGs. 10A=10C are tables illustrating exemplary category risk scores, category risk levels of the one or more categories associated with each of the one or more entities associated with a focus area and exemplary category risk pattern for the focus area, in accordance with an embodiment of the invention.

Category risk pattern is an aggregate risk and is based on the category risk level of each of the entities of the focus area to which the category belongs. The risk pattern may be depicted as green (low), yellow (medium), amber (high), and red (critical). This - risk pattern is determined by applying a set of predefined formulae on the category risk level for each of its entities. For example, if the non-functional requirements category risk pattern for a focus area (for example, development projects) is critical (or red), more attention and action by senior management of the focus area on non-functional requirements is required. . At 708, the plurality of contexts, the at least one entity corresponding to each context, the at least one focus area for each context, and the at least one category for . each focus area are represented in the visual dashboard. FIG. 11 is a table representing the exemplary entities, categories, focus area, and context of an organization in the visual dashboard, in accordance with an embodiment of the invention.

At 708, the current risk level, past trends of the risk level, future forecast of the risk level for each entity are represented as attributes for each entity. The current risk level of an entity is the entity risk level associated with the entity for the predefined time period. The past trends of the risk level of an entity are the entity risk level associated with the entity during preceding predefined time periods. The future forecast of the risk level is the entity risk level associated with the entity for a subsequent predefined time period. FIG. 12 is a table illustrating exemplary current risk level, past trends of the risk level, and future forecast of the risk level for an entity, in accordance with an embodiment of the invention.

At 710, the current risk pattern of each category within each focus area and the past trend of category risk pattern are represented. FIG. 13 is a table illustrating the exemplary current category risk pattern and the past trend of the risk pattern of the category risk pattern associated with the one or more categories, in accordance with an embodiment of the invention.

FIGs. 10A—10C are tables depicting the exemplary category risk pattern, in accordance with an embodiment of the invention.

Category risk pattern score = (3 category risk weight of the associated category risk level of each entity in the focus area)/(total number of entities in the focus area).

For example, in FIGs. 10A-10C, category risk levels defined are red, amber, yellow, and green.

Number of entities having red category level = 1; number of entities having amber category level = 0; number of entities having yellow category level = 2; number of entities having green category level = 0. :

Category risk level weight of red = 1; category risk level weight of amber = 0.6; category risk level weight of yellow = 0.3; category risk level weight of green = 0.

Category risk pattern score for category 1 for focus area 1 = sum of category risk level weight for the 4 entities for category 1 divided by 4, i.e., (1 +0 + 0.3 + 0.3)/4 => 04. Category risk pattern for category 1 for focus area 1 = Amber.

FIG. 14 is flowchart for registering each profiled risk associated with the at least one entity, in accordance with an embodiment of the invention. Registering is defined as the detailed description of the one or more risks associated with each profiled risk associated with the entity. FIG. 6E, in conjunction with FIGs. 6A—6D, are tables illustrating an exemplary entity associated with the focus area, in accordance with an embodiment of the invention, and are referred to as an example while describing FIG. 14.

At 1402, each profiled risk is assigned one or more registered risks. Each of these registered risks is assigned a risk owner, the risk owner being an employee of the organization. A risk owner is an employee of the IT company entrusted with the responsibility to manage the risk assigned to him or her and devise processes to administer it.

For example, referring to FIG. 6C, the risk question “Is the IT company responsible for any organization change management activity and/or communication management activity at the client side? Please provide the details”. This risk question, belonging to category “change management” for the entity “banking software”, has a non-zero answer weight corresponding to the answer input, leading to a non-zero risk score for the risk question. This is a profiled risk for the entity “banking software” and would have one or more associated risks. FIG. 6E depicts an exemplary assignment of one risk for the profiled risk. Further, referring to FIGs. 6A—6F, the focus area associated with “banking software” is “development projects” for the context “sales unit”. Referring to FIG. 6E, the delivery manager (or the senior manager) of this entity may be assigned as the risk owner for the one risk.

At 1404, each registered risk is assigned a risk priority. Each registered threat may be assigned a risk priority of “high/medium/ low” or on a scale of 1to 3 or 1to 5, etc., with 1 denoting lowest risk priority. For example, the risk “IT Company responsibilities on Change management at the client side not clear. This could lead to inadequate program objective buy-in at the client side resulting adversely on the program success”. Thus, it is assigned “medium” as the risk priority.

At 1406, an exit criterion is assigned to each registered risk. The exit criterion is defined as the steps to be taken by the risk owner to administer each of the risks of the registered risk. For example, the exit criterion assigned to the risk in FIG 6E, is “finalize the change management plan”. :

At 1408, an effectiveness level is assigned to each registered risk.

The effectiveness level is defined as the sufficiency of the exit criterion to aE successfully administer the risk corresponding to the profiled risk. The effectiveness level is assigned a percentage value denoting the percentage sufficiency of the exit criterion to successfully administer the risk corresponding to the profiled risk.

For example, the effectiveness level “risk level reducing” implies that the actions are effective in the administration of the associated risk. ~The method of assigning risks to a profiled risk and assigning a risk owner, a risk priority, an exit criterion, and an effectiveness level to each of the risks of a profiled risk is collectively known as the registering of each profiled risk. Each of the risks registered for the profiled risks, is hereinafter, referred to as a registered risk.

FIGs. 15A and 15B are flowcharts for administering each registered risk associated with the at least one entity, in accordance with an embodiment of the invention. Administration is defined as the action steps to reduce each registered risk associated with the entity.

At 1502, one or more actions for administering each registered risk associated with the at least one entity are received. An action is defined as the outline of steps to be’ taken to administer each registered risk associated with an entity.

For example, referring to FIGs. 6A—6E, the actions corresponding to the registered risk “IT Company responsibilities on Change management at the client side not clear. This could lead to inadequate program objective buy-in at the client side resulting adversely on the program success” are “Preparation of Change management plan (CMP) document’, and “Execution of change management plan as per CMP document”.

At 1504, a risk response strategy corresponding to an action is received from the risk owner. The risk response strategy for the action is defined as the strategy for executing the action corresponding to the registered risk associated with the entity. For example, “mitigate” as risk response strategy implies that the action is aimed at the mitigation of the registered risk by the risk owner.

In the example, the risk response strategy corresponding to the one or more actions is “mitigate”.

At 1508, exposure percentage of the one or more actions for administering each registered risk is received from the risk owner. Exposure percentage is defined as the percentage of risk addressed by the one or more actions in successfully administering the risk.

At 1508, a due date associated with each of the actions of each of the registered risk is received from the risk owner. The due date is defined as the target date for completing the action for administration of the registered risk.

For example, referring to FIG. 6E, the due date for administering the action “preparation of change management plan (CMP) document” is September 22,2010.

At 1510, an action owner associated with each registered risk is assigned. The action owner is defined as the employee of the organization responsible for ensuring the completion of the action for the administration of the registered risk. In the current example, the action owner is “Group Manager’.

At 1512, a compliance value corresponding to each of the one or more actions is received from the action owner. The compliance value is the measure of the conformation to the one or more actions in the administration of the registered risk. The compliance value may be measured in a numerical scale (1 to 10, or 1 to 100), a grade (a,b, c, d, e) and the like.

In the example, the compliance value corresponding to the action “Preparation of

Change management plan (CMP) document” is 50 (on a scale of 1 to 100), and the compliance value corresponding to the action “Execution of change management plan as per CMP document” is 20.

FIG. 16 is flowchart for determining a non-compliance score of the at least one ‘entity, in accordance with an embodiment of the invention. The non-compliance score of an entity is the measure of the inability of the one or more actions to successfully administer the risk. It is determined based on the risk weight of the administered risk, the exposure percentage, and the compliance value corresponding to each of the one or more actions. The non-compliance score may be measured in a numerical value (10, 20, etc.) or as a scale (1 to 10, or 1 to 100, with 1 being the lowest), or a grade (a, b, c, d, e). .

At 1602, a non-compliance score of the at least one entity is determined based on each administered risk and its associated actions for the predefined time period. The non-compliance being determined based on the risk weight corresponding to the at least one administered risk, the exposure percentage, and the compliance value associated with actions of the administered risk.

In accordance with an exemplary embodiment of the invention, the non- compliance score associated with the at least one entity may be determined as: (Z (risk weight associated with each administered risk x the exposure percentage associated with each action x the compliance value corresponding to each of the one or more actions)/Z (risk weight x 100)) x 100 x 0.66 x the co-efficient factor.

Referring to FIGs. 6A—6E, the non-compliance score associated with the entity “banking software” is ((12 x (50/100) x 50 + 12 x (50/100) x 20) / (12 x 100)) x 100 x 0.66 x 0.80 = 18.48FIG. 17 is flowchart for managing the overall risk associated with each context in an organization, in accordance with an embodiment of the invention. Referring to FIGs. 5A and 5B, FIG. 7, FIG. 14, FIGs. 15A and 15B, and FIG. 16, the overall risk associated with each context is managed based on the profiling of each risk associated with at least one entity of one or more entities, generating a visual dashboard for representing each profiled risk, registering each profiled risk associated with the at least one entity, administering each registered risk associated with the at least one entity and determination of the non-compliance score associated with the at least one entity.

At 1702, each risk associated with the at least one entity is profiled. As described earlier in detail with respect to FIGs. 5A and 5B, profiling of a risk is the identification of each risk associated with an entity based on the risk answer corresponding to each of the one or more risk questions. Profiling each risk associated with the at least one entity includes receiving an input corresponding to the one or more risk questions, determining a category risk score, and an entity risk score associated with the at least one entity.

At 1704, a visual dashboard representing each profiled risk is generated. As described earlier in detail with respect to FIGs. 10A-10C, the visual dashboard provides an overall risk picture for business leadership decision making by visually depicting each profiled risk associated with an entity. Generation of the visual dashboard includes generating the change management dashboard for each context, and generating the entity dashboard for the at least one entity. a

At 1706, a detailed description of each profiled risk associated with the at least one entity is registered. As described earlier in detail with respect to FIG. 14, registering is the detailed description of each profiled risk associated with the at least one entity.

Registering includes assigning one or more registered risks to the profiled risk, assigning a risk owner to each of the registered risk, prioritizing each registered risk by assigning each registered risk a risk priority, receiving an exit criterion corresponding to each registered risk, and assigning an effectiveness level to each registered risk.

At 1708, each registered risk associated with the at least one entity is administered. As described earlier in detail with respect to FIGs. 15A and 15B, administration refers to the action steps to reduce each registered risk associated with the entity. Administration includes receiving one or more actions corresponding to each registered risk, receiving a risk response strategy, receiving an exposure percentage, and a due date associated with each registered risk from the risk owner. It further includes assigning an action owner to each registered risk by the risk owner and the receiving of a compliance value from the action owner.

At 1710, a non-compliance score associated with the at least one entity is determined. As described earlier in detail with respect to FIG. 16, the non-compliance score is a measure of the inability of the one or more actions to successfully administer the risk. a

In various embodiments of the invention, the non-compliance score can be shown to the user of a computer system with the help of a generic GUI (not shown in the figure). Further, the one or more categories, the at least one risk question associated with each category, the risk answers, the risk question weight, and the risk answer weight corresponding to each risk answer may be received as input by the user or may be received from a repository. Examples of the repository include, but are not limited to, a database table, an MS Access® file, and an MS Word® file. In various embodiments of the invention, the freeform remark, the lifecycle stage, the ability to recover, the predefined time period, the impact, the risk owner, the risk priority, the exit criterion, the effectiveness level, the one or more actions, the risk response strategy, the exposure percentage, the due date, the action owner, and the compliance value may be received as an input by the user of a computer system with the help of a generic GUI (not shown, in the figure).

FIG. 18 is flowchart for periodically governing the risk and the one or more actions associated with each context, in accordance with an embodiment of the invention. Periodic governance is the regular analysis of the overall risks associated with each context in an organization (IT company) and the one or more actions to administer the risks. - At 1802, the risk associated with each context is analyzed by a cross-functional team of the organization. The cross-functional team is a team comprising employees across multiple departments of the IT company including the IT company’s business units, and risk management experts and senior employees of the IT company with relevant industry experience and expertise.

At 1804, a risk management report is generated based on the analysis of the risk associated with each context by the cross-functional team for the predefined time period.

The risk management report is a detailed periodic report on the risk associated with the plurality of contexts in the IT company. It includes the entity risk score and the entity risk levels associated with the one or more entities in the IT company.

At 1806, at least one sensitive entity of one or more sensitive entities is determined based on the risk management report. A sensitive entity is an entity with a profiled risk/threat which requires periodic monitoring by the senior management of the

IT company. For example, on an entity risk score scale of 1 to 100 with a threshold entity risk score of 30, all entities with entity risk scores greater than 30 are said to be sensitive entities.

Thereafter, at 1808, the at least one sensitive entity is selected for a periodic review. The periodic review may be a weekly or a fortnightly review of the one or more risks associated with the sensitive entity along with the one or more actions associated with the risks and the effectiveness level of the one or more actions in administering the risks by the senior management of the organization.

In an embodiment of the invention, the frequency of periodic review is based on the entity risk level associated with an entity. An entity with higher entity risk level may be periodically reviewed twice as frequently, as compared to another entity with medium entity risk level. :

FIGs. 19A and 19B are flowcharts for updating the PRAC model for managing the overall risk associated with any aspect in the organization, in accordance with an embodiment of the invention. The: PRAC model is based on the evaluation of the risk associated with any aspect in the organization. Therefore, the accuracy of the PRAC model is based on periodic update of the definitions of the plurality of contexts, the one or more entities, the one or. more focus areas, the at least one category, and the one or . more risk questions to accurately determine the risk associated with any aspectinthe organization.

At 1902, the definition of the plurality of contexts in the organization is updated.

Then, at 1904, the definition of the one or more entities associated with each context is updated. At 1906, the definition of the one or more focus areas for each context is updated. Thereafter, at 1908, the definition of the at least one category for each focus area is updated. The definition of the plurality of contexts, the one or more entities, the one or more focus areas, and the at least one category is updated by an expert in the domain of risk management in the organization such as a risk manager, a business leader, and a senior manager.

The successful evaluation of the risks associated with each context in the organization (IT company) is dependent on the inputs provided by the user corresponding to the one or more risk questions. Therefore, the inputs, i.e., the risk answers are reviewed to determine if any of the risk questions was inadequately answered. Accordingly, the identified risk questions are then updated so that the user can correctly provide his or her inputs.

At 1910, the risk answer with indeterminate response is selected from the one or more risk answers corresponding to the at least one risk question by a cross-functional team of the organization. An indeterminate response is a “not applicable” or an unquantifiable or blank response to a risk question. A risk answer with indeterminate response does not provide any resolution to the risks identified correspondingtoa category, thereby implying that the risk question associated with the category needs to be reframed. The cross-functional team is a team comprising employees across all departments of the IT company including the IT company’s business units, and risk management experts and senior employees of the IT company with relevant industry experience and expertise.

At 1912, the at least one risk question corresponding to the selected at least one risk answer is reviewed by the cross-functional team. In this process, the cross- functional team reviews the risk questions to select one or more of those risk questions that need to be updated (i.e., changed, modified, or removed).

At 1914, the at least one risk question corresponding to the selected at least one risk answer is updated by the cross-functional team. The selected risk questions are updated by the cross-functional team by changing/replacing, modifying, or removing the risk questions.

FIG. 20 is a block diagram of a profiling module 2002 for profiling each risk associated with the at least one entity, in accordance with an embodiment of the invention. Profiling module 2002 includes an input receiving module 2004, a change management dashboard attributes receiving module 2006, a category risk score determining module 2008, an entity risk score determining module 2010, a forecast receiving module 2012, an entity risk score updating module 2014, and a storage module 2016. Entity risk score updating module 2014 further includes a change management attributes updating module 2018.

In various embodiments of the invention, the profiling module 2002 profiles each "risk associated with an entity based on an input corresponding to each of one or more risk questions. As explained earlier, in conjunction with FIGs. 5A and 5B, the profiling of each risk includes receiving of an input corresponding to each of the at least one risk question, receiving the one or more change management dashboard attributes associated with the at least one entity, determining a category risk score associated with the at least one category based on the input corresponding to each of the at least one risk question and the change management dashboard attributes, determining an entity risk score based on the entity risk score formula, the category risk score, the one or more change management dashboard attributes, and the non-compliance score associated with the entity in the previous predefined time period, receiving a forecast input corresponding to the entity risk score associated with the at least one entity for a predefined time period, and updating the entity risk score based on the forecast input.

In an embodiment of the invention, input receiving module 2004 receives the input corresponding to each of the at least one risk question. Change management dashboard attributes receiving module 2006 receives the one or more change management dashboard attributes. Thereafter, category risk score determining module 2008 determines the category risk score associated with the at least one category based on the input corresponding to each of the at least one risk question and the change management dashboard attributes, as defined in detail in 506 of FIG. 5A.

Entity risk score determining module 2010 determines the entity risk score based on the entity risk score formula, the category risk score, the one or more change management dashboard attributes, and the non-compliance score associated with the entity in the previous predefined time period, as defined in detail in 508 of FIG. 5A.

Forecast input receiving module 2004 then receives a forecast input corresponding to the entity risk score for a predefined time period, as defined in detail in 510 of FIG. 5B. Entity risk score updating module 2014 updates the entity risk score based on the forecast input. Change management attributes updating module 2018 of entity risk score updating module 2014 then updates the change management dashboard attributes based on the forecast input. Co

Thereafter, the category risk score, the entity risk score, and the updated entity risk score are stored in storage module 2016. In an embodiment of the invention, the category risk score, the entity risk score, and the updated entity risk score can also be shown to a user of a computer system with the help of a generic GUI (not shown in the figure), as may be apparent to a person ordinarily skilled in the art.

In another embodiment of the invention, storage module 2016 stores the input corresponding to the one or more risk questions, the one or more change management dashboard attributes, and the forecast input.

In various embodiments of the invention, input receiving module 2004, change management dashboard attributes receiving module 2006, category risk score determining module 2008, entity risk score determining module 2010, forecast input receiving module 2012, entity risk score updating module 2014, storage module 2016, and change management attributes updating module 2018 of profiling module 2002 can be implemented in the form of hardware, software, firmware, and/or combinations, thereof. :

In various embodiments of the invention, profiling module 2002 utilizes the computational capabilities of a microprocessor of a computational device (not shown in the figure).

FIG. 21 is a block diagram of a visual dashboard module 2102 for generating a visual dashboard representing each profiled risk, in accordance with an embodiment of the invention. Visual dashboard module 2102 includes a change management dashboard module 2104, an entity dashboard module 2106, and a representing module 2108.

In various embodiments of the invention, visual dashboard module 2102 provides the overall risk picture for business leadership decision making by visually depicting each profiled risk associated with an entity. As described earlier, in conjunction with FIG. 7, generation of visual dashboard includes generating the change management dashboard for each context based on the entity risk score and the one or more change management dashboard attributes, generating an entity dashboard for the at least one entity based on each profiled risk and the one or more change management dashboard attributes, representing the plurality of contexts, the at least one entity corresponding to each context, the at least one focus for each context, and the at least one category for each focus area in the visual dashboard. The generation of visual dashboard further includes representing the current risk level, past trends of the risk level, future forecast of the risk level for each entity as attributes for each entity, and representing the risk level of each category within each focus area and the past trend of the risk level.

In an embodiment of the invention, change management dashboard module 2104 generates the change management dashboard for each context based on the entity risk score and the one or more change management dashboard attributes. Entity dashboard module 2106 then generates an entity dashboard for the at least one entity based on each profiled risk and the one or more change management dashboard attributes.

Thereafter, representing module 2108 represents the plurality of contexts, the at least one entity corresponding to each context, the at least one focus area for each context, and the at least one category for each focus area in the visual dashboard. The representing module 2108 then represents attributes for each of the represented the plurality of contexts, the at least one entity corresponding to each context, the at least one focus area for each context, and the at least one category for each focus area.

In an embodiment of the invention, the change management dashboard and the entity dashboard can be presented to a user of a computer system with the help of a generic GUI (not shown in the figure), as may be apparent to a person ordinarily skilled inthe art. g "In various embodiments of the invention, change management dashboard module 2104, entity dashboard module 2106, and representing module 2108 of visual dashboard module 2102 can be implemented in the form of hardware, software, firmware, and/or combinations, thereof. :

In various embodiments of the invention, visual dashboard module 2102 utilizes the computational capabilities of a microprocessor of a computational device (not shown in the figure). :

FIG. 22 is a block diagram of a registering module 2202 for registering each profiled risk associated with the at least one entity, in accordance with an embodiment of the invention. Registering module 2202 includes a risk owner assigning module 2204, a risk priority assigning module 22086, an exit criterion assigning module 2208, an effectiveness level assigning module 2210, and a storage module 2212.

In various embodiments of the invention, registering module 2202 registers each profiled risk based on the detailed description of each profiled risk associated with an entity. As described earlier, in conjunction with FIG. 14, registering each profiled risk includes assigning one or more registered risks, assigning a risk owner to each of the registered risks, prioritizing each registered risks by assigning each registered risk a risk priority, receiving an exit criterion corresponding to each registered risk, and assigning an effectiveness level to each registered risk.

In an embodiment of the invention, risk owner assigning module 2204 assigns a risk owner to each registered risk, the risk owner being an employee of the organization.

Thereafter, risk priority assigning module 2206 assigns a risk priority to each registered risk.

Exit criterion assigning module 2208 then assigns an exit criterion to each registered risk. Thereafter, the effectiveness level assigning module 2210 assigns an effectiveness level to each registered risk.

Thereafter, the risk owner, the risk priority, the exit criterion, and the effectiveness level are stored in storage module 2212. In an embodiment of the invention, the risk owner, the risk priority, the exit criterion, and the effectiveness level can also be presented to a user of a computer system with the help of a generic GUI (not shown in the figure), as may be apparent to a person ordinarily skilled in the art.

In various embodiments of the invention, risk owner assigning module 2204, risk priority assigning module 22086, exit criterion assigning module 2208, effectiveness level assigning module 2210, and storage module 2212 of registering module 2202 can be implemented in the form of hardware, software, firmware, and/or combinations, thereof.

In various embodiments of the invention, registering module 2202 utilizes the computational capabilities of a microprocessor of a computational device (not shown in the figure).

FIG. 23 is a block diagram of an administering module 2302 for administering each registered risk associated with the at least one entity, in accordance with an embodiment of the invention. Administering module 2302 includes a generic receiving module 2304, an action owner assigning module 2306, a compliance receiving module 2308, and a storage module 2310.

In various embodiments of the invention, administering module 2302 administers each registered risk based on the action steps to reduce each registered risk associated with the entity. As described earlier, in conjunction with FIGs. 15A and 15B, administering each registered risk includes receiving one or more actions for administering each registered risk associated with the at least one entity, receiving a risk response strategy corresponding to the one or more actions, receiving an exposure percentage of the one or more actions for administering each registered risk, receiving a due date associated with each action, assigning an action owner associated with each action, and receiving a compliance value corresponding to the one or more actions.

In an embodiment of the invention, generic receiving module 2304 receives one or more actions corresponding to each registered risk associated with the at least one entity, a risk response strategy corresponding to the one or more actions, an exposure percentage corresponding to each action, and a due date associated with each action.

Thereafter, action owner assigning module 2306 assigns an action owner associated with each registered risk. Compliance receiving module 2308 then receives a compliance value corresponding to the one or more actions.

Thereafter, the one or more actions, the risk response strategy, the exposure percentage, the due date, and the compliance value are stored in storage module 2310.

In an embodiment of the invention, the one or more actions, the risk response strategy, the exposure percentage, the due date, and the compliance value can also be presented to a user of a computer system with the help of a generic GUI (not shown in the figure), as may be apparent to a person ordinarily skilled in the art.

In various embodiments of the invention, generic receiving module 2304, action owner assigning module 2306, compliance receiving module 2308, and storage module

2310 of administering module 2302 can be implemented in the form of hardware, software, firmware, and/or combinations, thereof. :

In various embodiments of the invention, administering module 2302 utilizes the computational capabilities of a microprocessor of a computational device (not shown in the figure).

FIG. 24 is a block diagram of a compliance determining module 2402 for determining a non-compliance score of the at least one entity, in accordance with an embodiment of the invention. Compliance determining module 2402 includes a non- compliance score determining module 2404 and a storage module 2406.

In various embodiments of the invention, compliance determining module 2402 + measures the inability of the one or more actions to successfully administer the risk by determining a non-compliance score associated with the at least one entity. As described earlier, in conjunction with FIG. 16, the inability is measured by determininga non-compliance score associated with the at least one entity.

In an embodiment of the invention, non-compliance score determining module 2404 determines a non-compliance score of the at least one entity based on each administered risk and its actions for the predefined time period. The non-compliance is determined based on the risk weight corresponding to the at least one administered risk and the exposure percentage, and the compliance value of the actions of the . administered risk.

Thereafter, the non-compliance score is stored in storage module 2406. In an embodiment of the invention, the non-compliance score can also be shown to a user of a computer system with the help of a generic GUI (not shown in the figure), as may be apparent to a person ordinarily skilled in the art.

In another embodiment of the invention, storage module 2406 stores the risk weight, the exposure percentage, and the compliance value.

In various embodiments of the invention, non-compliance score determining module 2404 and storage module 2406 of compliance determining module 2402 can be implemented in the form of hardware, software, firmware, and/or combinations, thereof.

In various embodiments of the invention, compliance determining module 2402 utilizes the computational capabilities of a microprocessor of a computational device (not shown in the figure).

FIG. 25 is a block diagram of governance module 2502 for periodically governing the risk and the one or more actions associated with each context, in accordance with an embodiment of the invention. Governance module 2502 includes a risk analyzing module 2504, a risk management report generating module 2506, a sensitive entity determining module 2508, and a periodic review module 2510.

In various embodiments of the invention, governance module 2502 periodically governs the risk and the one or more actions associated with each context. As described earlier, in conjunction with FIG. 18, periodic governance is the regular analysis of the overall risks associated with the each context in an organization (IT company) and the one or more actions to administer the risks.

In an embodiment of the invention, risk analyzing module 2504 analyzes the risk associated with the each context. Risk management report generating module 2506 generates a risk management report based on the analysis of the risk associated with the each context. Sensitive entity determining module 2508 then determines at least one sensitive entity of one or more sensitive entities based on the risk management report.

Thereafter, periodic review module 2510 selects the at least one sensitive entity for a periodic review. In an embodiment of the invention, the risk management report, and the at least one sensitive entity can be presented to a user of a computer system with the help of a generic GUI (not shown in the figure), as may be apparent to a person ordinarily skilled in the art.

In various embodiments of the invention, risk analyzing module 2504, risk management report generating module 2506, sensitive entity determining module 2508,

and periodic review module 2510 of governance module 2502 can be implemented in the form of hardware, software, firmware, and/or combinations, thereof.

In various embodiments of the invention, governance module 2502 utilizes the computational capabilities of a microprocessor of a computational device (not shown in the figure). :

FIG. 26 is a block diagram of an updating module 2602 for updating the PRAC model, in accordance with an embodiment of the invention. Updating module 2302 includes a context updating module 2604, an entity updating module 2606, a focus area updating module 2608, a category updating module 2610, a risk questions module 2612, and a storage module 2614.

In various embodiments of the invention, updating module 2602 updates the

PRAC model for managing the overall risk associated with any aspect in an organization. As described earlier in conjunction with FIGs. 19A and 19B, the accuracy of the PRAC model is based on periodic update of the definitions of the plurality of contexts, the one or more entities, the one or more focus areas, and the at least one category to accurately determine the risk associated with any aspect in the organization. . In an embodiment of the invention, context updating module 2604 updates the definition of the plurality of contexts in the organization. Entity updating module 2606 updates the definition of the one or more entities associated with the each context.

Focus area updating module 2608 updates the definition of the one or more focus areas for the each context. Category updating module 2610 updates the definition of the at least one category for each focus area.

Risk questions module 2612 selects a risk answer with indeterminate response from the one or more risk answers corresponding to the at least one risk question. Risk questions module 2612 then reviews the at least one risk question corresponding to the selected at least one risk answer. Further, risk questions module 2612 updates the at least one risk question corresponding to the selected at least one risk answer.

Thereafter, the updated definitions of the plurality of contexts, the one or more entities, the one or more focus areas, the at least one category, and the updated plurality of risk questions are stored in storage module 2614. In an embodiment of the invention, the updated definitions of the plurality of contexts, the one or more entities, the one or more focus areas, the at least one category, and the updated plurality of risk questions can also be presented to a user of a computer system with the help of a generic GUI (not shown in the figure), as may be apparent to a person ordinarily skilled in the art.

In various embodiments of the invention, context updating module 2604, entity updating module 2606, focus area updating module 2608, category updating module 2610, risk questions module 2612, and storage module 2614 of updating module 2602 can be implemented in the form of hardware, software, firmware, and/or combinations, thereof.

In various embodiments of the invention, updating module 2602 utilizes the computational capabilities of a microprocessor of a computational device (not shown in the figure).

FIG. 27 is a block diagram of PRAC model 2702 for managing the overall risk associated with the each context in an organization, in accordance with another embodiment of the invention. PRAC model 2702 includes a definition module 2704, profiling module 2002, visual dashboard module 2102, registering module 2202, administering module 2302, compliance determining module 2402, governance module 2502, updating module 2603, and an overall storage module 2706.

In various embodiments of the invention, PRAC model 2702 manages the overall risk associated with the each context. In an embodiment of the invention, definition module 2704 defines the plurality of contexts in the organization, the at least one entity associated with each context, the at least one focus area for each context, the one or more change management dashboard attributes, the at least one category for each focus area, the plurality of risk questions, and the entity risk score formula. Profiling module 2002 profiles each risk associated with at the least one entity of one or more entities, as described in detail with respect to FIG. 20. Visual dashboard module 2102 generates a visual dashboard representing each profiled risk, as described in detail with respect to FIG. 21. Registering module 2202 then registers each profiled risk associated with the at least one entity, as described in detail with respect to FIG. 22. Thereafter, administering module 2302 administers each registered risk associated with the at least one entity, as described in detail with respect to FIG. 23. Compliance determining module 2402 then determines a non-compliance score associated with the at least one entity, as described in detail with respect to FIG. 24. Governance module 2502 periodically governs the risk and the one or more actions associated with each context, as described earlier in detail with respect to FIG. 25. Updating module 2602 then updates the PRAC model, as described earlier in detail with respect to FIG. 26.

Thereafter, each profiled risk, each registered risk and the non-compliance score are stored in overall storage module 2706. In an embodiment of the invention, each profiled risk, each registered risk, and the non-compliance score can also be presented to a user of a computer system with the help of a generic GUI (not shown in the figure), as may be apparent to a person ordinarily skilled in the art.

In various embodiments of the invention, definition module 2704, profiling module 2002, visual dashboard module 2102, registering module 2202, administering module 2302, compliance determining module 2402, governance module 2502, updating module 2602, and overall storage module 2706 of PRAC model 2702 can be implemented in the form of hardware, software, firmware, and/or combinations, thereof.

In various embodiments of the invention, PRAC model 2702 utilizes the computational capabilities of a microprocessor of a computational device (not shown in the figure).

The method, the system, and the computer program product described above have a number of advantages. The method enables the management of the overall risk associated with the each context in the organization, where one or more focus areas are associated with the each context. Such a determination ensures that the determined category risk score and the entity risk score are accurate and reliable. Also, such determination of the category risk score and the entity risk score is an efficient and less error-prone process. Further, such a method helps the organization to accurately forecast the overall risk associated with the each context in the organization for a long period of time. The risk is calculated by identifying the one or more entities with the risk score greater than a minimum or threshold risk level. The method allows the organization to take steps to administer the risks associated with each of the identified ~ one or more entities. The method also enables the determination of risk at various levels in the organization, such as at the business unit level, focus area level, entity level, etc.

The method and system for managing the overall risk associated with any aspect in an organization, as described in the present invention, may be embodied in the form of a computer system. Typical examples of a computer system include a general- purpose computer, a programmed microprocessor, a micro-controller, a peripheral integrated circuit element, and other devices or arrangements of devices that are capable of implementing the steps that constitute the method for the present invention.

The computer system typically comprises a computer, an input device, and a display unit. The computer typically comprises a microprocessor, which is connected to a communication bus. The computer also includes a memory, which may include a

Random Access Memory (RAM) and a Read Only Memory (ROM). Further, the computer system comprises a storage device, which can be a hard disk drive or a removable storage drive such as a floppy disk drive and an optical disk drive. The storage device can be other similar means for loading computer programs or other instructions into the computer system. CL

The computer system executes instructions that are stored in one or more storage elements to process input data. These storage elements can also hold data or other information, as desired, and may be in the form of an information source or a . physical memory element present in the processing machine. Exemplary storage elements include a hard disk, a DRAM, an SRAM, and an EPROM. The storage element may be external to the computer system and connected to or inserted into the computer, to be downloaded at-or prior to the time of use. Examples of such external computer program products are computer-readable storage mediums such as CD-ROMS, flash chips, and floppy disks.

The instruction means may include various commands that instruct the processing machine to perform specific tasks such as the steps that constitute the method for the present invention. The instruction means may be in the form of a ‘software program or a computer readable program code embodying the method in a computer usable medium. The software may be in various forms such as system software or application software. Further, the software may be in the form of a collection of separate programs, a program module with a large program, or a portion of a program module. The software may also include modular programming in the form of object- oriented programming. The software program that contains the instructions can be embedded in a computer program product for use with a computer. The computer program product comprises a computer-usable medium with a computer-readable program code embodied therein. The processing of input data by the processing machine may be in response to users’ commands, results of previous processing, or a request made by another processing machine.

The modules described herein may include processors and program instructions that are used to implement the functions of the modules described herein. Some or all the functions can be implemented by a state machine that has no stored program instructions, or in one or more Application-Specific Integrated Circuits (ASICs), in which each function or some combinations of some of the functions are implemented as custom logic.

While the various embodiments of the invention have been illustrated and described, it will be clear that the invention is not limited only to these embodiments.

Numerous modifications, changes, variations, substitutions, and equivalents will be apparent to those skilled in the art, without departing from the spirit and scope of the invention.

Claims

Claims: What is claimed is:

1. A method for managing the overall risk associated with any aspect in an organization using a PRAC model, the PRAC model being a framework defining the method and parameters for managing the risk associated with any aspect in an organization, the method comprising:

a. defining the PRAC model, the defining comprising:

i. defining a plurality of contexts in the organization, wherein each context of the plurality of contexts is a one of business unit in the organization, a strategic initiative in a business unit, and a strategic unit in the organization; :

i. defining at least one entity associated with each context, wherein an entity is one of a project, a program, a strategic initiative, an operational interest, a financial interest, a legal interest and a business interest in the organization;

ii. defining at least one focus area for each context, wherein each focus area is a group of one or more entities of a particular type;

iv. defining one or more change management dashboard attributes for the at least one focus area, wherein the change management dashboard attributes are the attributes used in the graphical depiction of the risk associated with the at least one entity;

v. defining at least one category for each focus area, wherein the category is an aspect on which the at least one entity associated with the at least one focus area is evaluated to identify if there is any risk associated with that aspect of the at least one entity;

vi. defining a plurality of risk questions for the at least one category to assess the risk associated with the at least one entity corresponding to the at least one category, wherein each of the plurality of risk questions is associated with the at least one category, wherein each risk question is defined based on the tacit knowledge of the entity, the focus area, the context and the organization, on which each entity associated with a focus area is evaluated; and vii. defining an entity risk score formula, wherein the entity risk score formula is used to determine the risk associated with the at least one : entity;

b. profiling each risk associated with the at least one entity, profiling being the identification of the risk associated with the entity, wherein profiling each - risk comprises:

i. receiving an input corresponding to each of the at least one risk question, the input being received for a predefined time period, the input being at least one of a risk answer, a freeform remark and a generic input;

ii. receiving one or more change management dashboard attributes associated with the at least one entity;

iii. determining a category risk score and category risk level, based on the input corresponding to each of the at least one risk question of the entity, associated with the category, and the one or more change management dashboard attributes;

iv. determining an entity risk score and entity risk level associated with the at least one entity based on the input corresponding to each of the at least one risk question associated with entity and the one or more change management dashboard attributes;

v. receiving a forecast input corresponding to the entity risk level associated with the at least one entity, the forecast input being received for the predefined time period; and vi. updating the entity risk score and entity risk level based on the forecast input;

c. generating a visual dashboard representing each profiled risk for each entity associated with the at least one focus area, the at least one focus area being associated with each context, wherein the visual dashboard provides an overall risk picture for business leadership decision making, the generation of visual dashboard comprising: oo

“i. generating a change management dashboard for each context; and ii. generating a entity dashboard for the at least one entity;

d. registering each profiled risk, the registering of each profiled risk comprising:

i. assigning a one or more registered risks to each profiled risk and assigning a risk owner to each registered risk;

ii. assigning a risk priority to each registered risk; | Co iii. assigning an exit criterion corresponding to each registered risk; and iv. assigning an effectiveness level to each registered risk;

e. administering each registered risk, the administering each registered risk comprising:

i. receiving

1. one or more actions for administering each registered risk associated with the at least one entity;

2. arisk response strategy corresponding to the one or more actions;

3. a exposure percentage of the one or more actions for administering each registered risk; and

4. a due date associated with each action;

ii. assigning an action owner associated with each action; and iii. receiving a compliance value corresponding to each of the one or more actions from the action owner, the compliance value being the measure of the degree to which the oné or more actions are successful in administering the registered risk;

f. determining a non-compliance score of the at least one entity based on each administered risk and its associated actions for the predefined time period, the non-compliance score being determined based on the risk weight corresponding to the at least one administered risk, the exposure percentage, and the compliance value associated with actions of the administered risk; and g. periodically governing the risk and the one or more actions associated with - each context, periodically governing the risk and one and more actions “associated with each context further comprising:

i. analyzing the risk associated with each context, the risk being ~ analyzed by a cross-functional team of the organization;

ii. generating a risk management report based on the analysis of the risk associated with each context, the risk management report being generated by the cross-functional team for the predefined time period; oo ii. determining at least one sensitive entity of one or more sensitive entities based on the risk management report; and iv. selecting the at least one sensitive entity for a periodic review.

2. The method according to claim 1, wherein generating the visual dashboard further comprises:

a. representing the plurality of contexts, the at least one entity corresponding to each context, the at least one focus area for each context, and the at least one category for each focus area in the visual dashboard; and b. representing attributes for each of the represented the plurality of contexts, the at least one entity corresponding to each context, the at least one focus area for each context, and the at least one category for each focus area, wherein representing attributes comprises:

i. representing the current risk level, past trends of the risk level, future forecast of the risk level, for each entity as attributes for each entity; and ii. representing the current category risk pattern of each category within each focus area and the past trend of the category risk pattern for each category.

3. The method according to claim 1, wherein updating the entity risk score further comprises updating the one or more change management dashboard attributes based on the forecast input.

4. The method according to claim 1 further comprising updating the PRAC model for managing the overall risk associated with any aspect in an organization, the updating of the PRAC model comprising updating:

a. the definition of the plurality of contexts in the organization;

b. the definition of the one or more entities associated with each context;

c¢. the definition of the one or more focus areas for each context;

d. the definition of the at least one category for each focus area; and oo 58 e. the plurality of risk questions, the updating of the plurality of risk questions comprising:

i. selecting a risk answer with indeterminate response;

ii. reviewing the at least one risk question corresponding to the selected risk answer; and © iii. updating the at least one risk question corresponding to the selected risk answer.

5. A PRAC model for managing the overall risk in an organization, the PRAC model being a framework defining the method and parameters for managing the risk associated with any aspect in an organization, the PRAC model comprising:

a. a definition module configured for defining the PRAC model, the definition . module comprising:

"i. definition of a plurality of contexts in the organization, wherein each context of the plurality of contexts is a one of business unit in the organization, a strategic initiative in a business unit, and a strategic unit in the organization;

ii. definition of at least one entity associated with each context, wherein an entity is one of a project, a program, a strategic initiative, an operational interest, a financial interest, a legal interest and a business interest in the organization;

ii. definition of at least one focus area for each context, wherein each focus area is a group of one or more entities of a particular type;

iv. definition of one or more change management dashboard attributes : for the at least one focus area, wherein the change management dashboard attributes are the attributes used in the graphical depiction of the risk associated with the at least one entity;

v. definition of at least one category for each focus area, wherein the category is an aspect on which the at least one entity associated with the at least one focus area is evaluated to identify if there is any risk associated with that aspect of the at least one entity;

vi. definition of a plurality of risk questions for the at least one category to assess the risk associated with the at least one entity corresponding to the at least one category, wherein each of the : plurality of risk questions is associated with the at least one category, wherein each risk question is defined based on the tacit knowledge of the entity, the focus area, the context and the : organization, on which each entity associated with a focus area is evaluated; and vii. definition of an entity risk score formula, wherein the entity risk score . formula is used to determine the risk associated with the at least one entity;

b. a profiling module configured for profiling each risk associated with the at least one entity, profiling being the identification of the risk associated with the entity, the profiling module comprises:

i. an input receiving module configured for receiving an input corresponding to each of the at least one risk question, the input being received for a predefined time period, the input being at least one of a risk answer, a freeform remark, and a generic input; :

ii. a change management dashboard attributes receiving module configured for receiving one or more change management dashboard attributes associated with the at least one entity;

ii. a category risk score determining module configured for determining a category risk score and category risk level, based on the input corresponding to each of the at least one risk question of the entity,

associated with the category, and the one or more change- management dashboard attributes;

iv. an entity risk score determining module configured for determining : an entity risk score and entity risk level, associated with the at least one entity, based on the input corresponding to each of the at least one risk question associated with entity and the one or more change management dashboard attributes;

v. a forecast receiving module configured for receiving a forecast input corresponding to the entity risk level associated with the at least one entity, the forecast input being received for the predefined time period;

vi. an entity risk score updating module configured for updating the entity risk score and entity risk level based on the forecast input; and vii. a storage module configured for storing the category risk score, category risk level, the entity risk score, entity risk level and the forecast input;

c. a visual dashboard module configured for generating a visual dashboard representing each profiled risk for each entity associated with the at least one focus area, the at least one focus area being associated with each context, wherein the visual dashboard provides an overall risk picture for business leadership decision making, the visual dashboard comprising:

i. a change management dashboard module configured for generating a change management dashboard for each context; and ii. a entity dashboard module configured for generating a entity dashboard for the at least one entity;

~~ d. aregistering module configured for registering each profiled risk, the registering module comprising:

i. one or more registered risks to each profiled risk and assigning a risk owner assigning module configured for assigning a risk owner to each registered risk;

ii. arisk priority assigning module configured for assigning a risk - priority to each registered risk;

: . iii. an exit criterion assigning module configured for assigning an exit criterion corresponding to each registered risk;

iv. an effectiveness level assigning module configured for assigning an effectiveness level to each registered risk; and v. a storage module configured for storing the risk owner, the risk priority, the exit criterion, and the effectiveness level;

e. an administering module configured for administering each registered risk, the administering module comprising:

: i. a generic receiving module configured for receiving:

1. one or more actions for administering each registered risk associated with the at least oné entity;

2. a risk response strategy corresponding to the one or more : actions;

: 4. a due date associated with each action;

ii. an action owner assigning module configured for assigning an action owner associated with each action;

iii. a compliance receiving module configured for receiving a - compliance value corresponding to each of the one or more actions from the action owner, , the compliance value being the measure of the degree to which the one or more actions are successful in administering the registered risk; and :

iv. a storage module configured for storing the one or more actions, the risk response strategy, the exposure percentage, the due date, and the compliance value;

f. a compliance determining module configured for determining a non- compliance score of the at least one entity based on each administered risk and its associated actions for the predefined time period, the non- oo compliance score being determined based on the risk weight corresponding to the at least one administered risk, the exposure percentage, and the compliance value associated with actions of the administered risk; and g. a governance module configured for periodically governing the risk and the one or more actions associated with each context, the governance module comprising:

i. arisk analyzing module configured for analyzing the risk associated with context, the risk being analyzed by a cross-functional team of the organization;

ii. a risk management report generating module configured for generating a risk management report based on the analysis of the risk associated with each context, the risk management report being generated by the cross-functional team for the predefined time period; : :

ii. a sensitive entity determining module configured for determining at least one sensitive entity of one or more sensitive entities based on the risk management report; and iv. a periodic review module configured for selecting the at least one sensitive entity for a periodic review.

6. The PRAC model according to claim 5, wherein the visual dashboard module further comprises:

a. a representing module configured for:

i. representing the plurality of contexts, the at least one entity corresponding to each context, the at least one focus area for each context, and the at least one category for each focus area in the visual dashboard;

ii. representing attributes for each of the represented the plurality of : contexts, the at least one entity corresponding to each context, the at least one focus area for each context, and the at least one category for each focus area, wherein representing attributes comprises:

1. representing the current risk level, past trends of the risk level, future forecast of the risk level, for each entity as attributes for each entity; and

2. representing the current category risk pattern of each category within each focus area and the past trend of the category risk pattern for each category.

7. The PRAC model according to claim 5, wherein the entity risk score updating module further comprises a change management attributes updating module configured for updating the one or more change management dashboard attributes based on the forecast input.

8. The PRAC model according to claim 5 further comprising an updating module configured for updating the PRAC model for managing the overall risk associated with any aspect in an organization, the updating module comprises:

a. a context updating module configured for updating the definition of the plurality of contexts in the organization;

b. an entity updating module configured for updating the definition of the one or more entities associated with each context;

c. a focus area updating module configured for updating the definition of the one or more focus areas for each context;

d. a category updating module configured for updating the definition of the at least one category for each focus area;

e. arisk questions module configured for updating the plurality of risk questions, the updating of the plurality of risk questions comprising:

i. selecting a risk answer with indeterminate response;

ii. reviewing the at least one risk question corresponding to the selected risk answer; and _ iii. updating the at least one risk question corresponding to the selected oo risk answer;

: f. a storage module configured for storing the updated definitions of the plurality of contexts, the one or more entities, the one or more focus areas, the at least one category, and the updated plurality of risk questions.

9. A computer program product for use with a computer, the computer program product comprising a computer usable medium having a computer readable program code embodied therein for managing the overall risk associated with any aspect in an organization using a PRAC model, the PRAC model beinga framework defining the method and parameters for managing the risk associated with any aspect in an organization, the computer readable program code comprising:

a. a program instruction means for defining the PRAC model, the program instruction means for defining comprising:

i. a program instruction means for defining a plurality of contexts in the organization, wherein each context of the plurality of contexts is a one of business unit in the organization, a strategic initiative in a business unit, and a strategic unit in the organization;

ii. a program instruction means for defining at least one entity associated with each context, wherein an entity is one of a project, a program, a strategic initiative, an operational interest, a financial interest, a legal interest and a business interest in the organization;

iii. a program instruction means for defining at least one focus area for each context, wherein each focus area is a group of one or more : entities of a particular type;

iv. a program instruction means for defining one or more change management dashboard attributes for the at least one focus area, wherein the change management dashboard attributes are the ~ attributes used in the graphical depiction of the risk associated with the at least one entity; }

v. a program instruction means for defining at least one category for each focus area, wherein the category is an aspect on which the at least one entity associated with the at least one focus area is evaluated to identify if there is any risk associated with that aspect of the at least one entity;

vi. a program instruction means for defining a plurality of risk questions for the at least one category to assess the risk associated with the at least one entity corresponding to the at least one category, wherein each of the plurality of risk questions is associated with the at least one category, wherein each risk question is defined based on the : tacit knowledge of the entity, the focus area, the context and the organization, on which each entity associated with a focus area is evaluated; and vii. a program instruction means for defining an entity risk score formula, : wherein the entity risk score formula is used to determine the risk associated with the at least one entity;

b. a program instruction means for profiling each risk associated with the at least one entity, profiling being the identification of the risk associated with t the entity, wherein the program instruction means for profiling each risk comprises:

: i. a program instruction means for receiving an input corresponding to each of the at least one risk question, the input being received for a predefined time period, the input being at least one of a risk answer, a freeform remark, and a generic input;

ii. a program instruction means for receiving one or more change a management dashboard attributes associated with the at least one entity; :

iii. a program instruction means for determining a category risk score and category risk level, based on the input corresponding to each of the at least one risk question of the entity, associated with the category, and the one or more change management dashboard attributes;

iv. a program instruction means for determining an entity risk score and entity risk level, based on the input corresponding to each of the at least one risk question associated with entity and the one or more change management dashboard attributes;

v. a program instruction means for receiving a forecast input : corresponding to the entity risk level associated with the at least one entity, the forecast input being received for the predefined time period; and

‘vi. a program instruction means for updating the entity risk score and entity risk level based on the forecast input;

c. a program instruction means for generating a visual dashboard representing each profiled risk for each entity associated with the at least one focus area, the at least one focus area being associated with each context, wherein the visual dashboard provides an overall risk picture for business leadership decision making, the program instruction means for generation of visual dashboard comprising:

i. aprogram instruction means for generating a change management dashboard for each context; and i. a program instruction means for generating a entity dashboard for the at least one entity;

d. a program instruction means for registering each profiled risk, the program instruction means for registering of each profiled risk comprising:

i. a program instruction means for assigning one or more registered risks to each profiled risk and assigning a risk owner to each registered risk;

ii. a program instruction means for assigning a risk priority to each registered risk;

. iii. a program instruction means for assigning an exit criterion corresponding to each registered risk; and iv. a program instruction means for assigning an effectiveness level to each registered risk.

e. a program instruction means for administering each registered risk, the program instruction means for administering each registered risk comprising:

i. a program instruction means for receiving:

2. arisk response strategy corresponding to the one or more : actions;

4. a due date associated with each action;

ii. a program instruction means for assigning an action owner ~ associated with each action; and ) iii. a program instruction means for receiving a compliance value corresponding to each of the one or more actions from the action owner, the compliance value being the measure of the degree to which the one or more actions are successful in administering the registered risk;

f. a program instruction means for determining a non-compliance score of ’ the at least one entity based on administered risk and its associated actions for the predefined time period, the non-compliance score being determined based on the risk weight corresponding to the at least one administered risk, the exposure percentage, and the compliance value associated with actions of the administered risk; and g. a program instruction means for periodically governing the risk and the one oo or more actions associated with each context, the program instruction means for periodically governing the risk and one and more actions associated with each context further comprising: I program instruction means for analyzing the risk associated with context, the risk being analyzed by a cross-functional team of the organization;

ii. a program instruction means for generating a risk management report based on the analysis of the risk associated with each context, the risk management report being generated by the cross-functional team for the predefined time period,

iii. a program instruction means for determining at least one sensitive entity of one or more sensitive entities based on the risk management report; and iv. a program instruction means for selecting the at least one sensitive entity for a periodic review.

10. The computer program product according to claim 9, wherein the program instruction means for generating the visual dashboard further comprises:

a. a program instruction means for representing the plurality of contexts, the at least one entity corresponding to each context, the at least one focus area for each context, and the at least one category for each focus area in the visual dashboard;

b. a program instruction means for representing attributes for each of the represented the plurality of contexts, the at least one entity corresponding to each context, the at least one focus area for each context, and the at least one category for each focus area, wherein representing attributes comprises:

i. a program instruction means for representing the current risk level, past trends of the risk level, future forecast of the risk level, for each entity as attributes for each entity; and ii. a program instruction means for representing the current category risk pattern of each category within each focus area and the past trend of the category risk pattern for each category.

11. The computer program product according to claim 9, wherein the program instruction means for updating the entity risk score further comprises a program instruction means for updating the one or more change management dashboard oo attributes based on the forecast input.

12. The computer program product according to claim 9 further comprising a program instruction means for updating the PRAC model for managing the overall risk associated with any aspect in an organization, the program instruction means for updating of the PRAC model comprising:

a. a program instructions means for updating the definition of the plurality of contexts in the organization;

b. a program instructions means for updating the definition of the one or more entities associated with each context;

c. a program instructions means for updating the definition of the one or more focus areas for each context;

d. a program instructions means for updating the definition of the at least one category for each focus area; and :

e. a program instructions means for updating the plurality of risk questions, the program instructions means for updating of the plurality of risk questions comprising:

i. a program instructions means for selecting a risk answer with indeterminate response; .

ii. a program instructions means for reviewing the at least one risk question corresponding to the selected risk answer; and iii. a program instructions means for updating the at least one risk question corresponding to the selected risk answer.