Dealing with project risks

No one can see into the future. But that's precisely the task in development projects. We want to develop a product in a development project while staying on budget and on schedule. Yet, there are plenty of imponderables in a project. And that's precisely what's so great about it. It's not for nothing that Tom DeMarco writes in his book *Bear Tango*:

Projects without real risks are losers. They are almost never profitable; that's why they weren't implemented years ago.

In this article, I'd like to introduce you to the topic, true to the motto: "No risk – no fun."

Process steps

Managing project risks is an iterative process that takes place throughout the entire project lifecycle.

Ideally, these steps are repeated several times in the project.

List of risks

Risks are best managed in a table. The probability of occurrence (PV) and impact can be expressed either qualitatively (high, medium, low, or 1, 2, 3) or quantified in percentages and euros.

The risk value is the product of the probability of occurrence and the impact:

Risk value = EW x impact

The sum of all risk values results in the risk inventory. This can be related to the project budget to obtain the risk index. The risk index is a measure of the level of risk contained in the project.

Risk workshop

There are various methods for determining risks. A classic example is a team workshop. Each participant prepares and brings their own risks with them. The risks are then discussed together as a team and an attempt is made to identify further risks. An interesting variation of the workshop is the "disaster" brainstorming session. Here you assume the project has failed or some other disaster has occurred and then determine how it could have happened. It is helpful to talk about a "nightmare" and to appear as the person who has concerns. For once, positive thinking is not called for here. It is also very useful to work with Post-It notes and stick the risks on a pinboard. This motivates everyone to write something down and not just sit there apathetic in front of the note-taker.

I highly recommend creating a risk database. This database contains the risks of all active and completed projects. This database allows you to benefit from the knowledge within your organization. You gain insight into what has gone wrong in the past and can proactively use this information for your project, even before the damage is done.

Dealing with risks

Once the risks have been identified, it's time to consider how to address them. There are the following options:

• Avoid risk
• Transfer risk
• Reduce the probability of occurrence
• Reduce impact
• bear risk

Avoiding risk is, of course, the best course of action. However, this option isn't always available. Risk transfer involves transferring the risk to suppliers or insurers. It's also possible to exclude risks through contractual agreements (e.g., patent risks). If the risk cannot be avoided, it may be possible to reduce its probability of occurrence or its impact. It may well be that a risk is acceptable and accepted.

When deciding how to deal with a risk, the probability of occurrence and the impact play an important role. The higher the impact or probability of occurrence, the more attempts will be made to avoid or transfer the risk.

Examples of risks

This chapter includes some keywords to help you identify risks. These are primarily general and not device-specific risks. Therefore, this list is certainly not exhaustive.

• Functional principle not proven
• Lack of experience in technology
• Small installation space
• Weight
• Electrical interference (EMC, ESD)
• Heating and thermal design
• Measurement accuracy
• Tolerances
• Battery life / power consumption
• Ambient conditions (temperature, pressure, humidity)
• IP protection class (penetration of solid objects or water)
• Shock and vibration requirements
• Mechanical stability
• Connectors or contact pins unsuitable
• Lifespan not sufficient
• Unknown norms or standards
• Manufacturability not given
• Single source components
• Patents
• Data transfer not sufficiently dimensioned (data volume, transfer time)
• Range of radio transmission insufficient
• Audio quality not sufficient
• Display or indicators inadequate
• Performance of the software on microcontrollers
• Insufficient memory available
• Hidden dependencies within the device (interaction)
• Data protection not taken into account
• Interfaces not clear

Commercial and political risks:

• Unclear development process
• Unclear requirements and deliverables
• Lack of experience in such a project
• Unreliable suppliers
• Team composition not optimal
• Distributed development
• Intercultural teams
• Resource conflicts and competing projects
• Schedule unrealistic
• Important decisions not made

Tips

Before the project risk workshop, read through the requirements and highlight the most challenging ones. Usually, there are only a few (less than 10) that require special attention.

Project risk management is an ongoing process. Therefore, schedule regular meetings and review the status of risks regularly. Update the list as new risks arise.

Plan your measures carefully. It doesn't make sense to focus solely on risks. On the other hand, you shouldn't simply ignore them either. Plan precisely when you want to implement which measures. Assign responsibilities and set deadlines.

It's impossible to identify all risks, and you're sure to encounter some surprises. Nevertheless, it's worthwhile to address project risks. This allows you to actively manage the project and avoid the embarrassing situation of constantly having to react.

I welcome feedback and would love for you to contact me. Feel free to leave a comment on the article. If you know someone who might also be interested in the blog, I'd be very happy if you would recommend it.

Best regards

Goran Madzar