Managing risks

What is the risk?

The term refers to:

  • an event that hasn’t happened yet,

  • the probability of an event,

  • an event that can be prevented,

  • an event that is either negative or positive,

  • an event with consequences that can be either minimized, maximized, or accepted.

In the context of managing IT risk, we can list three big types of risks associated with it:

  • external risk 🎩 – the result of the client’s influence,

  • internal risk 🔧 – the result of the software development process itself,

  • personal risk 👥 – the result of the efforts, quality, and commitment of individual team members in the project.

What are the best risk identification methods?

There are many tools and techniques that you can use to improve your risk identification process:

  • 📖 documentation analysis,

  • ✅ detailed analysis of project objectives,

  • 📝 control lists based on experience from previous projects,

  • 🌐 brainstorming – simple conversation between all team members can go a long way.

As you analyze risk, you are bound to notice many connections between them. That’s one of the reasons why it’s so important to identify them early on and prevent the compound impact of many risks.

7 common project management risks in software development

Changing requirements and priorities

Consequences

  • overloaded (or underloaded) sprints

  • abandoned uncompleted tasks

  • complete or partial rewrite of the app

  • changes to the schedule

  • incomplete or extended sprints

  • sudden need of adding more people to the team.

Solution

When you make changes, it’s vital to analyze what impact it has on the current state of the project, how much effort it will take, or if there is risk of delays. The analysis will allow for an efficient division of tasks, updating priorities, and providing the client with accurate information on what can (and cannot) actually be delivered.

Not giving an answer in this instance would be synonymous with accepting them unconditionally. This is a common practice in the software development process. That’s why it is so important for all project stakeholders to realize the consequences of the changes and jointly agree for some compromises, in case they are necessary.

Lack of commitment

Commitment of all team members is essential for each project’s success. That’s why it’s important that every team member is committed to the common goal, understands their role and supports other members.

Consequences

  • delays in deliveries

  • negative impact on the motivation of other team members.

Solution

Pay attention to other team members and try to figure out what might strengthen their commitment. They should feel good, but at the same time be able to focus on their work. Let them grow on an individual basis, talk to them and praise them. Make sure to provide them with as many details on the projects as you can so that they can feel like an important part of something bigger.

Lack of communication

Communication is crucial for the efficiency of work in a software development project. What are the consequences of poor communication?

Consequences

  • gaps in knowledge

  • duplicated tasks

  • decreased productivity

Solution

Regular meetings of all team members both for the sake of completing tasks and sharing knowledge created as part of the project. The meetings should feel safe and give everyone a chance to speak up. Don’t ever leave anyone’s question unanswered. If you don’t know the answer, inform them that you’re going to try find it and return with it later.

It’s vital that everyone understands their role in the project. A meeting outside of the work context can also be a good way to improve the atmosphere in the team.

Poor documentation

What is project documentation? Minimum viable product (MVP), task descriptions in JIRA and project space in Confluence – all of these are very important for the project’s success.

Consequences

  • chaos

  • team unnecessarily wasted on repeated questions regarding basic project information

  • no good benchmarks for team members to use during and after the project

  • insufficient knowledge for team members joining the project midway.

Solution

Even minimal project documentation goes a long way to prevent the worst consequences.

According to best Agile practices: “working software is more important than detailed documentation”. However, it shouldn’t suggest that documentation is not important. How to best tackle this issue?

Make sure to allow some time for writing documentation right from the start. That way, you won’t have any excuses. Use tools such as JIRA, Confluence or QA Touch – they really make things easier. There are also many other more specialized tools to help you write documentation for APIs and other project deliverables. Determine what information should always be available. A good place to store it in Confluence. It’s the place where you should be able to find all of the basic project information, team members and their roles, passwords and other access information for important project properties and environment, user descriptions, or a list of features.

Consistently use a specific convention for naming and describing tasks. Remember, the documentation doesn’t have to be bulky. Its job is to describe the entirety of the project in a clear and easy-to-follow manner.

Unplanned absence of a team member

Each unplanned absence of a team member is a cause for concern. During autumn and winter, the risk of getting sick is especially big.

Consequences

  • disorganization

  • delays in delivering tasks

  • insufficient knowledge about the project if the individual was a key member (again, it shows the importance of good documentation!)

  • demotivating for the team.

Solution

The key is for all team members to share the same essential project knowledge. Depending on how long the absence lasts and the state of the project, PM should make a decision whether a replacement is needed. Providing the project knowledge and documentation is there, it will be easy for someone new to get started.

Poor communication with the client

The client is not responding? Did you try to contact them a couple of times already? Chances are that the client is on leave, but neglected to let other team members know.

Consequences

  • delays in the project due to the client’s unresponsiveness

  • demotivation for other team members.

Solution

Show the client how important it is for you to maintain a good relationship with them right from the first meeting. Determine what kind of decisions should always be made together, and what can be decided by the developers/PMs on their own. When you send an email with a request to the client, it might be a good idea to describe exactly why to delay in an answer can be problematic (e.g. difficulty in meeting a given deadline). If no method of reaching out to the client works, the project manager should take action in order to improve communication with the client.

Failure to deliver on time

I can’t think of a project that had absolutely no delays 😀 Changing requirements during the implementation, badly estimated tasks, failed tests, unplanned absence, poor communication with the client etc. Most of these issues can be prevented with good planning. That’s why you should take those risks into consideration from the start.

Consequences

  • delays in project implementation

  • uncompleted task causing issues with the completion of other tasks

  • client dissatisfaction

  • bad working atmosphere.

Solution

As you plan the deadlines for the project or/and sprint, take into consideration all possible factors like this. Analyze possible risks and inform the client about them. Always assign tasks taking into consideration the number of team members available as well as their skills, strengths and weaknesses. Always inform about your progress and address all problems/blockers during the Daily Scrum. That’s the best way to go about quality assurance in software development.

If deadlines can’t be met, it’s vital to inform the client about it as soon as possible. A good way to tackle it is to split a bigger task into a couple of smaller ones. It’s better to deliver a few smaller tasks than nothing at all. It also shows the client the team’s commitment.

Last updated

Was this helpful?