Measuring Risk Tolerance

During the project lifecycle, we will face the risks and they are going to establish the success or failure of our projects. In order to evaluate the portfolio risk, we should assess the risk per project, for example, considering a database project with high risks will be more important to track than a front-end project in our portfolio, because of without the databases we cannot continue to flow of the software.

There are various that can be avoided with a good planning, for example the following:

• Risks to deliver poor business value. The Benefits Register will mark that every project should have a good output for the business. Otherwise, there is not a good reason to start the project.
• Risks of internal conflicts in the team. People from different backgrounds working together are not easy to handle. A good point to start is the article Conflicts Over Resources.
• Risks of low quality outcomes. The Quality Assurance team should have well-defined rules to evaluate the features integrated in the solution, such rules should aligned to the business goal.
• Risks to missing the deadline. The Gantt Chart is a wonderful tool to keep our projects on track and to know where we are anytime.

In my particular opinion, I like the Agile Risk Management to attend potential risks with techniques from the agile approach. Another recommendation is The Seven Risks in Software Development, where the author mentions some risks and their trigger and complement with the description I wrote before.

Probably, the book “The Standard For Portfolio Management” addressed correctly the procedure to approach the risks at portfolio level, I would like to share an article called “PPM 101 — Portfolio Risk Management” where the strategy is explained accurately.