Risk (CMMI)

In this topic, you can learn how to fill in the details of a risk work item. Risk work items document a possible event or condition that can have a negative outcome on the project in the future. A key aspect of project management is to identify and manage the risks of a project. For more information, see Managing Risks.

For information about how to create this type of work item, see Work Items and Workflow (CMMI).

In this topic	Related topics
Defining a Risk Linking a Risk to a Requirement, Task, or Other Work Item Adding Details, Attachments, or Hyperlinks to a Risk Changing the State of a Risk	Process Guidance Managing Risks Field Reference Titles, IDs, Description, and History (CMMI) Areas and Iterations Assignments, Workflow, and Planning (CMMI) Fields that Track Bugs, Issues, and Risks (CMMI) Linking Work Items (CMMI) Attachments

Required Permissions

To view a risk, you must be a member of the Readers group or your View work items in this node must be set to Allow. To modify a risk, you must be a member of the Contributors group or your Edit work items in this node permissions must be set to Allow. For more information, see Managing Permissions.

Defining a Risk

The work item form for a risk stores data in the fields and tabs that the following illustrations show:

   

When you define a risk, you must define the Title. You can leave all other fields blank or accept their default values.

To define a single risk

1. In the top section of the work item form, specify one or more of the following types of information:

   • In Title (required), type a short description.

     Good titles support the team's understanding of the potential risk involved. At any time, you can update the text to more accurately define the risk and the areas of work that might be affected.

   • In the Probability box, type a number between 1 and 99 to indicate the chance that the risk will occur.

     For example, you can type 1 to indicate that a risk is highly unlikely to occur.

   • In the Assigned To list, click the name of the team member who is responsible for addressing the risk.

     Note

     You can assign work items only to members of the Contributors group.

     If you leave the risk unassigned, it is automatically assigned to you.

   • In the State list, leave the default value, Proposed.

     By default, the value of the Reason field is New. For more information about this field and how you can use it to track workflow, see Changing the State of a Risk later in this topic.

   • In the Area and Iteration lists, click the appropriate area and iteration, or leave these fields blank.

     Note

     Your project administrator defined the Area and Iteration tree hierarchies so that team members can track progress by those designations. For more information, see Create and Modify Areas and Iterations.

   • In the Priority list, click the level of importance for the Risk on a scale of 1 (most important) to 4 (least important).

     By default, this value is 2.

   • In the Severity list, indicate the potential magnitude of adverse effects, such as cost and loss, if the risk occurs.

     You can specify this rating, which is subjective, as 1-Critical, 2-High, 3-Medium, or 4-Low. By default, this value is 3-Medium.

   • In the Blocked list, click Yes if an issue is preventing the team from mitigating the risk.

     If the team has created an issue work item to track the blocking problem, a link should be created to that work item also.

   • In the Original Estimate box, type a number that represents how many hours of work the risk mitigation plan will take to implement.

2. On the Details tab, provide as much detail as you want to describe the risk and the action that you propose to mitigate the risk.

3. On the Mitigation tab, provide as much detail as you want to describe the conditions or events that determine whether a risk should be mitigated.

   For example, the team might obtain a reserve generator if the weather forecast is predicting an ice storm or hurricane to hit within 50 miles of the office within the next four days.

4. On the Contingency Plan tab, provide as much detail as you want to describe the actions to take if the risk occurs.

   The team tracks the plan by creating an Issue work item and tasks that the team assigns to one or more members of the team.

5. On the All Links tabs, you can create links from the risk to one or more other work items, such as tasks and requirements.

6. On the Attachments tab, attach specifications, images, or other files that provide more details about the risk to be addressed.

   For more information, see the following sections later in this topic:

   • Linking a Risk to a Requirement, Task, or Other Work Item

   • Adding Details, Attachments, or Hyperlinks to a Risk

7. Click Save Work Item.

   Note

   After you save the risk, the identifier appears in the title under the work item toolbar.

Linking a Risk to a Requirement, Task, or Other Work Item

By creating relationships between risks and other work items, you can plan projects more effectively, track dependencies more accurately, view hierarchical relationships more clearly, and find relevant information more quickly. From the form for a risk work item, you can create another work item that is automatically linked to the risk, or you can create one or more links to existing work items.

On the Links tab, you can create specific types of links to specific types of work items. For more information, see Linking Work Items (CMMI).

To create and link a task, bug, requirement, or other work item to a risk

1. Open the form for the risk work item, click the All Links tab, and then click New.

   The Add new Linked Work Item dialog box opens.

   

2. In the Link Type list, click Related or another type of link that represents the relationship that you want to track.

3. In the Work Item Type list, click the type of work item that you want to create.

4. In Title, type a short but specific description of the work to be performed.

5. (Optional) In Comment, type additional information.

6. Click OK.

   A work item form for the type of work item that you specified opens with the information that you have provided.

