Ukrainian Software Development Market in Wartime
The article highlights the main changes and trends in the Ukrainian software development market caused by the full-scale military invasion that started in February 2022.
Some uncertainty and risk are inherent in any economic activity or project, and software development projects are no exception. In fact, the very nature of a project, as a temporary endeavour undertaken to create a unique result, assumes that each new project takes place under circumstances that cannot be fully predicted.
It is no coincidence that surveys show that 75% of respondents in the IT industry believe their projects are doomed to fail from the beginning. Even for tech giants like IBM, only 40% of projects meet the key parameters of schedule, budget, cost and quality.
This article explains how the risk management process is organised in software development projects and how to build appropriate cooperation and communication between project stakeholders to mitigate risk and achieve the expected project outcomes.
Risks: definition and categorisation
The risk management process is based on ISO 31000 and PMBOK, the industry standards for risk management and project management. Here it is helpful to define a few basic terms.
First, individual project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives. Overall project risk is the effect of uncertainty on the project as a whole, arising from all sources of uncertainty, including individual risks. It is important to note that risk does not necessarily affect project outcomes negatively. Risks with positive effects are called opportunities. Though risk management has an identical process for both negative and positive risks, this article focuses on negative risks.
Understanding risk management makes it easier for project stakeholders to effectively interact with the development team with regard to risks. Let’s consider ways to classify and systematise possible risks.
Risk categories
Risk categorisation makes it possible to classify and systematise individual risks. The risk breakdown structure (RBS) is widely used to break down potential sources of individual project risks to avoid gaps and blind spots. Risk categories can be split by source and area of influence.
Risk sources are fundamental drivers to cause both internal and external project risks. Typically, risks can be divided by source into the following ones:
- Technical risks consider the requirements, technology, technical complexity, reliability, performance, quality, and parameters of the equipment selected for the project. Estimates, assumptions, and technical restrictions are also considered.
- External risks involve external resources, such as software and licences provided by external vendors, customer environment, legislation and restrictions, financial risks, competitive environment, force majeure, and so on.
- Organisational or Commercial risks include contractual terms and conditions, logistics and internal infrastructure, customer stability and solutions, suppliers and subcontractors.
- Project management risks contain everything related to project management, work process organisation, and communication within a project team and with other stakeholders.
Precise risk categorisation helps to identify all potential threats and to implement effective risk responses, allowing teams to focus on the riskiest areas. It is also helpful in developing generic response scenarios for risks in the same category. The risk categories usually listed for the areas of influence are:
- Stakeholders
- Agreements and arrangements, including contract terms
- Quality
- Time
- Scope
- Customer satisfaction
- Other project objectives
The most influential factors in software development projects include:
- Technical infrastructure
- Project management performance
- Software engineering
- The project team’s knowledge and experience.
Risk management framework
The methods and techniques used to identify and respond to risks are commonly called risk management. According to project management statistics, 27% of organisations always apply risk management, while 35% do so periodically.
Based on our observations, insufficient experience is a common reason why IT companies practise risk management unsystematically or not at all. Scrum teams are commonly self-organising and cross-functional. Therefore, they lack risk mitigation knowledge and do not focus on utilising experience from past projects or ensuring proper communication.
The SSA Group Project Management Office (PMO) developed a universal risk management model applicable to projects utilising any methodology. The project manager (PM) plays a key role in this process, having expertise not only in risk management theory but also in leadership, coaching team members and facilitating the risk management process. The PM provides expertise in risk handling in collaboration with the development team and subject matter experts. Given their experience in risk mitigation from previous projects, the PM is prepared to handle highly specific risks.
We follow the Project Management Institute (PMI) recommendations and consider every stakeholder a potential valuable participant in risk management. During the project planning phase, we determine the project stakeholders and their roles in risk management. The list of stakeholders depends on the project and their engagement and responsibilities may change throughout the risk management cycle.
Risk management cycle
The risk management process consists of the following elements:
- Risk Identification – identifying individual project risks and sources of overall project risk and documenting their characteristics. As mentioned above, we actively utilise experience from other projects and risk registers to identify the initial and most common sets of risks.
- Qualitative Risk Analysis – prioritising individual project risks for further analysis or action. Through individual sessions with project team members and the product owner, the project manager assesses the probability of risk occurrence, its possible impact and other characteristics and then creates a shortlist of the risks with the most significant impact and consequences on the project’s success. The shortlisted risks are addressed first, with the project manager assigning a Risk owner, which is the person who will be responsible for that risk. Depending on the risk category and source, the risk owner may be the PM, a software developer, or any other stakeholder who has the specific expertise to address a particular risk.
- Quantitative Risk Analysis – numerically analysing the combined effect of identified individual project risks on overall project objectives. At this stage, the project manager assesses risks from the shortlist to support decision making for risk handling.
- Risk Response Planning – the SSA Group project manager and subject matter experts serve as consultants to help risk owners assess options, evaluate the pros and cons and suggest the most reasonable risk response strategy. The final decision is made by the product owner.
- Risk Monitoring and Control – SSA Group uses regular retrospectives to implement risk response plans, track identified risks, and evaluate risk process effectiveness throughout the project. Although retrospectives are typically used in Scrum, they can easily be applied to projects adopting other methodologies. Through regular retrospective sessions with the development team and risk owners, the project manager controls the implementation of the response plan, keeps track of identified risks, and evaluates overall risk process efficiency throughout the project.
The product owner’s involvement at this stage is crucial as new threats may emerge that need to be taken into consideration or changes may need to be made to the existing response plans.
Let’s take an e-commerce website as an example to understand how the risk management cycle works. We can determine the main project stakeholders as follows:
- product owner
- project manager
- software development team
- board of directors
- functional departments, including marketing and sales specialists
- online store customers
Marketing experts provide requirements for the project team, such as analytic integrations, advertising tools, social media, CRMs and so forth. This, in turn, makes them risk owners for all issues related to keeping versions of these marketing tools up-to-date and monitoring their operability. Thus, this stakeholder has a leading role at the Risk identification stage and actively participates in Risk response planning as a Risk owner with the relevant expertise, as well as in the Risk monitoring and control stage.
During the risk management process in SSA Group, each stakeholder has the responsibilities described in the table below.
Risk mitigation strategies
Risk mitigation planning is carried out to increase advantages and reduce threats to achieving the project objectives in software development. The primary aim is to keep the risks within an acceptable range and establish some containment measures for project implementation.
Here is a brief overview of the principal risk mitigation strategies:
- Avoid. If this strategy is followed, project participants avoid accepting the anticipated risks. It is necessary to refrain from taking specific actions and using certain tools, technologies and techniques if their use in the project entails risks. One advantage of this strategy is its rapid implementation; however, profitability and risk are often inversely proportional. One should constantly compare the potential effects of specific steps in the project against the potential harm from the risks. In our experience, setting project priorities is the most important consideration when applying this strategy.
- Mitigate. This path is appropriate when some risks cannot be avoided, or such avoidance may negate the project benefits. For example, the project team may follow this approach by setting strict deadlines when time is short, or if a safer alternative is too expensive and would overrun the project budget. This risk reduction strategy is the only one possible in an unforeseen emergency. Project participants focus their efforts on overcoming the negative consequences of risks by applying predetermined priorities and responses.
- Transfer. This strategy includes involving a third party in eliminating the negative consequences of risks. A risk transfer strategy is perfect for quickly addressing high impact risks; however, it usually increases project costs and it is sometimes not possible to transfer the risk entirely. In such instances, there is a partial transfer, or sharing, of risk.
- Accept. This strategy is sometimes called risk retention. This technique is used when the impact of a risk is assessed to be at a level that the project can withstand. The expected benefits usually outweigh the potential losses. This approach works well for known risks that may have arisen in similar projects, allowing project managers to assess the likelihood of occurrence and possible negative consequences.
These main strategies and their combinations are the basis for risk mitigation of software development projects and have proven effective in practice.
Risk mitigation tips based on SSA Group’s PMO experience
Risk management is a component of effective project management, the value of which cannot be overestimated. According to PMI research, an average of 11.4% of investments are wasted due to poor project performance. IT service providers with mature value-delivery operations outperform less mature organisations across key project metrics:
Risk management skills and relevant experience create significant advantages for software development projects. SSA Group’s PMO approach is built on experience, proving that absolutely any project has a set of potential risks as possible events in future and the project’s success depends on the ability to manage them. Inevitably, some project risks may occur and others may not. However, being prepared in advance gives us an advantage in achieving the required project outcomes.
Considering risk mitigation as one of the key project management processes and best practices in this area, SSA Group provides the following tips for our clients.
Tip 1. Engagement in risk mitigation
In the SSA Group project team structure, a project manager facilitates and establishes the risk management process and identification, assesses risks, and creates and monitors response plans. However, experience has proven that engaging other team members is invaluable. Depending on project specification, risks and response plan, the project manager will coordinate risk mitigation activities with stakeholders and involve them in the process. The primary focus is on risks that have the most significant impact and consequences or that directly or indirectly affect the project’s objectives, including quality, schedule, costs, scope, and client expectations.
Such an approach allows us to gather all the necessary experience for the project (technical, business, and organisational) to identify risks, reasonably assess them and propose optimal response plans.
Tip 2. Information exchange
Knowledge sharing and mentoring within the project team help increase specific project knowledge and skill building more quickly. The knowledge keepers may be the project management and development team members, the product owner or other stakeholders who also contribute significantly to the project’s success.
The project manager’s role is to ensure the accumulation of project knowledge within the development team. Such an approach helps to:
- efficiently onboard new team members
- reduce or even eliminate knowledge lost after team reduction
- enable scaling the team smoothly
- gain access to specific expertise without time-consuming research, which may not reach the expected outcomes
- decrease the level of indeterminacy in the early stages of the project when the overall risk level is highest
This approach may be implemented as long as:
- mentoring activities and knowledge sharing are part of the day-to-day process
- the PM and project team create a knowledge base and documentation of the project processes, infrastructure, tools, and requirements
- tasks and activities rotate between different team members, so each team member always has a backup
Tip 3. Project infrastructure and tools
Project infrastructure, engineering and managerial processes all contribute to achieving project results. Infrastructure must be stable and reliable and contain all the necessary elements for software development processes and product operation.
Engineering and management processes are instruments for addressing risk. This has numerous implications:
- Methodologies and processes are selected with consideration to project needs and conditions and aiming to minimise potential project risks.
- Methodologies and processes are adapted as needed, taking into account project needs and conditions and aiming to minimise potential project risks.
- The selected processes should be controllable and systematically carried out to achieve results. Activities executed chaotically, inaccurately or incompletely may not give the expected result when addressing risks and may prove ineffective.
The project manager ensures that risks are adequately reflected in the project documentation, particularly the project charter, risk register, and risk management plan.
Tip 4. Regular retrospectives and lessons learned
One of the most significant instruments in our risk management system is regular retrospectives and assessment of the achieved results. SSA Group considers this practice as one of the most effective in identifying risks. During an analysis of past activities, the team members and other stakeholders identify which actions and processes were effective and which can be improved, as well as the reasons for the events or conditions that occurred during the previous stage and whether they may occur again. This process helps to identify such events as potential risks or opportunities in the future.
Holding lessons learned meetings at the end of each project, stage, or iteration allows for findings and insights to be compiled and documented for consideration during future projects. This type of analysis allows us to tap into experience in risk management and issues handling from different projects, thus decreasing the risk level by establishing appropriate processes and practices at the beginning of operations.
Conclusion
Mature risk management processes help teams avoid software development project failures, achieve business goals and create new business opportunities. Maintenance and timely response to risk throughout a project’s lifespan are crucial in achieving the expected project results. By providing subject matter experts in information technology, SSA Group can contribute significantly to a project’s success. Combining technical and business expertise enables us to make quick and intelligent risk-based decisions and implement accurate controls throughout the risk mitigation cycle.
Consider hiring experienced IT consultants at SSA Group to support your software development plans and business growth.
- Author:
- SSA Group Team
