Abstract
Project risk and issue management is one of the most lethal but easily overlooked aspects of successful project management. Risks and issues derail your plan and cause you to divert focus away from project activities. But, there's simply no avoiding them. If you've got a project you're going to have risks and issues.
Project risks have several attributes as follows:
- They are generally known at the beginning of the project.
- They can exist at a specific point in the project or can persist through the life of the project.
- They can materially impact the outcome of the project if the risk comes true.
- There is a reasonable likelihood that the risk could come true.
- They are extraordinary to normal project management.
Similar to project risks, issues are problems that occur on a project that need some management action for resolution. If an issue isn't addressed, it could materially impact successful completion of the project. Where issues differ from risks, however, is that they generally don't persist throughout the project and they may not be known at the onset of a project. Your issue list will not be persistent like your project risks; items will open and close as they are identified and resolved. What's important in managing issues is that the issue needs to be material to successful project completion to be a management issue.
Introduction
So your project is humming along and stuff is getting done. Then, out of the blue, a key unanticipated product design issue comes up. As the project manager, you assess the design issue as not having a schedule impact and let the one of the project team members work it out. The design issue doesn't go away because the project team member thinks that the project manager is driving issue resolution. Before you know it, the project is late because the design issue wasn't addressed when it should have been.
Project risk and issue management is one of the most lethal but easily overlooked aspects of successful project management. Risks and issues derail your plan and cause you to divert focus away from project activities. But, there's simply no avoiding them. If you've got a project you're going to have risks and issues.
Risks and Issues: What's the Difference?
First, let's talk about risks. Have you ever done a project plan and documented assumptions that needed to occur for the project to be successful? These are the conditions in which you are relying on a specific outcome otherwise your project will not succeed. Because you are relying on the assumption having a specific outcome, the assumption presents a risk to the project if the outcome is different. For example, let's say you make an assumption that customers are going to be available for a minimum of 20 hours per week throughout the project. Because you have made this assumption, you are relying on them to be available or there will be a negative impact to schedule. So, this assumption then becomes a project risk that needs to be managed.
Project risks have several attributes, as follows:
- They are generally known at the beginning of the project.
- They can exist at a specific point in the project or can persist through the life of the project.
- They can materially impact the outcome of the project if the risk comes true.
- There is a reasonable likelihood that the risk could come true.
- They are extraordinary to what would normally be managed on a project.
Using your assumptions to identify the project risks is a very reasonable means of fleshing out the things on a project that are likely to hurt you. It is important, though, to focus on the important risks based on three factors: materiality, likelihood, and extraordinary-ness. When I define risks, I try to limit the risks to the top 6-8 things that have a likelihood of occurring, are extraordinary to normal project management, and could seriously hurt my project if they came true. As an example, if we were implementing a new technology I would absolutely have that as a project risk as there is a likelihood that the technology could fail and that it would seriously impact the project if it did indeed fail. I would not include risks like “activities must be completed on time” because, while it's material and likely, it's not extraordinary.
After you define your top project risks, your next step is to put mitigation strategies in place for each risk should the risk start coming true. So, if we take our example on implementing a new technology being a project risk, a mitigation strategy for the risk might include conducting stress and acceptance testing at the beginning of the project to ensure that the technology is able to perform under expected volumes. By defining mitigation strategies for each risk, you actively outline how you're going to head off the risk and manage away the potential problem.
Precision in defining risks is very important. I once worked with a project manager who consistently said, “This project is risky.” That statement, while it may be true, is completely un-actionable in that I didn't know what to do to mitigate the risk. Your risks should be defined in terms of the action that needs to be taken to mitigate the risk. If you're unable to articulate the action, your risk is ill-defined or not a material risk.
Now, let's focus on management issues. Similar to project risks, issues are problems that occur on a project and need some management action for resolution. If an issue isn't addressed, it could materially impact successful completion of the project. Where issues differ from risks, however, is that they generally don't persist throughout the project and they may not be known at the onset of a project. Your issue list will not be persistent like your project risks; items will open and close as they are identified and resolved. What's important in managing issues is that the issue needs to be material to successful project completion to be a management issue. For example, a management issue exists if there is a policy decision that needs to be made as a precursor to a key design point being finalized and the decision needs to be made by the project sponsor. There's materiality because the policy change directly impacts the design and may have widespread impact on the organization. In addition, an item may be escalated to a management-level issue if the issue owner is unable or unwilling to drive resolution to the issue. In this situation, the project manager escalates the issue for the project sponsor or steering committee to help the issue owner resolve the issue.
Managing Through the Risks and Issues Storm
To put issue and risk management into context, I need to describe an overall approach to reporting project status and how risk and issue management fits into the overall status report. I'm a firm believer in completing a project status report at least bi-weekly which is then communicated to project team members, key stakeholders, and project sponsors. Exhibit 1 below is an example of a project status report which outlines a project overall status, key milestones status, risks status, issues status, and project cost status. (free template available on http://www.projectmanagementadvisor.com)
Order Management & Shipping System Status Report
As Of: 1/12/20xx
Key components of order management and shipping modules were reviewed with minor revisions requested by customers. At this point, schedule is in a red status due to a 10-day slippage in work on the order management development completion. The project team is assessing alternatives to bringing in schedule via supplementing with additional resources and working overtime. If we are unable to recover, schedule downstream activities will be assessed to mitigate overall project slippage. Risks are at yellow status due to initial unfavorable stress testing results; subsequent test is being conducted to validate initial results. Issues are at red status due to customer manager being pulled from project to work on other activities. Request has been placed with home organization and the project sponsor for help. Project costs are green with estimate at completion being in line with total budget for project.
The project team is doing an outstanding job of working through some difficult issues and working to keep project tasks on schedule to the best of their ability. Particular thanks to the technical groups supporting the project for working overtime to help keep things on schedule.
Exhibit 1 – Project Status Report
As you can see from Exhibit 1, there are two distinct sections in the status report which focus on project risks and issues requiring management attention. Risks are summarized as follows:
Exhibit 2 – Project Risks Status Matrix
In characterizing risk status, I use a red/yellow/green coding scheme similar to schedule status, as follows:
- Green – everything is OK with the risk.
- Yellow – there are signs that the risk is about to come true and increased emphasis needs to be placed on the mitigation.
- Red – the risk is happening and the risk will cause a project impact unless immediate action is taken.
In Exhibit 2, risk #3 is showing signs that the risk is about to come true. Initial stress testing on the product is yielding unfavorable results. Additional focus is being placed on the risk to see if it can be pulled back to a green status.
Similarly, I summarize issues in the same manner:
Exhibit 3 – Project Issues Status Matrix
In characterizing issue status, I use the same red/yellow/green coding scheme:
- Green – The issue has been closed without impacting the project.
- Yellow – The issue has been identified, and unless the owner resolves by the needed date, the project will be impacted.
- Red – The issue hasn't been resolved and there will be an impact to the project until it is resolved.
In Exhibit 3, issue number 1 is in the process of being resolved with Bonnie Dentz needing to resolve it by 2/1. Issue number 2 has not been resolved by 1/10 and the project will have an adverse impact until it is resolved. Issue number 3 has just been closed satisfactorily and will roll off the management issue list on the next status report.
Reasons Project Fail Due to Poor Risk and Issue Management
Project risks or management issues don't get defined or don't focus on the important stuff
In defining project risks or management issues, it's important to ensure that the entire management team has input to and buys off on the lists. In defining risks, continue to ask yourself the following:
- Is it material if it happens?
- Is it likely to happen?
- Is it extraordinary versus just normal project management?
Similarly, when raising management issues, keep focus on materiality and project impact. It's also super-important to only raise issues to management once they exceed your span of control. If you chronically raise issues that the steering committee or project sponsor feels you should have been able to resolve on your own, your credibility as a project manager becomes suspect.
Project risks are defined but there is no mitigation strategy to manage through the risk
Defining and filtering your risk list is easy relative to defining mitigation strategies to navigate the risks. The mitigation strategies are going to be where your creativity and resourcefulness as a project manager come into play and, in my view, are one of the more fun parts of the job. I was running a project recently where we were using a new planning product and had an abnormally compressed timeframe to meet the needed completion date. We identified this as a key risk and employed as a mitigation weekly “show me's” where the product development team conducted weekly demonstrations of product functions completed that week. It worked great in that the product development team moved along quickly in order to meet their scheduled demonstrations, the project team got to see the weekly progress, and the team was able to react quickly if there was a problem with the product. Yes, this was an unconventional approach, but, given the identified risk, was a very appropriate and effective mitigation strategy.
Management issues get documented but there's no defined action to manage through the issue
Over the years, I've worked with a number of people who were great at saying, “I've got an issue” but did little beyond that to help resolve the issue. They are adept at backing up the issue dump truck into your project backyard, dumping the issues, and driving away leaving you to clean up the issue mess. As a project manager, I've learned to push back on issue dump truck drivers not only in clearly defining the issue, but in being part of the resolution. Putting a thoughtful and concise action plan down with needed actions, dates, and owners is crucial to ensuring that management issues get closed before they fatally impact your project.
Warning Signs that You're Headed for Failure
You don't have a project risk or issue list
If you can't go to a place where risks and issues are readily handy and accessible by the project team, you're likely to get surprised by an issue or risk on the project.
You don't have a plan for how you would mitigate risks from coming true
If you've only documented risks and have no specific mitigation plan for each risk, you're just a sitting duck waiting for a risk to blow your project out of the water. Each material, likely, and extraordinary risk needs a clear mitigation to help ensure that the risk doesn't come true.
There's no clear owner or need date for resolving issues
An issue rears its head on the project, and because there isn't a clear date or singular owner for resolving it, a major budget or schedule impact is created on the project because the issue wasn't addressed on a timely basis. Each issue needs an owner and a date in which it needs to be resolved to keep things moving along.
The project sponsor or steering committee isn't utilized effectively for resolving issues
Either issues are escalated when they shouldn't be or issues aren't escalated when they should.
You've likely got limited time with your sponsor or steering committee and you need to make sure that their time is spend on issues that you cannot control or require approval greater than you can provide.
The project team isn't clear on the problems that the project is currently facing
Project team members being surprised or confused by problems likely means that timely communication isn't happening or that the warning signals aren't in place for early problem identification. It could also mean that the team isn't meeting frequently enough to corporately understand the problem and the alternatives to resolving it.
Problems don't have a clear owner or “resolution needed-by” date
Problems assigned to “the team” or to some other group of people might just as well not be assigned at all, because it is unlikely that someone will take ownership for resolving the problem. Each problem, whether it is a schedule, issue, risk, or cost issue needs to be assigned to a singular owner with a needed-by date.
You don't know when something is about to be a problem
If you're frequently surprised by problems hitting you without any advanced warning, you might not have the right early warning system in place to identify potential problems so that you can take timely action. Surprises are fun for birthday parties, not so fun for projects.
Turning things around
Get your risks defined and define clear mitigation strategies for each risk
It's never too late to take this step in your project. Take the time to think about the risks you face that are material, extraordinary, and likely. If you developed an assumptions list as part of your project plan, use that as a starting point. Review them with the project team to ensure that the list is right. Then put together very clear mitigation strategies for averting each risk. The best way to do this is to incorporate the mitigation activities in the project plan so they are a normal part of the project and not superfluous activities.
Right-size the issue list
Get clear about defining which issues can be resolved by the project team and which issues you need help from your sponsor, steering committee, or other stakeholder to resolve. Don't escalate issues that you can deal with amongst the project team
Know who's on the hook
For risks, make sure that there is an owner on the team for managing the mitigation. For issues, make sure that a team member owns teeing up the issue and proposed resolution with the project sponsor or steering committee. While the sponsor or steering committee is responsible for making the decision, the project team is responsible for analyzing alternatives and providing a recommendation.
In Summary
To conclude, here are some key takeaways to remember in managing project risks and issues:
- Take the time at project onset to clearly define your project risks, mitigation strategies, and accountable points of contact.
- Regularly report status on project risks and issues and assess each risk and issue for potential to impact your project.
- Make sure that there is clear ownership for each risk and issue by someone on the project team
- Don't assume something will just go away or fix itself; be proactive about managing it through to resolution.
