Using Risk and Risk Action work items in Rational Team Concert

Centralized, collaborative risk management made (almost) easy


Overview of using Rational Team Concert to manage risks

IBM® Rational Team Concert™ is a collaborative change management tool. You can use it to create multiple project areas, with each catering to the needs of the project. Multiple process templates are included, and project teams can choose the one to use in a project area, based on the team's needs.

The Formal Project Management process template is for change control management, and it is also helpful in managing project risks. The sections that follow explain how to use this template.

Be sure to see the short summary of the benefits of using Rational Team Concert for risk management in your software development projects.

Managing risks related to projects

Every project and its related activities are surrounded by risks. Each risk involves two fundamental concerns:

  • The probability of occurrence
  • The impact that results if the risk occurs

The biggest risk involved with risk management is realizing, at the right time, that the risk exists. You cannot always avoid or overcome risks, but you can prepare for them. The strategy to prepare for a risk is to identify it and then plan for avoidance, mitigation, and contingencies. This makes risk management an integral part of project management.

Figure 1. Workflow diagram of project risk management
Risk Assessment, Risk Control
Risk Assessment, Risk Control

Project risk management

Risk Management is a two-stage process that involves risk assessment and risk control, each with related actions:

  • Risk assessment
    • Risk identification
    • Risk analysis
    • Risk prioritization
  • Risk control
    • Risk strategy
    • Risk action
    • Risk control

Risk assessment

Risk assessment means identifying and analyzing risks in any project. You need to assess risks as early as possible in the project lifecycle but also consider that projects are dynamic and the dynamic nature of projects always leads to new risks. Therefore, risk assessment is not a one-time process. You need to do this regularly throughout the entire lifecycle of the project.

Risk identification

Risk assessment starts with risk identification, and that starts by identifying the uncertainties in a project. Review the entire project plan to identify the activities that could lead to uncertain or undesirable results. Then capture these uncertainties for analysis.

Risk analysis

After you identify a risk, you can analyze it according to various parameters to understand the risk better:

  • Impact of an occurrence
  • Probability of occurrence
  • Precision (accuracy) level of the risk identified
  • Probable cost of the risk as estimated loss incurred if the event occurs
  • Tentative occurrence date of the identified risk

Risk prioritization

Based on the analysis, you can establish priorities for risk control actions. Not all identified risks can be controlled immediately, thus the need for prioritization. High-priority risks have the potential for the most negative impact.

Risk control

Based on the prioritization, you can plan risk control actions. Planning helps identify the strategy and actions to take for risk control and then to track the risk to closure. Risk control is a lengthy action that requires time for strategy planning and related actions.

Risk strategy

Based on the risk assessment, you can choose the strategy to avoid, mitigate, or prepare a contingency plan for any risk. The risk manager might choose to implement all or part of the strategies, which fall into three basic categories:

  • Avoidance: What are the actions that we should take to avoid the occurrence of the situation identified as a risk?
  • Mitigation: What are the actions that can be taken to decrease the seriousness (impact) of that risk?
  • Contingency: If the situation occurs, what are the steps to take to recover?

Risk action

After you have chosen the strategy, you can implement the related actions. The risk manager might implement multiple actions, using the same strategy for particular risks.

Risk closure

When a risk is no longer valid in the context of the project, you can close the risk. However, until it is closed, continue through the cycle of assessment and control.

Lifecycle of a risk

A risk lifecycle spans from risk identification through risk control to risk closure.

For a software project, risk is present from its initiation until deployment and support. However, a particular risk might have a different lifecycle, because a risk identified at project initiation might not be valid until deployment. The lifecycle depends on the risk identified. For example, not starting the project on the proposed start date is a risk, but if project starts on the proposed date, that risk no longer holds. However, the risk of incorrect requirements holds until the end of the project.

Using Rational Team Concert for risk management

The Formal Project Management process template in Rational Team Concert provides Risk and Risk Action work items for risk management. The following subsections give you a brief overview of Risk work items, with an example.

Risk work item

