Often, we give a beautiful technical presentation that goes on for an hour and then towards the last 5 minutes of the meeting the top brass in the room asks “great, what are the risks in this endeavour?”, as if whatever we were talking about up until now was not even remotely interesting. First, let me assure you, whatever we were talking about was indeed not interesting to that specific person 
. Joking aside, it is not that the technicalities are not important but to allow a project to start\continue, the organization, and we as its trusted employees, must understand how and when we get to the finish line of the project and at what cost.
At the outset I have divided this topic into two separate posts since the subject is long and with a lot of info. Note that this post series deals with R&D project risks and not product risks, i.e., what could happen in our project that would prevent us from reaching our goal in time or in budget. In other words, the possibility that the user may get electrocuted and die is indeed a risk, however that is not the kind of risks we are dealing with here. These will be covered in other posts.
Definition of a risk
According to the Cambridge dictionary a risk is:
Risk
“The possibility of something bad happening.”
“A risk is also someone or something that could cause a problem or loss”
That’s beautiful! However, the definition of “bad” or “problem” is a bit obscure. So, in project management, technical or non-technical, we first have to define for ourselves what is “good”. Any deviation from that is either a problem or bad.
A risk is always defined by its impact on the project or product in development. It is easy to think of a risk in a pattern of cause – “if x happens” and impact “then y will be changed”. A risk with no estimated impact is not a risk, it is no more than a premonition.
For example, if we took a fabric defect identification vision system and we defined that all defects are to be detected then a risk may be that if the vision system’s optical resolution is 0.2mm and above then defects in fabrics made of thin wool of 0.1mm diameter will be missed in 90% of the cases.
Unmapped risks may cause a whole project failure
Before we go into the different types of risks let’s dwell a bit on the importance of risks in a project. In each stage of a development project, we have to convey to the project management what is left on our table to finish, what resources we need and how much time we require. In a perfect world, that would be enough. However, in reality things sometimes do not work as we would like them to, and we have to plan for these deviations. Furthermore, in each step we would like to map for ourselves how risky it is to continue with the project. If for example we started working on a completely new laser diode that has to reach the market in 6 months we would say it is risky, to the brink of impossible (and you all know that I think nothing is impossible ). If we do not map these as risks and assess them, we may get to all kinds of project failures and even company closure. Our job, as technical leads, is to convey the message at all times – this is risky; that is safe; we can do that in-time and on-budget; etc. That way the project management can flow smoothly and even when surprises crop up (as they ALWAYS do) we have some kind of a mechanism to deal with them so that a total catastrophe does not occur.
Risk Types
There are different types of risks to the project which impact the project development, each should be handled differently.
Technical risk
A technical risk is a situation where a technical aspect of the project might not meet the desired requirement. The if clause of a technical risk is by definition numeric: “if the system cannot meet 500lp/mm optical resolution”; “if the system’s chiller cannot dissipate 100W/hour” etc.
Timeline Risk
A timeline risk is the possibility where whatever we assessed as the timeline of a certain part of the project would take longer. For example, “if the algo development takes 12 weeks instead of 8” or “if the lens is delivered by the supplier in April instead of February”.
Do not confuse technical risks that eventually mitigate to timeline impact with timeline risks. Timeline risks are not technical risks – in timeline risks given enough time we could meet the system requirements according to the technical plan, while technical risks if materialized cause a situation where the system does not meet certain requirements. If there are mitigations, and these mitigations take a long time – that is a new risk already. But any mitigation is not the best technical option, otherwise we would have taken it to begin with.
Costs Risk
Cost risk is translated directly to money, including timeline or technical risks’ mitigations. Do not count the project’s delivery date itself as costs risk (this is covered in timeline risks), but its derivative that may add extra costs we need to count under our overall costs’ estimates. For example, “if the cost of SW engineers is doubled because 2 software engineers are needed for Q2 instead of one” is a very good example of a timeline risk which mitigated into a costs and monetary budget risk. An additional example: “if disposable materials (cleaning liquids, protective windows, optical mats) costs for Q3 is greater than 3,000$US”.
Market Risk
Market risks are the risks from the outside world that impact our product development. This is the kind of risks where we have little to no control over if they happen or not. The only control we have is over the mitigation. For example, if our competitors beat us to the market with a certain feature that may impact the whole project; if regulation in a certain target country is changed just before we launch a product it is a risk; if we end up with a product BOM that is too high for the market (in spec!) that may also change the contents of a project.
A note regarding product costs: there are two common approaches to final product costs risk assessments during development. The first approach deals with anything that has to do with the final client in the market risks (see below). The second approach calculates all the costs risks including the final product sale price under the costs risks section. To be frank, there is not much difference, as long as you take the risks into account it does not really matter under which topic you gather these risks. I personally prefer the first approach hence it is detailed here in the Market risks.
Risk Impact and Severity
Up until now we have spoken about the first half of a risk clause – the “if” part. The risk impact is the “then” bit. The “then” should tell us as accurately as possible what would happen if the risk materializes.
- Technical risks will show impact on requirements in requirement units on development tasks in terms of additional tasks that were not accounted for in the original development plan.
- Timeline risks will show the delay in days\weeks\months on project deliverables.
- Costs risks will show deviation in whatever currency we are working with vs. our budget.
- Market risks impact is usually translated to additional tasks, but not always. They could be anything since they can trump any other activity we have in the project.
Whenever possible the “then” must also be quantitative (in market risks this is very difficult to come by).
Proper risk formulation: “if… then…”
Eventually we would like to have a table with all the risks, in descending order of highest to lowest risks. To do that we must somehow convert any risk to a numeric value.
If we have done our homework correctly, we should have a scale for the technical, timeline and costs impacts, such that for each impact assessment we could give a numeric score for our overall risk assessment. Highest score usually indicates the highest impact and the greatest risk. You may choose whatever linear scale you like since it makes no difference mathematically. Make sure you have enough discrete scores for all your needs on the one hand, but on the other hand not too many so that there would be no significant difference between two adjacent scores. I personally like a 1-5 scale, which is wide enough for nuances but not too wide for redundant scores.
For example, over an estimated 1-year project, a delay of less than 2 weeks will be the score of 1, 2-4 weeks, score of 2 and so on. So, for a “then” of 6 weeks we could score the impact as 3.
Risk Probabilities
Knowing the impact of some hazard is not enough. The best example is Armageddon: if a meteor hits earth, then it will be the end of mankind. That would definitely get the highest impact there is, wouldn’t it? If we could ask the dinosaurs, they would probably agree with this statement. However, what is the probability of such an event? Hmm… slim at best. That is why each time we assess a risk impact, we must also assess what is the probability of that risk materializing. For example, if we have a risk like “if manufacturing of the prototype’s Aluminum mechanics takes more than 10 weeks then we miss the June deadline” which would have a terrible impact since we would lose the market. However, since we have been working with this Aluminum manufacturer for years and the longest it has ever taken them to manufacture anything was 8 weeks, so we would give this risk a very low probability, to accommodate that this is certainly a very low risk.
For this, again, we should have a table which gives a score to each probability, for example 0-10% change will get the score of 1, and above 75% will get the score of 5. BTW, the score of 0 probability would be given to a risk that has already been mitigated – we will get to this later. What if we do not have an estimate for the probability? We then decide in advance how we quantify unknown probabilities. A good probability score for unknowns is the middle of the scale, i.e., score of 3 for a 1-5 scale.
A whole risk assessment – setting a score that combines the probability and impact
If we go back to assessing the whole risk, a good and common way to have an overall risk score is a multiplication of the risk’s probability with the risk’s impact; that would give us a score of how dangerous each risk is. There are other metrics that could be used, for example is a risk impact sensitive systems a multiplication of the risk’s probability by the square of the risk impact could be used. These are very type specific and project specific methods which are not commonly used.
Again, I personally prefer the 1-5 score table for impact and priority where the overall risk score is a straight multiplication of the two, so each risk gets a score between 1 and 25. With this scoreboard, any risk score equal to or above 15 is a top priority risk i.e., red color, risks between 9 and 12 (13,14 are not possible scores in this scoreboard) will be medium priority risks with yellow color and 8 and below are low priority risks (green). It is then easy enough to understand immediately which risks we attend to first. Take a look below at Wile E Coyote’s risks in the overall catching the Roadrunner project.
It is important that the scale will reflect the logic of the risks. If in our opinion a risk is minor but its score is high, either our scale is off or our markings of the impact\probability is incorrect. In the table above, if we had gotten a risk that the bomb would explode exactly in the right spot and the Roadrunner finally gets caught with the probability of 5 that wouldn’t have made any sense and we would have to reconsider this score.
That’s it for now. We covered the basics of project risk types and a method to reach quantification and scoring of the different risks. This is the first of two posts covering project’s risks. In the next post we will cover risk mitigation and methods to assess and manage the different risks during project development.