You've got way too many issues!


Project managers realize that they must manage risks and issues in a timely and effective manner. However, many project teams do not practice effective and continuous risk management throughout the project life cycle, preferring to wait until the risk becomes realized, and becomes an issue, before taking any action. This paper will discuss the differences between project risk management and Issues Management and review some tools and best practices that make both jobs more effective. It will also cover some techniques and recommendations for applying these tools.

The objective of this paper is show the difference between risks and issues, how to best develop the effective mindset and attitude to deal with them, explain risk management best practices as well as risk management tools and techniques to apply consistent risk management throughout the project, and show issue management best practices and some effective tools for identifying, assessing and controlling issues on a project.


Many organizations exhibit an unusual phenomenon when asked to show the lists of risk they identified for their project. Many project teams routinely list only five or six risks listed. Most similar projects generate between 50 and 100 risks. With some convincing, one can get the team to quickly identify another 20 risks, and convince the team to be able to come up with some additional areas of uncertainty—once they take the time to explore.

A more surprising phenomenon happens when one looks at the list of issues being managed by the project team. The number swells into the hundreds, each with an owner and an action plan for dealing with the issue. Many of these issues occur after the project work begins, and could well have been avoided or reduced in severity by proactively identifying them as areas of uncertainty at the project start. There is definitely a connection between insufficient risk management and overblown issues management.

But why would an organization care whether an item was identified as a risk early on in the project, or an issue later on? For that matter, why worry about risks at all, since they haven't been proven to definitely occur? It's only a waste of time; time that could be better spent producing the project's deliverables and not a bunch of paper. There is no benefit for the project team, especially when issues management is what gets rewarded!

Organizational Mindset Toward Risk Management

Here a few observations that I've made with regards to projects that I've audited:

  1. Many organizations focus more on issues management than proactive risk management.
  2. Many project managers wait until a risk event has occurred (and becomes an issue) before they deal with it.
  3. Many project teams’ idea of risk management is to wait for the risk to be realized and then develop a workaround.
  4. There is little reward within the organization for practicing risk management, but often great rewards for those who can successfully deal with issues.

These concepts suggest that developing a good, proactive risk management discipline is an organizational responsibility, and that organizations need to develop a mindset around proactive risk management. But the simple fact is that many organizations do not practice good, proactive risk management continuously across all their projects. The reasons often given are varied:

  1. “We don't have time to plan for things that might occur.” (But we always seem to have the time and money to fix the problems that they cause.)
  2. “Risk planning is just an excuse for not getting any work done.” (But is looking out for the interests of the project and its stakeholders not important?)
  3. “There is no value-add to risk management planning.” (But there is recovering from setbacks and missing opportunities?)
  4. “I get paid for fixing real problems, not for planning for imaginary ones.” (But do you get paid for causing problems?)

None of these arguments hold water if you're the individual that has to put forth the extraordinary effort sometimes required to deal with a realized risk. Individuals who make these statements don't understand that developing contingencies to deal with potential problems is good project management.

Joseph Juran defined a project as “a problem scheduled for solution” (Juran, 1989). Wouldn't an organization consider chronic risks and issues a “problem”? It has been my experience that organizations, even those that realize the importance of proactive risk management, often practice it sporadically. Treating risk and issues management as an organizational problem requires a commitment of time and resources that apparently most organizations don't want to make. Risk management might be performed well, or at least performed, early in the project when the pressure to deliver is virtually non-existent. But as soon as the project gets into the stress of delivering according to a tight schedule, risk management goes out the window, and we wait until the risk surfaces, and becomes an issue, before we devote any time or energy to respond. This is an expensive strategy to follow from a cost, resource and time perspective.

Issues are often best dealt with when they are small and before they can greatly impact the project objectives. This is the whole idea behind risk management – developing strategies and responses before the risk is realized. It is proactive, rather than reactive, and follows a prescribed set of activities to identify, assess, respond and control the uncertainties of a project before they become issues that will siphon off resources and time to resolve.

The other side of risk management is to identify, assess, respond and control those opportunities that represent the potential positive outcome of a realized uncertainty. By not practicing proactive risk management, we can miss the benefits of these missed opportunities, and thereby deny the project team a chance to get ahead of any problems or issues by managing these benefits.

The final point to be made about developing an organizational mindset towards risk management involves the benefits obtained by collecting and categorizing the project risks actually realized by each individual project. This collection, often best represented by a Pareto chart, can be used to identify areas of focus for future endeavors and represents developmental opportunities for an organization as it attempts to move to higher levels of project management maturity. This central repository of “lessons learned” also adds to the organizational process assets and can be used by future project managers as inputs to the risk identification and assessment processes.