After a risk is identified, it is recorded by using the Risk work item in Rational Team Concert. Here, we will use an example of incorrect requirement for understanding this work item and its attributes. Figure 2 shows the Overview tab view, which includes a summary, description, and details.

Figure 2. Overview tab layout for Risk work item
UI for Risk work item, Overview tab
UI for Risk work item, Overview tab

Notice that the Risk work item has multiple attributes related to the risk, in addition to several default attributes:

This text description gives the project team members an idea of the nature of the risk. In the context of our example of incorrect requirements, summary would say "Incorrect Requirements."
Details of the risk can be elaborated here. Text can be added, edited, and deleted.
This area contains comments from project team members. Comments cannot be edited after they are saved.
Because it is a Risk work item, this remains as a risk type.
Creation Date
This entry cannot be edited. It refers to the date when this work item was created.
Created By
This entry cannot be edited. It refers to the creator of this work item.
Project Area
This entry cannot be edited. It refers to the project area with which this risk is associated.
Team Area
This entry cannot be edited. It refers to the team that is working on this risk.
Filed Against
Here, you can choose associate the risk with a project. This helps in tracking the risks related to a project.
This area is used for tags to help make searching a collection of risks easier. Examples of tags: requirement missing, requirement incorrect
Owned By
This is for recording the owner of each risk. This is the person to go for any related actions.
Based on the importance of the risk, how soon it should be closed is tracked by priority. For incorrect requirements, the priority would be High, because we would need to handle the problem as soon as possible to avoid building an incorrect product.
Identified For
This is for recording the phase of the project plan where this work item (risk) is scheduled. The Incorrect Requirement risk is in the Requirement part of the plan.
This captures the likelihood of the situation occurring that this risk identifies. For example, if the requirements analyst on the team is new in the role or new on the project, the chances are higher. But if that person is experienced, the probability is lower.
This entry is to estimate the impact, or effects, if the situation identified in the risk occurs. As an example, if incorrect requirements are written, the impact on the product could be huge, because it could lead to development of an unacceptable product.
This entry cannot be edited. Exposure is calculated by multiplying probability and impact percentages and then dividing by 100. The higher the number, the more vulnerable we are to this risk, and the lower the number, the safer it is.
Matrix represents which area in the specific risk is in, with the probability and impact identified. The green cells show the quadrants where risk is low, orange represents medium risks, and red is for high risks. The quadrant where one is gets highlighted with L (Low), M (Medium), H (High). You can also define the probability and impact by selecting a cell in the matrix.
This attribute is used to indicate the accuracy of the risk prediction. This depends on the level that the risk is understood in relation to the project.
Consequence Cost
Record the estimated financial cost of the risk here. Default value is USD, but you can change it to another currency by using project area editor.
Probable Cost
This entry cannot be edited. It gets populated by the calculation of consequence cost multiplied by probability of risk.
Risk Category
This indicates the category to which risk belongs, and you can choose from the options. For Incorrect requirements, the category could be Technology, because requirements are related to technology.
Identification Date
This attribute is used to record the date when this risk was identified.
Occurrence Date
This attribute is to record the tentative date when this risk is most likely to occur.
This tracks the current state of the risk. If a new risk is identified, the status is "New." The risk then needs to be validated, so the state of the work item is "To be validated." The risk in then validated regarding its probability of occurrence. If the risk is deemed valid, it is accepted, and the status is changed to In Progress to work on it. Work is then done to mitigate the risk or close it. If the risk is closed, a substate is chosen, and it mentions the action taken for risk closure. The defaults actions options for closures are Avoid, Mitigate, Invalid, Accepted, or Transferred.

If a risk identified is expected to reoccur, the same Risk work item is reopened.

Risk Action work item

You can use the Rational Team Concert Risk Action work item to track the planned or completed risk actions for any identified risk. This work item is similar to other work items in Rational Team Concert, with a few extra attributes, which the following subsections explain.

