An integral part of project risk management is how we handle the risks, how we constantly maintain the risks and how we manage the project according to the different risks in terms of the project development processes and integration. This is the second part of a 2-part post series regarding project risks. If you haven’t as yet read the first post in the series I strongly suggest that you do, since most of this post’s contents will be based on the topics already covered in the previous post.
After we have identified the different risks of the project, we must decide what to do with them. In this post I will demonstrate what risk mitigations are, how to manage the risks and mitigations during the development process and some good practices.
Risk Mitigations
Once we have a risk with an overall risk level that is either high or medium, we have to create a list of action items to prevent this risk from materializing, or at least reduce its probability of materializing. For example, in a timeline risk a popular mitigation is hiring more staff or borrowing personnel from other project from within the company. Let’s take another example for a costs risk: to re-negotiate a certain vendor for the item price or find an additional vendor for the same item.
It is important though to make sure that the risk mitigation solves the risk and not the risk impact! For instance, if we had a risk such as “if 2 lenses are required instead of one, then the optical box will be longer than 100mm that was spec’ed” then the mitigation cannot be “make the optical box 100mm longer” – if we made the optical box a 100mm long it means the risk is materialized and we have not done a good job preventing it.
Always have mitigation planned for high risks
A mitigation cannot, by definition, reduce the risk’s impact. When the risk materializes its impact is what we mapped when we formulated the “then” clause. A mitigation can and should reduce the odds that the risk would become a reality. So in our 1-5 scale, if we have a risk with an impact score of 3 and started with a 75% chance of the risk materializing, which probably translated to a score of 5, and reduced it to a 10% chance which translates to 1 then the risk overall score after mitigation goes down from 15 to 3. One thing to remember about risk impacts is that a risk that has no possible mitigation by an effect has to get quite a high impact ranking. If we think about it, that makes sense. It means that something may go wrong in our project without us being able to do anything about it.
Each mitigation must have an owner and a due date and these tasks have to be taken into account as an integral part of the project. A mitigation without an owner or without a due date is in itself as if there is no mitigation and the risk will live in its original state and not as a risk with mitigation. A risk that was already completely mitigated would get a probability score of 0.
If we expand the risk table of our colleague Wile E, it would look something like this:
What if we have a risk with a very high probability and a disastrous impact – how do we prepare ourselves for the risk materializing? We add this risk as a separate risk to our risks list, where its “if” clause is the “then” clause of the original risk, and its base probability is the mitigated probability of the original risk. However, it may create some kind of duplicated entries in our risk list but is the correct and organized way to do it. See in our Wile E Coyote example the entries regarding the explosive malfunction.
Risk Assessment Methods
Up to now we have been discussing the “what” in a risk assessment. In the next section I would like to discuss the “how”. When approaching the project, we should take the assessment itself with each and every project goal and imagine what the perfect route to this goal would be. It is then easier to assess the risks as any deviation from that perfect route. In other words, the “if” should be mapped directly against the project goals and milestones.
The impact and probability are more challenging.
Budget risks impacts are usually the easiest to assess – we will need more money 
How much more, is an estimation task in our monetary budget to which we will not go into in this context.
Technical risks’ impact is also somewhat easy to assess: if we cannot make such and such requirement to the full, we would need some kind of a deviation from the original technical plan we had. It becomes difficult when we have to assess its probability – in most cases we would score it according to our past experience and according to the complexity of the original “if”. Complex development processes we would rank as high probability of failure.
Market risks will usually be devised by Product \ Marketing \ Management, but not only (see below). These risks are not carved in stone and their impacts are difficult to predict. We should take the market risks very seriously but we must remember that we may continue safely without having a definite impact stated for market risks simply because of the difficulty to assess its direct impact and its probability.
Finally, timeline risks: lead time of hardware that was ordered is a banker – we know the longest it should take since the vendor has committed to it in his quote (take 10% spares!!!), and anything sooner would get us to a better state than when we had started. Effort assessment is however, an art. Try as we can, we quite often get it wrong. I would dedicate a post for why complex projects usually get delivered late.
Each team manages their own discipline’s risks
To accurately assess project risks we must assemble the whole team’s risks together and put them in a big table. If we reflect back to the roles of a System Engineer in a project, risk evaluation and follow up are a very important part of it. Does that mean that each and every bit of risk in implementation in SW has to be managed by the System Engineer? Certainly not. Each technical team has to maintain their own risks. So where is the limit? When do we follow up a technical risk related to a certain technical (or even non-technical) discipline? The rule of a thumb is in the technical impact: if other technical disciplines are impacted by that technical risk, it should be included in the project risks and followed by the System Engineering team. Same goes for timeline risks – when a project’s milestone is impacted by a certain risk the System Engineer should also follow it. Note the use of the word “follow” – the ownership of the risk handling, prevention and mitigations is probably not held by the System Engineer, but it’s the System Engineer’s responsibility to communicate this risk and assess its impacts constantly.
Good practice for this assessment task is to have each R&D related team initially make their own risk list and then sit down with each team to identify the highest impactors (don’t forget the supply chain!! they are very often left out in the early risk assessment meetings and a lot of timeline risks could be mapped correctly by consulting with them). Once the detailed picture with each team is clear, we assemble all the team leaders into the same room and together discuss the highest impactors. This is a method that covers most of the risk mapping in an efficient way since there are not too many multi-participant meetings. It is also a good solution as to how to compensate for team members’ inexperience – on more than one occasion I have attended such meetings where more experienced team leaders of a specific discipline identified unmapped risks for other disciplines. In addition, a lot of previously unmapped marketing risks found their way into the list at such meetings as part of the brainstorming process, so remember to share the risk assessments with the Product management as well.
Risk Management during the project
Risk management is tedious. We have to keep the project risk table alive and updated at all times. It means, in practice, that every now and again we must assemble the whole project’s team re-review all the risks in our risk table and see if the mitigations were carried out, if old risks were crossed off the list and of course whether new risks were added to the list and communicate our results to the project management. That is of vital importance in cases where the different tasks and action items (and by that, the risk mitigations) of the different team members are not managed in an orderly manner – and the fact that you use some kind of task management software such as asana, Monday.com, MS Project, Jira, Trello etc. does not mean that the tasks are managed properly, it only means that you have the tools to do so. I have personally seen a very talented R&D manager who used a simple excel sheet and all the tasks were managed perfectly in that organization.
The frequency of having the risks reviewed is project dependent. There are three events that must be accompanied with risk review: project initial planning when embarking, project milestones and project gate\phase exists. Other than that, it totally depends on the System Engineer or the Technical Lead of the project. I recommend having risks assessment each time a high score risk reaches its mitigation due date. Plan the mitigations timeline such that at least a few finish at the same time, which will prevent you from having risk assessment meetings every week. In addition, I would briefly go over the risks periodically so that in the planned time span of the project the risks would be reviewed at least 5 times periodically, so a 10 months’ project would be review every 2 months.
Risk Driven Project Planning And Risky Projects
If we take the complexity of the example one notch higher, for example a case where in the integration of the first alpha we have 3 different mitigation tasks however, the SW team needs a working electronics board to continue working otherwise they would not be able to deliver the final project SW on time (this particular case is based on real events). We are trapped. On the one hand the mitigation tasks are critical to the project’s timeline and budget, on the other hand if we do not hand in the required hardware to the SW team in time, we would have another problem on our hands! The way to approach this situation is already prescribed: we add an additional risk which may not have been foreseen there before, a timeline risk regarding SW delivery. This way, when we plan the integration phase we take into account this issue in our priorities and preferences. BTW, in that particular project SW indeed got their electronics board first as their overall timeline impact on the project was greater than all other risks. Reading between the lines, in a way, we claim that the planning of the project is done twice (at least): once before we assess all the risks of the project and then when all the risks and mitigations are inserted as an integral part of the project. Sometimes it is even more than twice, if new and high impactor risks are discovered during development.
When planning the project development process, we have to take into account the project risks. A straight forward example would be if we had a technical risk that prevented us from delivering a working product. In such cases we must mitigate the risks as soon as possible in order to save time and money. When it comes to multidisciplinary projects this issue becomes a bit more complicated. We wouldn’t want to hold the entire project if there was a technical risk in the electronics that had to be mitigated. That’s exactly where the project development process comes into play. In such a case we would recommend having the electronics team start their project with a quick prototyping model, while the rest of the teams continue their own business in a classical V-model.
There is a very important message here. In the process of understanding how the risks and their mitigations fit into the project development plan we sometimes may conclude that a certain project is too risky and maybe even decide not to proceed with the project plan at all. If we get to a point that we need 10 prototypes going for a medium-sized project for risk mitigations only it might mean that we rushed into a full-blown project too soon. In addition, it is during the risk assessment when we decide if the project will be labeled as “risky”. When a project is risky the expectation levels from it as well as the head count assigned to it are getting different attention.
To sum up, risks and their mitigations are an integral part of a project planning and a project process. When we map the risks correctly, we have a better chance of reaching the project’s finish line with the right product and to everyone’s satisfaction. I hope my last two posts have given everyone a better understanding of how to approach project risks in an effective way such that your day-to-day work will be smoother and easier.
Last but not least, after being the subject of all the examples in the last two posts I owe dear Wile E the tribute he deserves with the only episode where he finally catches the Roadrunner, with a twist of course. Enjoy.