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).

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 Assigned To list, choose 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, choose 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 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 Priority list, choose 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, choose 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 DESCRIPTION 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 CONTIGENCY 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. Choose 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, choose the All Links tab, and then choose New.

   The Add new Linked Work Item dialog box opens.

   

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

3. In the Work Item Type list, choose 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. Choose 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

   • Issue (CMMI)

   • Review (CMMI)

8. Choose Save Work Item.

To link several existing work items to a Risk

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

   The Add Link to Risk dialog box opens.

   

2. In the Link Type list, choose 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.

   • Choose Browse to specify work items from a list.

     The Choose linked work items dialog box appears.

     

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

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

     Choose OK.

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

4. Choose OK.

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

5. Choose 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. Choose 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 Bugs, Issues, and Risks Field Reference (CMMI) and Titles, IDs, Descriptions, and History Field Reference.

2. Choose 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.

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

   • Choose Add, choose 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, choose OK.

2. Choose Save Work Item.

To add a hyperlink to a risk

1. On the Links tab, choose Link to.

   

2. In the Link Type list, choose 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. Choose OK.

6. Choose 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 Tracking Status and Assignments [CMMI].

To change the state of a risk

1. Open the risk.

2. In the State list, choose 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. Choose 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.

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:

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:

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)

Bugs, Issues, and Risks Field Reference (CMMI)

Work Item Field Reference for Visual Studio ALM

Other Resources

Work Items and Workflow (CMMI)