When estimating software development project risks, we often face significant challenges of risk identification and controls at various levels.
Most commonly, businesses control project budgets and schedules but possible delays, extra cost, or communication issues are often overlooked. How to mitigate risks in a project? Risk estimation and scoring will help you avoid project breaches and will mitigate problematic situations.
In this article, we'll elaborate on software development risks and mitigation.
How to define project risks
First off, you need to define the nature of risks in software project management you are facing in a software development project. Normally, we can define four software project risk categories:
- Organizational risks.
- Schedule risks.
- Operational risks.
- Technology risks.
After categorizing risks according to their type, a project manager needs to evaluate each of the risks based on the range of attributes, with probability and severity being the most important of them. The metric system normally ranges from very low to very high—but you should consider it as a combination of factors and have a larger, comprehensive risk management plan in mind.
The core of the project risk management plan is to consider all the possible risks before the estimation and find a solution to each of the project's threats once they emerge.
What is the software development project risk itself? It’s an event that happens within the software development lifecycle and is likely to cause a loss.
Let’s see the types of software development project risks that may occur within a project’s lifetime, take a look at the examples and offer a solution to mitigate them.
The project schedule may falter when tasks are not estimated properly. This will affect the company’s income and will lead to the project's failure.
1. Incorrect deadlines set by a client
It often happens that a business analyst from the client’s side has already defined deadlines which are much stricter than a technical team from the vendor’s side estimated. As a result, the vendor’s team has to work overtime or add more people which were not in the initial agreement.
SOLUTION: Before starting a project, the development team should inform the client about the high probability of a risk event. If the deadlines cannot be moved forward, it makes sense to focus on the most important features instead of spreading efforts to each and every task.
For example, if the deadline is associated with some public event where the client is supposed to show a demo of the minimum viable product, you can focus on the product’s UI and hardcoded data.
2. Very generic specification
If the project’s specification is too brief or the project scope is vague, chances are a couple of features will fall out of scope. As a result, more project requirements will be added during the development process, deadlines will be blown, not to mention the overtime hours which will all ruin the team spirit.
SOLUTION: Don’t sign the contract until you’re sure everything in the scope has been specified. It’s better to start with business analysis and convert the client’s business requirements into the functional specification where all the features are described in detail and prioritized by their importance.
3. The client is not available to the dev team
As a project progresses, the client needs to make sure that his expectations materialize and the dev team gets the requirements right. If there’s not enough communication between the two parties, there can be delays in informing about the impediments and delivering the result.
SOLUTION: If the client cannot be available for continuous synchronization, it’s worth considering to delegate the product owner responsibilities to other competent stakeholders either from the client’s or from the vendor’s site.
4. The client requires too much communication
There’s a flip side of too active communication. It may lead to unnecessary discussions, detailed explanations of the tech issues to non-tech people and getting stuck into nowhere.
SOLUTION: If the client insists on frequent meetings, you need to add some extra hours to the estimate. Also, it makes sense to filter the tech info regarding very small decisions that don’t affect the project’s schedule and performance.
Having found out that our development team is based in Belarus, many of our potential clients from the US become worried about how to mitigate it outsourcing risks and manage a time gap of 8 to 11 hours between the countries. However, with proper risk management working in a distributed team may not be so intimidating.
5. Working in offshore teams within the same time zone
This is one of the low-impact business risks. If both teams have strong technical leaders, they may have differing visions of the product's implementation.
SOLUTION: The teams still need more time on synchronization and communication when the teams can discuss any emerging hurdles and come up with a consistent strategy
6. Working in different time zones
Here’s where the risk substantially increases. Teams are supposed to collaborate within the limited time when their working hours intersect. For example, 9 AM in New York equals 5 PM in Belarus, so the teams have 2-4 hours of time overlap. This often causes over time.
SOLUTION: There should be additional time added to the estimate for synchronization. If there’s a chance to send an offshore team on site to the client for a couple of weeks to dive into the project, it will lower the risks of personal conflicts and misunderstandings which often arise at the early stages of a project.
Operational problems may have adverse effects on project outcomes. Project management must plan for efficient execution of the project, and find a balance between the needs of the development team and the expectations of the customers.
7. Compromising on design
Often teams tend to skip the important steps of the design phase and rush into doing “real” development tasks. However, without the proper planning, prototyping, and information architecture building, the whole process is a waste of dev hours.
SOLUTION: When estimating the project, add enough design hours to conduct product workshops, UX strategy, UI design, and usability testing.
8. Lack of developers
In some cases, developers have to work on several projects in parallel if there's a lack of resources. If a support period of a previous project is also ongoing, developers may be distracted due to bug-fixing activities.
SOLUTION: If both part-time projects are long-term, it makes sense to allocate a back-up specialist. However, it will increase the cost of the project and lower the productivity of both specialists because they lose track and have to switch between contexts.
9. Unstable workload
If we have a workload of fewer than four hours per day per person, it's difficult to switch between the context of the two projects. This risk increases when critical issues emerge on two projects at the same time.
SOLUTION: Such cases require additional coordination. It makes sense to put a project on hold and accumulate a reasonable number of tasks if the workload is less than 80 hours.
10. No testing
Some clients hope that developers will be able to test the project by themselves and save on QA people.
SOLUTION: The one and only solution is to just to hire a QA person. They are more skilled in detecting hidden bugs and will dedicate their time to testing only.
11. No post-go-live support
Once the project goes live, it often happens that the vendor’s team doesn’t provide any support or focuses on the critical issues while smaller issues may not be in scope.
SOLUTION: Early in the project, state how and for how long post-go-live support will be handled. Include hours for knowledge transfer and handoff activities.
Technical risks generally lead to failure of functionality and performance. Let’s see the most popular of technical risk examples and project risks mitigation strategies:
12. Not choosing the right technology
Choosing the right technology stack and implementation team is probably the most critical decision that you make during the Discovery phase of the project. Each team has the core knowledge or experience in specific domains, technologies or solutions. Placing too much emphasis on some popular technology is among the most popular custom software risks.
SOLUTION: There is no need to focus too much on popular technology. Instead, you need to specify the problem you’re trying to solve—for example, better security, real-time communication, or mobile responsiveness—and choose a technology stack that deals better with that problem.
13. Integration of popular technologies
Most risks are tightly connected with integrations with 3rd party systems, plugins or content management systems. If these technologies and tools are popular and well-known to your team, the risk is quite low. Popular libraries are often supported by a robust community, so the solutions to the new issues can be found rather quickly.
SOLUTION: Just make sure all the tools have proper and updated specifications. Add a decent buffer to the estimate in case there are updates developers haven’t worked with yet.
14. Integration of new, unproven technologies
If the technology is new, the risk may increase manyfold. It’s unreasonable to think that the team will deal with the software integration risks as fast as they would with the known ones.
SOLUTION: You’ll need at least a basic specification of new technology. Check if any payment for support is required and include the price in an estimate. Double the time on project learning and document all the issues that surface.
15. Working on existing source code
Taking over an ongoing project with the existing source code is a very risky deal. The team needs to investigate the source code, assess its quality and identify elements which should be refactored to increase efficiency. The team should also learn the project from a user perspective to understand their flow in general.
SOLUTION: Request all the existing documentation, try to investigate the issues that complicated the work earlier. Take every chance to speak with the previous team and discuss the details. It may make sense to perform source code analysis before you deliver an estimate, as you’ll never know what challenges you’ll meet afterward.
In general, to be effective, software risk management activities must be integral with most project processes. Essentially, this means risk planning in project management, frequent checking during project meetings and critical events, thorough learning of documentation and more communication between the product owners and a technical team.