Using SharePoint to Manage Risks & Issues

One of the most straightforward applications of project management best practices using SharePoint relates to managing risks and issues. Maintaining a Risk & Issues Tracking list within your project team site improves the structure and accessibility associated with this important best practice area. This is a huge improvement over the “offline” tracking Excel spreadsheet that is reviewed and updated on a semi-regular basis only by the project manager.

Creating the Risk & Issue Tracking Log in SharePoint

I find that the Issue Tracking type list is a great starting point for creating the Risk & Issue Tracking Log in SharePoint. The following are the standard fields associated with this type of list that I leverage to create the Risk and Issue tracking tool:

• Id – System assigned unique identifier for the risk or issue.
• Title – Headline associated with the risk/issue.
• Description – More details about the risk/issue (background and source of the risk/issue).
• Category – Tailor this field to capture the risk/issue categories associated with your project. In most cases, this field is used to group the risks/issues by type/source of risk or functional areas.
• Priority (Magnitude) – Used to capture the magnitude of the impact of the risk or issue on the project. I tailor this field to be a choice between 9 (high impact), 3 (medium impact), and 1 (low impact). Assigning a numeric value enables calculation of the overall risk/issue ranking. The values 9, 3, and 1 provides separation between the higher impact risks/issues and medium & low impact risks/issues.
• Assigned to (Owner) – The team member that owns management of the risk approach or issue resolution.
• Due Date (Target date) – Represents the target date for the resolution of an issue. The date assigned for a risk is generally when the potential event is anticipated to occur and needs to be proactively managed.
• Status – Tailor this field to capture the current status of the risk or issue. Try not to overcomplicate the status – something like Active, Resolved, and Closed is adequate to communicate the status of a risk/issue.
• Comments – Utilized to explain the current status of the risk or issue.

The following metadata is added to this list to improve the tracking of risks and issues based upon the best practices associated with Risk and Issue Management:

• Risk or Issue – A selection of Risk or Issue. This field provides the capability to maintain risks and issues in the same list. If a Risk turns into an Issue, you just need to update this field (vs. re-enter it into another list).
• Project Impact – A multiple line text field that is set-up to explain the impact of the risk or issue on the project (schedule, scope, budget, quality). This description helps explain the magnitude ranking assigned to the risk/issue.
• Probability – Used to estimate the probability of the risk occurring. Similar to the magnitude field, I set-up this field to be a choice between 9 (high probability), 3 (medium probability), and 1 (low probability). A value of 9 is assigned for issues (the event has already occurred). Assigning a numeric value enables calculation of the overall risk/issue ranking. The values 9, 3, and 1 provides separation between the most risks/issues and medium/low risks.
• Risk ranking – The risk ranking is set-up as a calculated field to establish the overall risk/issue ranking based upon a combination of the magnitude and probability of the risk (magnitude x probability). An “81” risk/issue represents a high impact and high probability item that triggers more focus and attention from the team.
• Risk approach – The planned risk management approach. This field is set-up with an option of Mitigate, Avoid, or Accept.

Below is an example of the “All Items” view of the Risk and Issue Tracking Log list in SharePoint.

Creating Views

Once the list is set-up and populated with data, multiple views can be created to communicate more effectively with different audiences. If you are talking to your core team, you will pull up the Active Risks or Issues, and filter on different categories. If you are preparing your status report or communicating with your project sponsor, you will use the High Impact Risks or Issues views. Individuals on the team will l focus on the risks or issues that they own, using the My Issues view. Below is an example of different views created for the Risk and Issues Tracking Log.

 

 

Exporting to Excel

I am not an advocate of pulling the issues “offline” into Excel for communication purposes. It is best to provide your stakeholders access to the view that gives them the relevant information based upon their needs. However, on larger projects with significant amounts of data, it is helpful to be able to export the list into Excel to perform additional analysis (e.g. creating charts that depict risk/issue related trends). Below is an example of the risk and issue tracking log exported into Excel.

Summary

Diligence around resolving issues and reducing the probability or impact of potential risks is a key PM best practice, particularly during the execution phase of the project. Use of SharePoint to manage risks and issues enables a more structured and accessible process, creating a project environment that encourages and facilitates timely identification and resolution or mitigation of risks and issues. In addition, it provides a strong tool to deliver targeted communication to key stakeholders. Teams that most effectively manage risks and issues are the teams that avoid major surprises and set-backs throughout the project life cycle.