A dialogue about life itself, in the course of conducting a software audit.
Me: “Okay, let’s review the risks of the project at the moment.”
Junior project manager: “You know, I’m not really interested in these risks at all, I just want to finish the thing in a cool way.”

To be honest, I still sighed deeply in my mind. A project manager who does not understand the importance of acknowledging and monitoring risks is simply not yet a project manager. You can put all your youthful power and enthusiasm into leading the project – involve, communicate, negotiate, coordinate, etc., but often the project still doesn’t go great. If you are not prepared for the realization of risks, they will always catch you off guard and knock your entire team off their feet.

The story below is quite long, because I wanted to be thorough. When I was younger, I went through the same phase as the project manager above, and today I know that professional risk management is what is essential for the success of even a slightly larger project.

Risks can never be completely avoided, but they can be mitigated to a large extent at an early stage. Risks must definitely be assessed regularly throughout the project, and as soon as one of them rears its head, it must be acted upon quickly and decapitated.

In fact, the risk is not something scary and there is no need to be afraid of it. In an experienced team, many risks do not materialize at all. At the same time, I have not seen a single project so far where not a single risk has been realised.

Being aware of the risks and taking the right measures is already half the battle.

Common Software Project Risks

The risks, probabilities and impacts of each project are different, but there are also many similarities. Here is an overview of the most common risks in software projects, from which you can choose for your project and add specific risks to your project.

Planning and management

• Weak communication and insufficient transparency of project status
• Unrealistic schedule
• Too little time on the part of the contracting authority’s project manager (PO)
• The client’s project manager is leaving his job
• A member of the executor’s team leaves the job
• Vacation plans are uncoordinated
• A member of the executive team falls ill
• The number of contracting parties is large

Requirements and scope

• The requirements are unclear to the executor or they have not understood them correctly
• Different expectations for the scope and outcomes of the project
• Handover of works accumulates at the end of the project
• The volume of developments is higher than expected
• Requirements change frequently, change management is weak
• Confirmation of interim results by the contracting authority is delayed

Competence

• The team lacks the necessary competence
• The client’s project manager lacks the necessary competence

Interfaces

• Interface requirements are unclear and communication with third parties is slow
• (There can be a lot of different risks down here, depending on how much complexity and interfaces there are in the development)

In most cases, risks are realised as a result of weak planning and project management, which is why the development methodology and the quality of the work process are the number one priority in a software project.

Start by writing down your risks

The risk plan must be prepared by the project manager of the implementer at the very beginning of the project. Yes, it must be done in writing. No, it’s absolutely not enough if you only think about the risks in your head. You can draw up the first risk plan alone, the next step is to discuss it with the team – what risks do they see and how do they assess them?

If it is a public procurement and the tender asked for a risk plan, then you already have some basics. But the plan included in the offer is only a guess, in fact, you don’t know what the likely risks are until you have met with all parties. Add a discussion of the risk plan to the agenda of the project kick-off meeting and allow enough time for reviewing and evaluating it.

At the end of the blog post, you can download a sample of the risk plan, and it may be useful to compile a risk matrix that gives you a visual overview. For example, the risk matrix might look like this:

Plan, evaluate and act!

It is the responsibility of the project manager to coordinate risk assessment and mitigation activities from the first day of the project. If the activities have been done and they did not give the desired results, other activities must be tried. Always involve your team members to get suggestions and ideas from everyone. If these activities also do not work and The risk becomes redder and redder, the risk must be escalated to the level of the management group or management. It is extremely important not to just sit back and relax in a problematic situation. If the problem cannot be solved, then escalate and solve it at a higher level. Quickly.

Assess the risks periodically every 2 weeks, this is the right time for you to react to them in time when risks arise. Some risks appear suddenly, but more often there is a so-called creeping red turn and you notice and act too late. To avoid this, include a risk assessment slide in every agenda of a steering group or project meeting. This way, you have the risks in mind, are aware and it is easy to overestimate the current situation.

The risk slide might look like this:

Sample risk plan

The risk plan document has the following pages:

• Risk plan – must be prepared at the very beginning of the project
• Risk matrix – helps to visualize the risk plan and get a better overview
• Highlighted risks /date/ – the most likely risks, responsibilities and activities at the moment, use for regular monitoring

Happy use!