Risk Management vs. Issues Management

Many confuse the ideas of risk management and issues management. In actual practice, there are many similarities which lead to this confusion, but the essential differences are:

Risks Issues
Uncertainty Certainty
Probability of occurrence – 1 – 99% Probability of occurrence – 100%
Varying degrees of impact Varying degrees of impact
Proactive response based upon analysis Reactive response based on urgency
May not happen Definitely has already happened

It is clear from the above table that risks are “future-focused” and issues are more “present-focused” in their management. But, as David Hulett, PhD., has pointed out, “there are no ‘facts’ about the future.” (Hulett, 2004, pages 4-5). Risks always have that degree of uncertainty that is used in the analysis and prioritization process, whereas issues are very clear – they do exist and have already occurred. Both risks and issues have impacts to the project, and therefore responses need to be developed for them both.

In practice, project teams use many of the same tools (logs, owners, management plans, etc.) to deal with both risks and issues on their project. In the next sections, we isolate some of these tools and best practices for first, risk management, and then, issues management.

Project Risk Management

Project RiskAn uncertain event or condition that, if it occurs, has a positive or negative effect on the project's objectives. (PMI, 2004)

According to A Guide to the Project Management Body of Knowledge (PMBOK® Guide), project risk is really just uncertainty about what will happen in the future. What can happen can either be good, bad or neutral. Many of us are only concerned about bad outcomes, so our focus is on the potential negative impacts, but a strong case can be made for addressing those positive impacts of a potential risk. These opportunities can accelerate our project schedule, reduce costs and improve quality, and, for these reasons alone should be explored.

There are many tools that can help in the identification of both positive impact risks (opportunities) and negative impact ones (threats), but one of the most obvious is a SWOT analysis. A SWOT analysis is a tool where we examine where to apply specific, focused efforts to achieve a particular outcome. SWOT stands for:





From a risk perspective, strengths and opportunities represent risks with positive impacts, and weaknesses and threats are those with negative impacts. Risk management is all about having defined processes for dealing with uncertainty on a project, so that the impacts from threats can be minimized and those from opportunities enhanced. These processes are defined in the risk management plan.

The project risk management plan is one of the subsidiary management plans that make up the overall project management plan. It is the plan to define and manage risk on the project. The PMBOK® Guide offers some suggestions as to the component pieces of this plan, but in general, this plan should contain all the ground rules and standard operating procedures that that project team will follow to define, analyze, develop responses for, monitor and control risks throughout the project. It is both a team exercise and a process approach to developing a re-usable asset focused on risk management.

In general, the risk management plan should include processes that the team will use to perform the following risk management activities:

  1. Risk management planning – This activity produces the risk management plan, described above. It contains the ground rules and procedures that the team will use to define and manage risk on the project.
  2. Risk identification – The goal of this activity is produce lots of risks. Tools like checklists, brainstorming, SWOT analysis, assumptions analysis, Delphi technique, etc. are especially helpful in this process.
  3. Risk assessment – The PMBOK® Guide describes two sequential processes for this, qualitative risk analysis and quantitative risk analysis. Whether you perform both processes, and what tools you will use, will be determined by the nature of your project, but the overall goal of this stage is to produce a prioritized list of risks. Not all risks identified are equal. Your aim is to reduce the large number of risks identified into the significant few that will be responded to, monitored and controlled.
  4. Risk response planning – Here is where the team develops responses to the top n risks produced by the risk assessment. Responses should be driven by the analysis and the response dependent upon whether the risk was identified as an opportunity or a threat.
  5. Risk monitoring – All risks identified need to be monitored, regardless of the ranking produced during the analysis. As you move from phase to phase within a project life cycle, risks can change, and new risks can be added. Risk monitoring includes not only watching identified risks, but also identifying new ones.
  6. Risk control – A certain percentage of the risks identified will be realized within the life of the project, and these risks need to be controlled. All risks need to be monitored, but only those that occur need to be controlled.
  7. Gather risk lessons learned – This is an important part of risk management, as it allows the project team to update their information about the whole risk management process, update the risk management plan, and add to the existing risk checklist for the next project.

The PMBOK® Guide contains these processes as part of the Project Risk Management processes covered in Chapter 11. Many organizations are familiar with this process, but don't practice continuous risk management on their project. Their teams work hard up front doing the risk identification and analysis, and may even do some response planning, but fall apart once the project begins. The next risk management activity is developing the workaround after the risk is realized.