7. Specify the remaining fields as the following topics describe:

   • Requirement (CMMI)

   • Change Request (CMMI)

   • Task (CMMI)

   • Bug (CMMI)

   • Test Case (Agile)

   • Issue (CMMI)

   • Review (CMMI)

8. Click Save Work Item.

To link several existing work items to a Risk

1. Open the form for the Risk work item, click the Links tab, and then click Link to.

   The Add Link to Risk dialog box opens.

   

2. In the Link Type list, click Related or another type of link that represents the relationship that you want to track based on the type of work item to which you are linking.

3. Perform one of the following actions:

   • In Work item IDs, type the IDs of the work items that you want to find. Separate IDs by commas or spaces.

   • Click Browse to specify work items from a list.

     The Choose linked work items dialog box appears.

     

     In the Saved query list, click a query that contains the work items that you want to add. For example, you can click Open Work Items, Active Bugs, or Active Tasks.

     Click Find, and then select the check box next to each work item that you want to link to the Risk.

     Click OK.

   • (Optional) Type a description for the items to which you are linking.

4. Click OK.

   For more information, see Find Work Items to Link or Import.

5. Click Save Work Item.

   Note

   Both the risk and work items that you linked are updated.

Adding Details, Attachments, or Hyperlinks to a Risk

As more information becomes available, you can add information to a risk in the following ways:

• Type information in the text boxes on the Description, Mitigation, Contingency Plan, or History tabs.

• Attach a file.

  For example, you can attach an e-mail thread, a document, an image, a log file, or another type of file.

• Add a hyperlink to a Web site or to a file that is stored on a server or Web site.

To add details to a risk

1. Click the Description, Mitigation, Contingency Plan, or History tab, and type information in one of the text boxes.

   You can format information to provide emphasis or capture a bulleted list.

   Note

   Every time that a team member updates the work item, its history shows the date of the change, the name of the team member who made the change, and the fields that changed.

   For more information, see Fields that Track Bugs, Issues, and Risks (CMMI) and Titles, IDs, Descriptions, and History (Agile).

2. Click Save Work Item.

To add an attachment to a risk

1. On the Attachments tab, perform one of the following actions:

   • Drag a file into the attachment area.

   • Click or press CTRL-V to paste a file that you have copied.

   • Click Add, click Browse, and, in the Attachment dialog box, type or browse to the name of the file that you want to attach.

     (Optional) In the Comment box, type additional information about the attachment.

     To close the Attachment dialog box, click OK.

2. Click Save Work Item.

To add a hyperlink to a risk

1. On the Links tab, click Link to.

   

2. In the Link Type list, click Hyperlink.

3. In the Address box, perform one of the following actions:

   • If the target is a Web site, type the URL, or copy it from your Internet browser and paste it into the Address box.

   • If the target is a server location, type its UNC address.

4. (Optional) In the Comment box, type additional information about the hyperlink.

5. Click OK.

6. Click Save Work Item.

Changing the State of a Risk

If the team determines that it must mitigate a risk, a team member sets its state to Active. The risk remains active until the mitigation actions are complete, at which point, a team member changes the state to Resolved. If the team verifies that it has mitigated a resolved risk, a team member closes it.

If the event that the risk identifies occurs, the team enacts a contingency plan.

A team can use the following states to track the states of Risks:

• Proposed

• Active

• Resolved

• Closed

Any team member can change the state of a risk.

A team member creates a risk in the Proposed state. When a team accepts a risk for the current iteration, the risk moves to the Active state, and the team analyzes the risk and creates tasks to implement it. When the tasks are complete and system tests show that the team successfully implemented the risk, it moves to the Resolved state. Finally, the team moves the risk to the Closed state after the team validates the risk.

For more information about the data fields that you can use to track work item states, see Assignments, Workflow, and Planning (CMMI).

To change the state of a risk

1. Open the risk.

2. In the State list, click Active, Resolved or Closed.

   • If you change the state from Proposed to Active, the Reason field automatically changes to Accepted.

   • If you change the state from Active to Resolved, the Reason field automatically changes to Code Complete and System Test Passed.

   • If you change the state from Resolved to Closed, the Reason field changes to Validation Test Passed.

3. Click Save Work Item.

Typical workflow progression: A team member creates a risk in the Proposed state with the default reason, New. A team member changes the state of the risk from Proposed to Active with the default reason, Accepted. A team member changes the state of the risk from Active to Resolved after the team completes all mitigation actions. A team member changes the state of the risk from Resolved to Closed when the team validates the risk as having been mitigated. Atypical transitions: A team member changes the state of the risk from Proposed to Closed with the default reason, Rejected. A team member changes the state of the risk from Active to Closed if the risk occurs before the team mitigates it, the risk is no longer possible, or the risk is no longer relevant to the project. A team member changes the state of the risk from Resolved to Active when the team reviews the mitigation and determines that the risk is still present. A team member determines that the risk was closed in error and changes the state from Closed to Active.

Risk State Diagram

Proposed (New)

