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.
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 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 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 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.
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
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.
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.
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?
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.
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.
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.
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.
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
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.
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
- 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.
- 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
- 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
- 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
- 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
- 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.
- More about Rational Team Concert:
- Rational Team Concert template help:
- Read Managing Formal Projects in Rational Team Concert 3.0.1 in the Jazz library.
- In the Managing Risks section of the Collaborative Lifecycle Management information center, check the Defining risks and Creating Risk Actions topics.
- See the Administering projects topic in the Rational software information center for Formal Project Management process template documentation.
- Find Rational Team Concert articles and links to many other resources on IBM developerWorks, and check the product overview page, features and benefits, system requirements, and the user information center.
- Check the Rational Team Concert page on Jazz.net.
- Watch the Using Rational Team Concert in a globally distributed team webcast or a demonstration of the Dashboards and reports, or listen to the podcast about IBM Rational Team Concert and Jazz.
- Rational Team Concert template help:
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Subscribe to the developerWorks weekly email newsletter, and choose the topics to follow. Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools, as well as IT industry trends.
- Watch developerWorks on-demand demos, ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, any time, and many of the “Getting Started” ones are free.
Get products and technologies
- Download Rational Team Concert from Jazz.net and try it free on up to 10 projects for as long as you want (requires registration).
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
- Join the Rational Team Concert forum discussions on Jazz.net.
- Rate or review Rational software. It’s quick and easy.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. Find out what makes a good developerWorks article and how to proceed.
- Follow Rational software on Facebook, Twitter (@ibmrational), and YouTube, and add your comments and requests.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Get connected. Join the Rational community to share your Rational software expertise and get acquainted with your peers.
Ankur Sharma is a staff software engineer for IBM Rational software. He has six years of experience in application development, including web application development, web services, and Eclipse Standard Widget Toolkit (SWT) development.
Siddharth Kumar Saraya, who is a Technical Lead for Rational software in the IBM Software Labs, completed a dual master's degree, one in computer application and a second in business administration with an emphasis in risk and insurance management. Siddharth's experience includes manual and automated testing, involvement in delivery of projects, and management of project teams from project initiation until deployment.