Risk taking is considered a skill set of some form. It requires enormous amounts of endurance and perseverance and an overall strategic approach to get something we call a calculated risk. Not everybody is risk averse but they are definitely sure about being on the calculated end of risk. There is risk of reputation, financial risk, risk of business continuity and other types which keep organisations worried and always have an impact on them. 

In service and product related technical engineering, risk can be understood as a mere combination of three different things how severe can be the effect of a potential failure, the probability of failure happening and how can it be dealt with in real time. 

Understanding what does risk look like?

The understanding of risk is different in different scenarios by different people and the way risk impacts a system’s existence. System can be taken here as a discrete product or some business process.The definition of a system here can be taken as a discrete product or a business process. Be aware that we are not talking here about what the possible causes of risks might be, only the potential for the system to fail (or produce undesirable outcomes) based on the decisions we make.

Systems do not fail by themselves, there occurs some sort of independent function failure and it happens to start affecting other nearby functions or somehow interrelated functions. So, conducting a risk analysis at the overall system level doesn’t serve your purpose right, it should be done at a component or minute function level so that later on we can rely on those minute independent systems and make sure they are not impacting other systems. This is a very calculated approach and should be brought to use through risk analysis. This way, even the minor independent functions can be made effective than they can really be and if you look back this seems like the best approach of overall. 

Now you should Analyse what can be the worst 

Risk analysis is more of a formal process which is conducted by teams who are responsible for delivering the final product as well as ensuring the product runs and delivers to stakeholder expectations. If you delegate it to a risk measurement or mitigation team they won’t be able to understand most of the functions and their cruciality to the overall business product. Hence it is recommended to make sure that the risk measurement is being done by people who are entirely responsible and they can segregate, prioritise and plan the course of action as per their derived calculation. 

Taking risks is complex than you would assume and it is done taking various parameters into consideration. A clearly established a set of principles which consist of strong architectural insights and have a clear cut risk rating criteria should be brought in practise. Ratings which provide an explanation for themselves are helpful in nature and they omit the potential bias that may come from different individuals as per their preferences. 

Things you should not do:

1. Not documenting risk management - The importance of documentation cannot be stressed upon, a formal and well documented risk management process enables well structured approach to identification of risk continuously emerging within the organization. 
2. Ignore critical risks because they seem untreatable - Don't ignore risks which look big to you, even though you have no choice but to take it, just don't let it go unaddressed and try to mitigate it as much as possible. 
3. Missing out the risk re-evaluation process - It is supposed to be a continuous activity,risk management. evaluating, prioritising, implementing actions and mitigating in time help improve your evaluation. This process should be repeated wherever feels necessary and can bring something to the table. 

How can you mitigate the analysed risk ?

The best considered way to mitigate any risk is to increase our individual abilities and rational to arrive at better decisions. The ideal risk management process involves a broad experience and knowledge base to turn out to be helpful after it has completed it’s due course. 

The best way to mitigate risks, especially design risks, is to increase our ability to make better decisions. Effective risk management requires immense use of dynamic knowledge and work experience. Some questions you might want to answer in order to understand how to mitigate the propagated risk?

• What could be the possible reason behind the system’s failure. How did a particular component fail ?
• What can be the worst impact of the failure? Or how bad is the failure in nature from the viewpoint of a customer who might encounter the failure while operating the product or system as a whole ? 
• How did the failure occur and what are the possible reasons for it? Which part of the system couldn’t run as it was previously expected to and what made it fail and eventually cause the disturbance across the system ? 
• What is the condition of the controls How good are our controls (for example, automated testing or observability and automated correlation of events) at detecting the failure or the effects of failure ?
• What should be done to mitigate the risk and make sure that it doesn’t What, if anything, should we do to reduce or mitigate the risk? Which steps have been taken to reduce the chance of failure occurring or  enhance our ability to detect failure before it causes considerable damage ? 

Often failures happen in systems which are running live, continuous checks and problem identification can be used to mitigate future such occurrences. Once the root cause of failure is identified, it can be used to make sure that that any similar problems in the future don’t go unattended, they are addressed immediately like they were in the past. 

The remainder

Risk mitigation and management is very complex in nature but it’s sort of an art which can be developed over time. It is more helpful in systems which are too much interrelated and it helps you take risky but calculated decisions and makes sure they are dealt with correctly and don’t go unattended eventually causing harm to the business processes.