Let me propose a situation: you’re about two weeks away from completing a project when a panicked developer calls you on the phone and says that the office has been flooded due to a faulty fire control system. You immediately think to yourself: is this an issue or a risk?! OK – “ so you don’t think that at all ” – but how would you define the flooded office? This post on the blog PMtechnix.com discusses the differences between project risks and project issues. To put it simply, a risk is something people are worried about but hasn’t happened. An issue is something that has happened and needs to be handled immediately. Pretty cut and dry, right? Well, consider the difference between a project risk and a non-project risk when reading this statement from the article: “The system we are building is designed for 100 concurrent users, but if we get more than that it might run slow or even crash.” Is that a concern of the project team or not? The answer is no: it’s a concern of the operations team – but that’s not always clear: The source of this confusion is usually failure to distinguish between a project, a product, and a program. A project delivers what is asked for, often a product. It does not make claims about the value or benefits of the product. That is the domain of the program or product owner. Sometimes the project manager, program manager, and product owner are the same person, but often they are not. Risks are documented when they are discovered, most being at the beginning of the project. The probability and impact are assessed and mitigation tasks are added to the project plan. A contingency plan may be created to document what we plan to do should the risk occur. These risks are monitored and updated as needed throughout the project. Should they actually occur, they become issues. A good practice to get in the habit of would be to make sure that your team (and yourself) are clear on what risks and issues are, and which ones fall into the jurisdiction of the work at hand.