The team identifies each proposed Risk and analyzes it for probability of occurrence, cost of occurrence, mitigation options, mitigation triggers, and contingency plans. The team activates a proposed risk if the mitigation triggers are set off or if it is a high enough priority to mitigate immediately. The team closes a proposed risk if the team determines that the risk is no longer of concern or that it is not feasible to mitigate the risk.

The following data fields are automatically captured when a team member creates a risk:

• Created By: Name of the team member who created the risk.

• Created Date: Date and time when the risk was created, as recorded by the server clock.

From Proposed to Active

A team member move a Risk from a Proposed to Active state when the need for its mitigation is triggered.

Reason	When to use	Additional actions to take
Mitigation Triggered	When the conditions that are defined by the mitigation triggers occur or the team considers a risk to be a high enough priority to warrant immediate mitigation.	Assign the risk to the team member who will implement the mitigation plan.

The following data fields are captured when a team member changes the state of a risk to Active:

• Activated By: Name of the team member who activated the risk.

• Activated Date: Date and time when the risk was activated, as recorded by the server clock.

• State Change Date: Date and time when the state of the risk was changed.

From Proposed to Closed

A team member can close a risk that is in the Proposed state because of one of the reasons in the following table:

Reason	When to use	Additional actions to take
Rejected (Not a Risk)	When the team determines, through additional analysis or review, that the event or condition to cause the risk cannot occur or that the impact would be negligible.	None.
Accepted	When the team determines that effective preventive or corrective measures are not feasible and that the potential benefits outweigh the potential consequences.	None.

The following data fields are captured when a team member closes a risk:

• Closed By: Name of the team member who closed the risk.

• Closed Date: Date and time when the risk was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the risk was changed.

Active

The team works to mitigate any risk that is in the Active state. When the team completes all mitigation tasks for the risk, it moves to the Resolved state. If the risk occurs before the team completes mitigation tasks, the team creates an issue work item to track the problem and closes the risk work item.

From Active to Resolved

A team member can resolve an active risk when the team completes a planned mitigation action or actions. The default Reason is Mitigation Action Complete. The team should assign the risk to the team member who will verify it.

The following data fields are captured when a team member resolves an active risk:

• Resolved By: Name of the team member who resolved the risk.

• Resolved Date: Date and time when the risk was resolved, as recorded by the server clock.

• State Change Date: Date and time when the state of the risk was changed.

From Active to Closed

A team member can close an active risk because of one of the reasons in the following table:

Reason	When to use	Additional actions to take
Overtaken by events	When the risk occurs before the team mitigates it.	Create an issue work item to track the problem, and link to the closed risk work item. Enact the contingency plan as a corrective action for the issue.
Rejected (Not a Risk)	When the team determines, through additional analysis or review, that the event or condition to cause the risk cannot occur or that the impact would be negligible.	None.
Eliminated	When the risk is no longer valid because the project or the risk itself has changed. Because the risk can no longer occur, the team can stop tracking it.	None.

The following data fields are captured when you close an active risk:

• Closed By: Name of the team member who closed the risk.

• Closed Date: Date and time when the risk was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the risk was changed.

Resolved

When the team completes the mitigation tasks for a risk, the team sets the risk to Resolved and assigns it to a team member who will verify the mitigation work before closing the risk. If the mitigation is unsatisfactory, the team member reactivates the risk.

From Resolved to Closed

A team member can close a resolved risk when the team reviews the mitigation tasks and determines that the actions sufficiently mitigated the risk. The default Reason is Mitigation Action Complete. The team should assign the risk to the product owner.

The following data fields are automatically captured when a team member closes a resolved risk:

• Closed By: Name of the team member who closed the risk.

• Closed Date: Date and time when the risk was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the risk was changed.

From Resolved to Active

A team member can reactivate a resolved risk when the team reviews the mitigation tasks and determines that they will not address the risk sufficiently. The default Reason is Mitigation Action Unsatisfactory. The team should assign the risk to a team member who will implement the mitigation plan. Also, the risk verifier should annotate the risk work item to indicate what part of the mitigation plan failed verification.

The following data is automatically captured when a team member reactivates a resolved risk:

• Activated By: Name of the team member who reactivated the risk.

• Activated Date: Date and time when the risk was reactivated, as recorded by the server clock.

• State Change Date: Date and time when the state of the risk was changed.

Closed

A member of the team can reactivate a closed risk if it comes back into scope. Usually a business analyst or program manager reactivates a closed risk.

From Closed to Active

The team closes a risk after it has been mitigated or accepted because the team cannot mitigate the risk. You can reactivate a closed risk if it was accidentally closed. The reason is set to Closed in error.

The following data is automatically captured when a team member reactivates a closed risk:

• Activated By: Name of the team member who reactivated the risk.

• Activated Date: Date and time when the risk was reactivated, as recorded by the server clock.

• State Change Date: Date and time when the state of the risk was changed.

See Also

Concepts

Artifacts (CMMI)

Fields that Track Bugs, Issues, and Risks (CMMI)

Other Resources

Work Items and Workflow (CMMI)