This isn\u2019t just semantics either. <\/p>\n\n\n\n
Treating positive risks just like negative ones ensures that you\u2019re ready and able to take advantage of them should they occur, just as it enables you to avoid or minimize the consequences of negative risks.<\/p>\n\n\n\n
In this guide, we\u2019ll teach you all you need to know about risks in project management so that you can analyze them more effectively and prepare a more thorough risk management plan. We\u2019ll focus on the elements that comprise project risks, as well as various ways in which you can categorize risks.<\/p>\n\n\n
![\"Risk](\"https:\/\/plaky.com\/learn\/wp-content\/uploads\/2022\/02\/Risk-in-project-management-cover-1024x512.png\")
<\/figure>\n<\/div>\n\n\nRisk analysis in project management<\/h2>\n\n\n\n
Before you can fix a problem, you have to understand it. Diagnostics are crucial for understanding problems. Just as this is true for doctors and patients, developers and software, engineers and gadgets, it also holds true for project managers<\/a> and project risks.<\/p>\n\n\n\n Risk analysis is the process by which you come to understand how, when, and to which extent the risks you\u2019ve identified pose a threat to your project.<\/strong><\/p>\n\n\n\n \ud83d\udca1 Plaky Pro Tip<\/strong><\/p>\n\n\n\n Knowing what kinds of risks exist and how they could impact your project is a huge part of building your project design. Check out the post below to learn what it takes to master project design:<\/p>\n\n\n\n To help you understand a project risk, it helps to break it down into these six parts:<\/p>\n\n\n\n Understanding these risk aspects will greatly aid you in preparing your risk management plan.<\/p>\n\n\n\n To put it simply, a risk event can be described through the consequence of a risk. In other words, what (bad) things are going to happen if the risk occurs?<\/p>\n\n\n\n Examples of risk events include a hacker attack, a key employee resigning, or a lightning strike frying some electronics.<\/p>\n\n\n\n To put it another way, the thing that most people would have in mind when they say the word risk <\/em>is called a risk event in project management.<\/p>\n\n\n\n Not all risks are as likely to happen. It\u2019s safe to say that miscommunication or equipment malfunction happen much more frequently than lawsuits or earthquakes.<\/p>\n\n\n\n To ascertain the probability of a given risk, you just need to ask yourself how likely it is to happen. <\/p>\n\n\n\n In most cases, risk probability boils down to guestimation. <\/p>\n\n\n\n Some project managers prefer to use percentage values, while others use descriptors like highly likely <\/em>or unlikely<\/em>. <\/p>\n\n\n\n Risk probability doesn\u2019t have to rely on guesswork. By conducting a quantitative risk analysis, you can arrive at more data-driven conclusions.<\/p>\n\n\n\n Risk impact is the estimation of the severity of a risk\u2019s consequences. Risk impacts can range from catastrophic to inconsequential. Much like risk probability, risk impact is most often derived through estimation \u2014 in either percentages or descriptors \u2014 but, the option for a more data-driven quantitative analysis or risk impact does exist.<\/p>\n\n\n\n Risk impact and risk probability are often paired together to create the risk assessment matrix.<\/strong><\/p>\n\n\n\n Risk assessment matrices help you assign overall threat level scores to individual risks so that you can prioritize them accordingly.<\/p>\n\n\n Risk timeframe is a description of when a risk can be expected to happen. <\/p>\n\n\n\n Risk management entails risk monitoring \u2014 but knowing the timeframe for any given risk is can help you focus your efforts. <\/p>\n\n\n\n For example, a server crash due to massive online traffic is a real concern \u2014 but, it\u2019s more likely to happen during large holiday sales than on a random Wednesday afternoon.<\/p>\n\n\n\n Also, there is no need to be jumpy and keep worrying about a certain risk if it\u2019s not going to occur until the project enters its final phase<\/a>.<\/p>\n\n\n\n Risk indicators are portents of impending risk events. They\u2019re the signals that indicate a risk event is looming on the horizon and that you should be prepared to react to it.<\/p>\n\n\n\n So, if the flu season rendering a large part of your workforce bedridden constitutes a schedule risk for your project, then news of cases outside the office could serve as early risk indicators.<\/p>\n\n\n\n That being said, risk indicators aren\u2019t always followed by risk events. They only serve to forewarn you of risks potentially materializing in the near future. <\/p>\n\n\n\n Let\u2019s illustrate this.<\/p>\n\n\n\n Dark clouds are an indicator of rain. Sometimes, these dark clouds pass overhead without producing so much as a droplet. But to see dark clouds and ignore the chance of rain entirely would be tantamount to turning a blind eye to a risk indicator in project management.<\/p>\n\n\n\n A risk trigger is a switch that, when flipped, turns a potential risk into a tangible issue.<\/p>\n\n\n\n If the risk event is getting shot \u2014 excuse the violent analogy \u2014 the risk trigger would be pressing the actual trigger. <\/p>\n\n\n\n A single risk event can have multiple risk triggers. <\/p>\n\n\n\n Also, while risk triggers are often designated during risk identification, this isn\u2019t always the case.<\/p>\n\n\n\n For effective risk management<\/a>, you should review risk triggers from time to time and update them if necessary.<\/p>\n\n\n\n Now that we have understood the elements of risk in project management, let\u2019s see how we can categorize risks. For the purpose of this guide, we have categorized risks in project management as inherent and thematic risks.<\/p>\n\n\n\n \n Keep track of project risks and all their elements in Plaky.<\/p>\n\n Not all risks are made equal.<\/p>\n\n\n\n Just to name some of the more prominent types of inherent risks, we have:<\/p>\n\n\n\n Understanding these risk categorizations will help improve the execution and effectiveness of your risk management plan.<\/p>\n\n\n\n On top of this, we can also divide risks into any number of thematic categories, like cost risks, technology risks, strategic risks, and so on. Further below we\u2019ve provided 15 examples of thematic risk categories that are aimed to help you identify more risks. <\/p>\n\n\n\n These thematic risk types are different from inherent risk types in that they aren\u2019t as well defined and often feature overlap. With inherent risks, a risk is either known or unknown, positive or negative, primary or secondary \u2014 there is no middle ground.<\/strong><\/p>\n\n\n\n We should also note that the inherent and thematic risk categories aren\u2019t mutually exclusive. Namely, you can<\/em> attribute descriptors from each category to a risk. <\/p>\n\n\n\n For example, it\u2019s possible to have a negative, known, secondary technological risk.<\/p>\n\n\n\n The first category divides all risks into positive and negative ones.<\/p>\n\n\n\n Positive risks<\/strong> <\/em><\/strong>are those risks that, if they happen, will have a positive impact on the project. They help you finish the project quicker, make it cost less, or have any other positive effect.<\/p>\n\n\n\n Negative risks <\/strong>are those risks that, if they happen, will have a negative impact on the project. They make you miss the deadline<\/a>, incur extra costs, lower the quality of the product, and so on.<\/p>\n\n\n\n The main advantage of risk management is the ability to take a proactive approach to managing risks. <\/p>\n\n\n\n However, you can only proactively manage the risks that you\u2019ve identified. Even with extensive risk management and the best PM helming the project, an unknown risk will force the team to respond to it reactively.<\/p>\n\n\n\n These two risk response types \u2014 proactive and reactive \u2014 constitute the first paradigm for categorizing risks. <\/p>\n\n\n\n Known risks<\/strong> are those you can manage proactively. They are the risks you\u2019ve predicted and accounted for by, among other things, defining their risk event, probability, impact, etc.<\/p>\n\n\n\n Unknown risks<\/strong> are those that demand a reactive response because you\u2019ve failed to predict them. They spring out of nowhere and leave you scratching your head, wondering what happened. Sadly, the only way to learn what unknown risks are is to fall victim to them.<\/p>\n\n\n\n Some project managers choose to call risks unknowns<\/em>, leading to the existence of confusing terminologies such as known and unknown unknowns. The reasoning behind this is that, while you may predict that a product will encounter bugs during testing, you don\u2019t know how these bugs will manifest \u2014 they are known unknowns. And if you get hit by a lawsuit that you didn\u2019t see coming, well that\u2019s an unknown unknown. It\u2019s confusing, and we don\u2019t recommend using this terminology \u2014 but you can encounter it so it’s good to be equipped with this knowledge.<\/p>\n\n\n\n Each project starts with a few known risks and plenty of unknown ones, but as you progress with risk management planning, the known risks should greatly outnumber the unknown ones. In an ideal case, you\u2019d identify all potential risks, leaving the percentage of unknown risk at 0%.<\/p>\n\n\n\n In a category of their own, we have primary risks, secondary risks, and residual risks<\/a>.<\/p>\n\n\n\n Primary risks <\/strong>are the risks you\u2019ve identified and designated with a risk event, probability, impact, and so on. Unless stated otherwise, assume that the term risk <\/em>implies primary risks, just as it usually implies negative risks.<\/p>\n\n\n\n Secondary risks<\/strong> are those risks that stem as a consequence of risk management implementation. In other words, risks that occur as a consequence of responding to a primary risk are called secondary risks. <\/p>\n\n\n\n Let\u2019s say you switch to using a new team communication tool to reduce costs only to have it be plagued with crashes and downtime. The issue \u2014 crashes and downtime \u2014 are something that would have never occurred if not for your risk management efforts, making them the impact of a secondary risk.<\/p>\n\n\n\n Residual risks<\/strong> are the threat that remains even after you\u2019ve implemented your risk response plan. Mathematically, they could be expressed as:<\/p>\n\n\n\n Residual risk = risk – risk response<\/strong><\/p>\n\n\n\n To give a concrete example, let\u2019s say you impose contractual penalties upon the shipping company responsible for delivering your product to retailers. These penalties reduce risk probability, but not risk impact. Therefore, this risk response plan leaves you with some residual risk.<\/p>\n\n\n\n Now if the risk you\u2019re combatting is equipment malfunction, and your risk response includes having redundant equipment on standby, then the residual risk is low or non-existent.<\/p>\n\n\n\n Residual risks and secondary risks are often mixed together, but they are fundamentally different. <\/p>\n\n\n\n You\u2019ll often hear that the three types of project risks are cost risks, schedule risks, and performance risks.<\/strong><\/p>\n\n\n\n This division is perfectly valid, as it closely ties to the triple constraint theory<\/a> which states that the project budget, timeline, and scope are linked to project quality and that a change to any one of them will affect the others.<\/p>\n\n\n\n But, limiting yourself to only these three risk categories doesn\u2019t really help you identify risks any easier. Therefore, we like to place them into a category of thematic risks. This isn\u2019t an official PM term, but we call them thematic<\/strong> as this name evokes the sense of direction from which risks can emerge. <\/p>\n\n\n\n So, to facilitate your risk identification process, we\u2019ve provided 15 different thematic categories that risks could fall under:<\/p>\n\n\n\n One of the best ways to improve your risk identification skills<\/a> is by going through this list and finding as many risks for each category. This allows you to comb through a wider range of risks than you could without using such a structured approach.<\/p>\n\n\n\n You\u2019ll frequently find that some examples of risks given to portray risk categories could fall under several categories. <\/p>\n\n\n\n For example, a product name dispute lawsuit could be a cost risk<\/strong> (regardless of whether you win or lose the lawsuit), a schedule risk<\/strong> (if you are forced to push back the product release due to the lawsuit), or even performance risks<\/strong> (in cases where the attention of the general public gets drawn to it), in addition to being a legal risk<\/strong>. <\/p>\n\n\n\n So, there can be overlap<\/strong>.<\/p>\n\n\n\n Provided below are some of the more common risk categories that will help guide your risk identification efforts in the right direction, starting with the three most common ones.<\/p>\n\n\n\n Cost risks are all risks that have the potential to make you go over budget (or under budget, if we\u2019re also taking positive risks into consideration)<\/strong>.<\/p>\n\n\n\n From the very outset, poor budget planning<\/a>, and sloppy execution are bound to leave their mark on a project. Let\u2019s take the infamous FiReControl<\/a> project as an example. The goal of the project was to develop control hubs for the fire brigade in England. The original cost estimate of the project was \u00a3120 million, but at one point threatened to cost \u00a3635 million.<\/p>\n\n\n\n How did this happen? <\/p>\n\n\n\n Apparently, the department in charge of the project thought IT development would be smooth sailing and began the endeavor with quite unrealistic expectations \u2014 which quickly built costs. <\/p>\n\n\n\n And that\u2019s just one example. Plus, poor budgeting isn\u2019t always the root cause of the problem. Scheduling issues often also constitute a cost risk, as the people working on the project need to be compensated for their prolonged work.<\/p>\n\n\n\n Likewise, schedule risks are all risks that affect the project timeline<\/a><\/strong>. Implementing a new piece of software or equipment that can help in reaching the project deliverables<\/a> sooner is one example of a positive schedule risk<\/strong>. <\/p>\n\n\n\n In most cases, though, you\u2019ll be dealing with negative schedule risks:<\/p>\n\n\n\n Performance risks don\u2019t have to do with the performance of the team working on the project \u2014 this falls under schedule risks. <\/p>\n\n\n\n Instead, performance risks are all about the quality of the project deliverables<\/strong>. <\/p>\n\n\n\n Anything that can impact the desired quality level of the project deliverables is a performance risk: <\/p>\n\n\n\n Sometimes, schedule risks bleed over into performance risks, which is often the case with a time crunch.<\/p>\n\n\n\n Let\u2019s say you\u2019re trying to make an ultra-durable smartphone. Outside of making it waterproof, dustproof, and otherwise resistant to the elements, the smartphone isn\u2019t supposed to have any fancy features. Everything is agreed upon and the project gets underway.<\/p>\n\n\n\n Then, a call gets made to add support for a smart assistant or to add a gyroscope \u2014 something that wasn\u2019t part of the agreed-upon project scope. This is a classic case of scope creep<\/a> \u2014 the requirements increase after the plan has already been made<\/strong>.<\/p>\n\n\n\n The addition of new features is one of the more common causes of scope creep, but it can also come about as a result of poor communication with stakeholders<\/a>, having a poorly defined project scope in the first place, or any other reason.<\/p>\n\n\n\n \n Keep scope creep at bay while improving project workflows with Plaky.<\/p>\n\n You could have the most skilled workers in the world, but that wouldn\u2019t matter one bit if the work they\u2019re doing is based on miscommunication. Theoretical frameworks of communication<\/a> break this process down into at least 8 elements:<\/p>\n\n\n\n As you can see, there are plenty of stops along the way where the intended meaning can get distorted. Perhaps you won\u2019t phrase it properly (encoding), you\u2019ll opt for verbal communication for complex ideas where a message would have been more apt (channel), or maybe the message recipient will simply interpret the message incorrectly (decoding).<\/p>\n\n\n\n Miscommunication can occur between the PM and stakeholders, the project team, or any other party. <\/p>\n\n\n\n The important thing to remember is that communication risks can easily happen in any project and that their impact can range from negligible to quite problematic.<\/p>\n\n\n\n To avoid communication risks, you could establish communication protocols, like asking the message recipient to reiterate what they\u2019ve heard. It will feel a bit unnatural at first, but you\u2019ll quickly get used to it. <\/p>\n\n\n\n Anything that can lead the project deliverables to suffer from prying eyes (and hands) is a security risk<\/strong>. <\/p>\n\n\n\n Information leaks, hacks, or even theft, are all security risks that can negatively impact projects.<\/p>\n\n\n\n As an example of a security risk, let\u2019s look back to the spring of 2020, when the hotly anticipated sequel to PlayStation\u2019s hit video game The Last of Us<\/em> was gearing up for release.<\/p>\n\n\n\n Months ahead of the game\u2019s release, the plot of the game was leaked, causing a large controversy over the death of a fan-favorite character. <\/p>\n\n\n\n The game went on to be a critical and commercial success despite this setback \u2014 but needless to say, the road to get there was less than ideal, due to breached security.<\/p>\n\n\n\n Safety and health risks constitute all risks that could endanger the safety of workers and\/or consumers. <\/strong><\/p>\n\n\n\n For example, a risk with mercury-in-glass thermometers was that, should they break, the consumers would be exposed to mercury. This is why everyone avoids that risk and makes electronic thermometers nowadays. <\/p>\n\n\n\n Nowadays, a common safety risk is the presence of toxic elements used in most QLED displays. Although Samsung has made QLED TVs without these elements<\/a> \u2014 making them 100% safe for consumers \u2014 the sales are still low due to the negative public perception of the technology as a whole. <\/p>\n\n\n\n In this case, we can see that health and safety risks can cause a problem for projects even when there aren\u2019t actually any health and safety risks involved.<\/p>\n\n\n\n Failing to account for such risks will negatively reflect on the project, either by:<\/p>\n\n\n\n Technology risks include a plethora of different risks intended to help guide your risk identification efforts in the right direction.<\/strong><\/p>\n\n\n\n This is because anything relating to technology can be seen as a technology risk. Some of these risks could even be labeled under multiple categories.<\/p>\n\n\n\n For example, data security issues can be seen as both technology risks and legal\/regulatory risks. <\/p>\n\n\n\n Technology risks also include service outages, like your cloud storage provider losing your data or your server provider failing to maintain uptime on your website.<\/strong><\/p>\n\n\n\n New software implementation is often perceived as a risk due to the costs associated with it, as well as the need to train employees to use said software.<\/strong><\/p>\n\n\n\n All of the previously mentioned examples refer to forces outside your influence<\/em>, so to speak, but technology risks aren\u2019t always someone else\u2019s fault. <\/p>\n\n\n\n If you roll out a software product that suffers from frequent crashes, it can take months to repair the PR damage after fixing the crashes.<\/p>\n\n\n\n Resource risks are exactly what they sound like \u2014 risks that threaten to prevent you from completing a project (or keeping it on track) due to a shortage or unavailability of essential resources. <\/strong><\/p>\n\n\n\n Imagine if you needed to make and ship out 50 million gaming consoles but a shortage of microprocessors bottlenecked your production. <\/p>\n\n\n\n This is a resource risk, and you can tackle in the following ways:<\/p>\n\n\n\n In any case, categorizing this (and all similar cases) as a resource risk is much more conducive to risk identification and risk response planning than if you were to limit yourself only to cost, schedule, and performance risks.<\/p>\n\n\n\n Most companies have a clear strategic vision when they commence work on a project \u2014 and if they don\u2019t, they should. The project deliverable and the strategic vision of the project can be two separate things<\/strong>. <\/p>\n\n\n\n For example, a project deliverable could be to develop and maintain a cloud storage service. <\/p>\n\n\n\n And, here are three very different strategic goals for this project:<\/p>\n\n\n\n The product being developed could be exactly the same in all cases, but you would have to react to external stimuli differently depending on your strategic goal. <\/p>\n\n\n\n For example, if a new competitor were to blast onto the market with an amazing cloud infrastructure, you\u2019d feel much worse about it with number 2 and 3 strategic goals than with the number 1 goal.<\/p>\n\n\n\n Operational risks include any issue that stems from the company\u2019s business as usual. <\/strong><\/p>\n\n\n\n Perhaps the workflow is just not efficient enough to accommodate the needs of the project. This may require some changes, but changes bring with them their own operational risks.<\/p>\n\n\n\n This can include changes in:<\/p>\n\n\n\n The result of any of these changes will likely be confusion and adjustment periods, during which the project will not get its timeline paused.<\/p>\n\n\n\n We\u2019ve mentioned legal\/regulatory risks as part of other categories, but they really are deserving of their own category. They are also a broad category \u2014 legal trouble can come from the state, from competitors, unrelated third parties who aren\u2019t even competitors, or even the organization\u2019s employees<\/strong>.<\/p>\n\n\n\n S<\/strong>imilar to legal risks are regulatory risks<\/strong><\/a> are \u2014 but they\u2019re more focused on the product than the company<\/strong>. <\/p>\n\n\n\n This is especially the case with many innovative IT projects that depend on data security and privacy protection. When developing something new, there is always a chance that the project deliverable is going to be at odds with some regulations. <\/p>\n\n\n\n For example, if you\u2019re selling your product in different countries, you need to account for their varied laws.<\/p>\n\n\n\n In other words, the trouble with legal and regulatory risks is that they can stop the project dead in its tracks, which is why it\u2019s crucial to consider how any project fits into the legal and regulatory constraints in their markets.<\/p>\n\n\n\n Every project product can be made to look great in a vacuum. In all likelihood, it will be competing against other, sometimes more popular and well-established, competition.<\/strong><\/p>\n\n\n\n Unfortunately, it\u2019s often not enough to simply make a good product or offer a good service and expect the rest to work itself out. A project geared for success will take the volatility of market changes into consideration.<\/p>\n\n\n\n Remember that a risk isn\u2019t necessarily a bad thing in project management. You should be ready to respond to positive market risks that can undermine your competition.<\/p>\n\n\n\n External hazard risks are a perfect example of risks you cannot prevent. <\/strong><\/p>\n\n\n\n All you can do in the face of storms, floods, and earthquakes is have a solid response plan in action. <\/strong><\/p>\n\n\n\n Not having your office on the ground floor helps mitigate the negative effects of floods, for example. <\/p>\n\n\n\n Setting up shop in an aseismic building can greatly reduce the impact of earthquakes on your project. <\/p>\n\n\n\n And having a server room power generator can help projects stay on track even through power outages that frequently accompany storms.<\/p>\n\n\n\n These are just a few ideas of what constitutes an external hazard risk and how one might go about dealing with them. <\/p>\n\n\n\n Do keep in mind that external hazard risks aren\u2019t limited to natural disasters \u2014 armed robberies or terrorist attacks could also be categorized here. <\/p>\n\n\n\n Not every project needs a response plan for all external hazards \u2014 but it\u2019s best to stay aware of these things.<\/p>\n\n\n\n Project deferral risks are all risks that can stem from a project being put on hold.<\/strong><\/p>\n\n\n\n Leadership greenlights projects, but it also has the power to put them on hold for whatever reason. <\/p>\n\n\n\n But not all projects handle being put on hold equally. <\/p>\n\n\n\n Some projects get exponentially more expensive as they get prolonged. <\/p>\n\n\n\n Others may suffer from a limited window of opportunity to achieve their maximum effectiveness.<\/p>\n\n\n\n For these reasons, understanding how big of a risk deferral poses to your project is crucial and can offset some of the drawbacks associated with said deferral.<\/p>\n\n\n\n It only takes one sentence to define risk in project management:<\/p>\n\n\n\n Risk is anything that can affect the project, either positively or negatively.<\/p>\n\n\n\n But knowing what risk is and how to identify it and mitigate it are as different as knowing what a computer is and knowing how to fix one.<\/p>\n\n\n\n Keeping the 7 types of inherent risks and 15 thematic risk categories listed in this guide with the examples we\u2019ve provided will help you identify a larger pool of risk for your projects. <\/p>\n\n\n\n Get started with Plaky<\/a><\/p>\n\n\n\n \ud83d\udcd6 Risk is just one of the terms that doesn\u2019t have an identical meaning in project management from its standard dictionary definition. You can learn more about similar terms, and many others, from our Project Management Glossary of Terms<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Comprender el riesgo es esencial para una gesti\u00f3n eficaz. Aprende todo sobre los riesgos del proyecto aqu\u00ed.<\/p>","protected":false},"author":6,"featured_media":7323,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[6,4],"tags":[],"class_list":["post-460","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-basic-terminology","category-project-management"],"acf":[],"_links":{"self":[{"href":"https:\/\/plaky.com\/learn\/es\/wp-json\/wp\/v2\/posts\/460","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/plaky.com\/learn\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/plaky.com\/learn\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/plaky.com\/learn\/es\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/plaky.com\/learn\/es\/wp-json\/wp\/v2\/comments?post=460"}],"version-history":[{"count":33,"href":"https:\/\/plaky.com\/learn\/es\/wp-json\/wp\/v2\/posts\/460\/revisions"}],"predecessor-version":[{"id":11648,"href":"https:\/\/plaky.com\/learn\/es\/wp-json\/wp\/v2\/posts\/460\/revisions\/11648"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/plaky.com\/learn\/es\/wp-json\/wp\/v2\/media\/7323"}],"wp:attachment":[{"href":"https:\/\/plaky.com\/learn\/es\/wp-json\/wp\/v2\/media?parent=460"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/plaky.com\/learn\/es\/wp-json\/wp\/v2\/categories?post=460"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/plaky.com\/learn\/es\/wp-json\/wp\/v2\/tags?post=460"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
Elements of risk in project management<\/h2>\n\n\n\n
\n
Risk event<\/h3>\n\n\n\n
Risk probability<\/h3>\n\n\n\n
Risk impact<\/h3>\n\n\n\n
![\"Example](\"https:\/\/plaky.com\/learn\/wp-content\/uploads\/2022\/02\/Risk-assessment-matrix-example.png\")
Risk timeframe<\/h3>\n\n\n\n
Risk indicator<\/h3>\n\n\n\n
Risk trigger<\/h3>\n\n\n\n
\n\n\n\nFree project management software<\/h2>\n
![\"Illustration\"](\"https:\/\/plaky.com\/learn\/wp-content\/themes\/cake-learn\/src\/images\/plaky\/banners\/default@2x.png)
\n <\/picture>\n <\/div>\n<\/div>\n <\/p>\n\n\n\nTypes of risks \u2014 The inherent categorization<\/h2>\n\n\n\n
\n
Positive and negative risks<\/h3>\n\n\n\n
Known risks and unknown risks<\/h3>\n\n\n\n
Primary risks, residual risks, and secondary risks<\/h3>\n\n\n\n
Types of risks \u2014 The thematic categorization<\/h2>\n\n\n\n
\n
Cost risks<\/h3>\n\n\n\n
Schedule risks<\/h3>\n\n\n\n
\n
Performance risks<\/h3>\n\n\n\n
\n
Scope creep risks<\/h3>\n\n\n\n
Free project management software<\/h2>\n
![\"Illustration\"](\"https:\/\/plaky.com\/learn\/wp-content\/themes\/cake-learn\/src\/images\/plaky\/banners\/landing-1@2x.png)
\n <\/picture>\n <\/div>\n<\/div>\n <\/p>\n\n\n\nCommunication risks<\/h3>\n\n\n\n
\n
Security risks<\/h3>\n\n\n\n
Health and safety risks<\/h3>\n\n\n\n
\n
Technology risks<\/h3>\n\n\n\n
Resource risk<\/h3>\n\n\n\n
\n
Strategic risks<\/h3>\n\n\n\n
\n
Operational risk<\/h3>\n\n\n\n
\n
Legal\/regulatory risks<\/h3>\n\n\n\n
Market risks<\/h3>\n\n\n\n
External hazard risks<\/h3>\n\n\n\n
Project deferral risks<\/h3>\n\n\n\n
Conclusion: Understanding project risk is simple, but identifying risks is difficult<\/h2>\n\n\n\n