What is the risk involved in walking a tightrope to cross between two buildings? Philippe Petit, who has succeeded at this dangerous task, might have asked himself that many times. He must have been well aware of the risk as he was performing his feat.

There is no such thing as project without a risk

What does Quality Assurance understand as  “IT project risks”?

Let’s start by defining a 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.

IT risk management and risk sources

When speaking of IT project risk management, it’s vital to determine the possible sources of such risks. When we can categorize possible IT risks, finding and managing them will be much easier. However, the categories need to reflect the nature of a given project. 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. 

Based on my own experience as a Quality Assurance specialist and the advice I collected from colleagues in the PM department, I compiled this list of seven most typical project management risks in software development, complete with their consequences and possible solutions to them. Let’s call it an IT risk management framework. Let’s discuss the risk management strategies associated with it.

7 common project management risks in software development

🎩 Changing requirements and priorities

There are many changes during the lifespan of a project – the concepts, requirements, number of tasks in a sprint and priorities all can change. Sometimes, a client may change their mind midway through the completion of a given task, which drives up the cost as well.

🔴 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.

The word “team” refers to each and every stakeholder of the project – the client, project managers, developers, testers, designers, analysts. 

Speaking of project managers, read another one of TSH’s articles to find out why the project manager’s role is crucial in Agile-driven software development.

🔴 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

🔴 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.

Risk identification in software development

Let’s talk about why it is not a good idea to be that guy 🙂

When should you start risk identification? Right from the start, of course! Begin by creating a list of possible risks that should be considered during the whole duration of the project. It should be updated as you go.

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.

IT project risk management – summary

What do you think about the risk management process as presented here? As I said before, there is no software project without risks. It’s very important to understand that it is only natural in the context of information technology. That’s why… there is no point in being scared of risks. If you…

• hold regular meetings,
• address problems immediately,
• search for, share, document and understand knowledge and data,
• motivate all team members within your organization,

… you will most definitely succeed.

And remember – success is contagious. It will have a positive impact on all team members, the entire team as well as other teams and your organization as a whole.

Make sure to save the knowledge you have gathered during the IT project risk identification process and use it to tackle new challenges in the future. Once you get it right, it will be easy to turn it into a repeatable and predictable process for managing IT risks. Good luck!