Figure 3. Overview tab layout for Risk Action work item
UI for Risk Action work item, Overview tab
UI for Risk Action work item, Overview tab
This would be the same or similar to the Risk work item. By reading the summary, people should be able to understand which risk relates to this action.
Strategy Type
Options listed are Avoidance, Mitigation, and Contingency. Each is an independent strategy and has its own relevance. Based on the action for an identified risk, separate work items are open, and they are associated with a Risk work item. You can choose different strategies based on the risk identified.
This strategy is chosen as an action when risk avoidance needs to be planned. In this strategy, action items are planned so that risk can be avoided and it does not occur. Here, in the example of the Incorrect Requirement risk, an avoidance measure could be to ensure that the requirements analyst is experienced.
This strategy is chosen as an action when risk mitigation needs to be planned. In this strategy, action items are planned so that, if the risk event occurs, the actions to take to decrease the impact are clear. A mitigation plan for the Incorrect Requirement risk could be more thorough, comprehensive reviews of the requirements by the stakeholders, architects, and designers before requirements are passed on for design and development (specified by who does what and when).
This strategy is chosen as an action when risk contingency needs to be planned. In this strategy, action items are planned so that, if the risk even occurs, actions to take to recover from it are clear. For the Incorrect Requirement risk, a contingency plan could be that we schedule regular, interim demos of the product being developed until it is fully developed.
Constraint Type
This is a drop-down listing with options that include As Soon As Possible, Start No Earlier Than, and so forth. These are used to record what constraint is governing this Risk work item and how soon action on it needs to be started or finished. For Incorrect Requirements, considering the impact of this risk of building an incorrect product, the preferred choice would be As Soon As Possible.
Constraint Date
The date recorded for this attribute is related to the Constraint Type field. This date signifies the date that the action plan should become effective or end. For Incorrect Requirements, this would be a date in the Requirements phase, because if this risk continues beyond stage, it would be difficult to contain.
The state tracks the current state of the risk action. For a new risk action, state is New. When these actions are ready to be assigned priorities and actions, the work item state becomes Triage. Then, when you start working on the item, the work item state changes to In Progress. After the work related to the risk action is finished, the state needs to be changed to Resolved. When it is in the Resolved state, you can choose to Verify, Reopen, or Close the work item.

Other tabs in Risk and Risk Action work items

Links tab
Both the Risk and Risk Action work items include this tab, which is where you can make links to related risk, actions, and other work items. You can also upload files related to the work item here. A list of subscribers to this work item is also maintained by using this tab.
Figure 4. Links tab layout for Risk and Risk Action work items
UI for Risk and Risk Action, Links tab
UI for Risk and Risk Action, Links tab
Approval tab
This tab is in both Risk and Risk Action work items. Using this, you can control the transition of states of the risk, which helps in adhering to the project process. For example, only an Approved risk can be closed.
Figure 5. Approval tab layout for Risk and Risk Action work items
UI for Risk and Risk Action, Approvals tab
UI for Risk and Risk Action, Approvals tab
History tab
Both Risk and Risk Action work items include this tab. It records all of the actions performed in work items. You can use this tab to track any past action on the work item.
Figure 6. History tab layout for Risk and Risk Action work items
UI for Risk and Risk Action, History tab
UI for Risk and Risk Action, History tab
Time Tracking tab
This tab is in the Risk Action work item only. It records the time spent by the owner on the work item in terms of hours invested each day. The owner of the work item may edit and delete the time entries.
Figure 7. Time Tracking tab layout for Risk Action work item
UI for Risk Action, Time Tracking tab
UI for Risk Action, Time Tracking tab

Benefits of using Rational Team Concert to manage risks

  • Get complete change control management and project risk management, with no need for separate software.
  • Store all project data at one location, because you use only one tool.
  • Refer to risk items and actions quickly and easily, and refer to Risk work items across different project areas, now and in the future.
  • Use a simple UI to capture risks and related parameters in work items with conventions that team members are familiar with, because the layout is similar to other work items in Rational Team Concert.
  • Record the actions, decisions, project, and people involved in project risk management, from risk identification to risk closure.
  • Create independent risk actions for identified risks, and track each of those actions.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=Rational, Security, DevOps
ArticleTitle=Using Risk and Risk Action work items in Rational Team Concert