Here is a list of risk management best practices that will increase the project team's use of continuous risk management:

  • Perform a fresh risk assessment (identification, analysis, response planning) at the beginning of each new phase of the project. Each phase brings its own uncertainties (and removes others), so it is important to do a new assessment as part of the entry criteria to each phase.
  • Make a discussion of risk part of the agenda for every project status meeting. Status meetings are held throughout the project, so a good way to perform continuous management of any discipline is to add it to the agenda for this meeting.
  • Assign an owner to each identified risk. The owner is tasked with developing and executing the risk response plan, monitoring the risk until it is retired, and controlling the risk if realized. The risk owner will also be tasked with reporting on their risks during project status meetings.
  • Perform a risk analysis before developing time and cost estimates. Developing these estimates without considering risk will force us later to insert any activities and contingent responses into the project plan.
  • Re-use any relevant risk management process assets like the risk management plan and probability and impact scales. If these assets worked for one project, the odds are pretty good that they can be leveraged for another.

Issues Management

IssueA point or matter that is in question or in dispute, or a point or matter that is not settled or under discussion or over which there are opposing views or disagreements. (PMI, 2004)

Here, the PMBOK® Guide is a little more vague, as it implies that the issue is merely a dispute or disagreement. A more definitive definition can be found on the web site of the Issue Management Council ( Teresa Yancey Crane, founder of the Issue Management council, defines an issue as “a gap between your actions and stakeholder expectations.”(Crane, 2007)

Taking liberties with this definition, and applying it to the context of a project, we can develop the following definition for an issue:

Issueany gap between a stakeholder expectation and your project's reality.

Exhibit 1

Exhibit 1

Issues come in a variety of types:

Routine – Those caused by:

Lack of information

Resource conflicts

Poor communication

Unanticipated events

Political – Those centered in personality and power:



External – Those caused by people/events outside the project organization.

It is sometimes helpful to categorize the issues by the above types, so as to gain insights into the issues affecting the organization, and which issues are within the control of the project team. A Pareto analysis into these different types of issues can lead to some organizational improvements.

Using the above definition of issue, then, we can define issues management as any action, or activities, used to close the gap between a stakeholder's expectation and the project's reality. These strategies can be summed up as follows:

  1. Change the stakeholder expectation to meet the project reality.
  2. Change the project reality to meet stakeholder expectations.
  3. Change both the stakeholder expectation and the project reality.

The PMBOK® Guide does include issues management as part of both the Project Human Resource Management and Project Communication Management Knowledge Areas. Coincidentally, they are both “manage” processes, Manage Project Team (PMI, 2004) and Manage Stakeholders (PMI, 2004). It is interesting to note that “resolved issues” is an output of the Manage Stakeholder process, and it is fair to say that until an issue is resolved, it remains an issue.

In many respects, issues management is similar to risk management in that owners are assigned, impacts are analyzed, responses are developed, and logs are used to track and report. In addition, the development of an issues management plan is recommended.

An issues management plan is the project team's process (plan) for defining and managing issues on the project. Its purpose is to make sure that all project issues are identified, evaluated and assigned to an owner for resolution. Many issues impact project costs, schedule, quality and/or scope, and the issues management plan should stipulate that any issue resolution that impacts these objectives needs to go through the Integrated Change Control (PMI, 2004) process. It should also include provisions to communicate and document any issue resolutions, actions and decisions.

Like the risk management process, issues management includes the following team processes:

  1. Issue management planning – This activity produces the Issues management plan described above. It contains the ground rules and procedures that the team will use to define and manage the issues on the project.
  2. Issue identification – The goal of this activity is to identify the issues at play for this project. Risk identification tools like checklists, brainstorming, SWOT analysis, scatter diagrams, Ishikawa charts, etc. can also be used in this process.
  3. Issue prioritization/classification – In this process, the overall goal is to produce a prioritized list of the issues present in the project. Like risks, not all issues identified are equal. Your aim is to focus issues management activities to those that will be responded to, monitored and controlled.
  4. Issue response planning – Here is where the team develops responses to the top issues produced by the prioritization/classification process. This process is also where the issue's owner is identified.
  5. Issue actions implementation – Issue action includes setting a goal (target), objectives (defined successful outcomes), strategy and tactics for the actions taken in response to the issue.
  6. Issue monitoring – All issues identified need to be monitored, regardless of ranking produced during the prioritization classification. Like risk monitoring, issue monitoring includes not only watching identified issues, but also identifying new ones.
  7. Gather issue lessons learned – This is an important part of issue management, as it allows the project team to update their information about the whole issue management process, and update and revise their Issues Management Plan.

It is important to realize the impact that the project communications management processes have in addressing any issues that arise in a project. Creating issue logs and an issues management plan are two extremely useful tools in managing project issues. Setting up an issues responsibility assignment matrix is another. Issues analysis tools like Pareto Charts, Ishikawa diagrams, and Scatter Diagrams can help the project team understand the forces at play in managing issues and help in the lesson learned process.

Here is a list of issue management best practices that will help the project team more effectively deal with project issues:

  • Try to deal with each issue as soon as possible. Generally speaking, the sooner the issue is addressed, the easier and cheaper the solution.
  • Track issues by type or category. This will allow the team to analyze typical project issues and develop more effective strategies in dealing with them.
  • Recognize that issues management is part of the overall stakeholder management process. And with stakeholders, it's all about managing expectations.
  • Capture lessons learned about resolved (and unresolved issues). These lessons will enrich the historical information database and add to the information used to manage future issues.
  • Like risks, include a discussion of issues as part of every status meeting.
  • Try to resolve all issues at the lowest level possible. Individuals closest to the problem should handle the resolution, if possible.
  • Engage customers (stakeholders) in the issues management process. This is especially important when using a strategy that will seek to align the stakeholder expectation to the project reality.
  • Require those with decision-making authority to attend any issue resolution meeting. You want to avoid any delay in implementing any actions that would resolve the issue, and having someone with the power to make decisions will help in this regard.
  • Look for the root cause of several similar issues. You may find a single solution to many issues, and, therefore, make better use of your limited resources.
  • Include an escalation process in the issues management plan. Not all issues will be resolved at your level, or within your timeframe. The project team will need a way to push issue resolution up the chain of command if their initial efforts fail.
  • Adopt a formal issues management process. Relying on ad hoc solutions and processes as each issue presents itself is an exercise in frustration. Formalizing the process will allow the project team to know what steps are required when it comes time to deal with project issues.


This paper focused on the differences between risk management and issues management. It showed that issues management activities can be mitigated by performing proactive risk management. Teams should deal with the potential problem while the impacts to the project objectives are minimal. Risk management deals with the uncertainty that exists in all endeavors that try to plan for future events. Risk management tools and best practices were presented, as well as recommendations for their use. Issues management deals with all those events or problems that have already occurred. The issue is certain, and must be dealt with, or it will have an impact on the project objectives. Issue management tools and best practices were presented, along with suggestions for their use.

Crane, T. Y. (2007, May) An Issue Ignored is a Crisis Invited. Oman Executive Review [Electronic Version] Retrieved on July 5, 2007 from

Juran J. M. (1989)., Leadership for Quality—An Executive Handbook (New York: Free Press,.

Hulett, D.T. (2004, 4th Qtr) What Every Executive Needs to Know About Project Risk Management, Flying High [Electronic Version] Retrieved on July 5, 2007 from

Project Management Institute. (2004) A guide to the project management body of knowledge (PMBOK®) (Third Edition). Newtown Square, PA: Project Management Institute.

© 2007, Ernest Baker, PMP
Originally published as a part of 2007 PMI Global Congress Proceedings – Atlanta, Georgia



Related Content

  • Project Management Journal

    Narratives of Project Risk Management member content locked

    By Green, Stuart D. | Dikmen, Irem The dominant narrative of project risk management pays homage to scientific rationality while conceptualizing risk as objective fact.

  • Project Management Journal

    Identifying Subjective Perspectives on Managing Underground Risks at Schiphol Airport member content locked

    By Biersteker, Erwin | van Marrewijk, Alfons | Koppenjan, Joop Drawing on Renn’s model and following a Q methodology, we identify four risk management approaches among asset managers and project managers working at the Dutch Schiphol Airport.

  • Project Management Journal

    Collective Mindfulness member content locked

    By Wang, Linzhuo | Müller, Ralf | Zhu, Fangwei | Yang, Xiaotian We investigated the mechanisms of collective mindfulness for megaproject organizational resilience prior to, during, and after recovery from crises.

  • PMI Case Study

    Saudi Aramco member content open

    This in-depth case study outlines a project to increase productivity with Saudi Arabian public petroleum and natural gas company, Saudi Aramco.

  • PM Network

    A certeza da incerteza member content open

    By Fewell, Jesse Por mais que ansiamos por um retorno pré-pandêmico, é ingênuo pensar que as velhas formas de trabalho um dia voltarão - mesmo para o ágil.