Risk Management

Software Projects Risks

Because they aren’t as tangible as other risks, threats to software development projects are often ignored or minimized. These risks can still cause havoc in software development projects, just as they could for any other industry project.

Many project managers in information have been involved in planning software development projects down to the final detail. They also plan the effort required to complete each task. Then, an unforeseen problem occurs that makes it impossible to deliver the features or on schedule.

Risk managers are essential for any successful project manager. In fact, the role of risk manager is now a formalized position in the insurance industry. You must first identify the risks that you face in order to manage your software development project’s risks. This article is designed to give you some techniques and tips to help you do this. It is helpful to be familiar with terms that do not directly relate to risk identification. These are some examples of such definitions.

  • Risk eventIf it happens, this is the event that will impact the project.
  • Threat– A risk that may have a negative impact upon the project’s scope, quality, schedule or budget.
  • OpportunityRisks are not all threats. Some are opportunities that could have a positive effect on the budget, quality, schedule or scope of work. It is important to avoid threats, reduce their impact, and encourage opportunities or increase their impact.
  • Probability – The chance that a particular risk event will occur. This is what gamblers call odds.
  • Impact – This is usually a relative cardinal or ordinal rank that is assigned to a particular risk event. It could also refer to an absolute value, time period, feature set or quality level.
  • Risk ToleranceThis describes your organization’s approach towards taking risks. Is your organization conservative? Are you open to calculated risks in your organization?
  • Risk Threshold – Your organization’s tolerance to risk will typically be expressed as an ordinal or cardinal comparator. This comparator uses the risk events probability, impact and calculation to generate the comparator. Any risk whose Probability/Impact score exceeds this threshold will not be accepted or minimized. Risks with scores below this threshold are acceptable.
  • Risk Contingency– This is the sum that the project has been allocated to manage risk. This sum should be divided into two amounts: one to manage identified risks and one to manage unidentified risks or unknown unknowns. You can choose to have the sum in monetary or time form.

For help in identifying risk, the project manager for a software project can turn to many sources: Common Risks (risks common for every software project), risks identified by the performing organization, risks identified using the SDLC methodology chosen for that project, risks specific to a particular development activity, Subject Matter Experts and risk workshops.

Common Risks

Every software development project, regardless of its size, complexity, technical components or tools, is subject to a variety of risks. These risks are most common in the following:

  • You are not meeting the requirements– The requirements that the software system must meet in order to achieve the business goals and objectives.
  • Not enough requirements– Requirements that were captured, but the original intent or interpretation was lost in the process.
  • Projects are without critical or key resources These resources can be single contributors or members of a team with skills that are in high demand within the organization. It is possible to lose a resource over a longer period of time if they are given tasks that are critical.
  • Bad estimation– Evaluating the effort needed to develop the software is either too low (also bad) nor too high (also terrible). This is the most common mistake. The work is often prolonged to the point that it consumes all of the time allocated by an overestimation.
  • Skills that are missing or not complete This risk event can have the same results as bad estimation but it will present a different risk. If a junior programmer is identified as an intermediate programmer, it could lead to a substantial increase in the effort required to produce their deliverables or even a complete inability.

These risk events must be identified and captured by the project managers at the beginning of any risk identification exercise. These risks should be made visible to the team before any risk identification exercises. This will save time and encourage thinking about the associated risks (“…… What if Jane was to be assigned to a more important project? Would Fred be affected by that?”).

Organizational risks

These risks are unique to the company that is executing the project. These risks may contain some of the common risks and other sources but they will also include risks that are not available from other sources.

For common risks, the project manager should refer to the archives of prior software development projects. The risk registers for all projects should be gathered. Although it is unlikely that there will be a common risk across all projects with a large number of registers, you should still carefully examine the risks in multiple registers to determine if they are applicable to your project.

In cases where there are no archives, ask the project managers in your company who were responsible for previous software development projects. You may find that the project managers responsible for past software development projects in your organization have their project artifacts, including risk registers, stored in their personal space. This is even if there is no structured archive process. It will be helpful to have the experience of past project managers in order to decipher the risks contained in the archived risk registers.

The risks will not be repeated across different registers, or between different project managers. Analyzing the risk event description will help you determine whether two or more events are identical, despite having different descriptions.

SDLC-Specific Risks

Related Articles

Your software development project can be exposed to certain risks or protected from them depending on the SDLC (Software Development Life Cycle). The selection of an SDLC (Software Development Life Cycle) for your project is a critical decision. You should avoid or reduce the risk. The identification of risks and choosing an SDLC for your project are similar to the chicken and egg. It is hard to know which comes first. Here’s how to sequence them. The type of software system you are creating and the company where it is being developed will influence the choice of SDLC. What level of experience do they have with each SDLC? What are the priorities of each project? After you have decided on an SDLC, you can identify its risks and decide if your organization is willing to take the risk.

Each type of SDLC has its risks. We will discuss some of the more common risks that are associated with SDLC, including those for the most widely used types.


Waterfall projects will be more susceptible to delays and other risks that could impact the schedule. This is due to the fact that there are no intermediate checks to help catch issues early in the build process. The project will be delayed if there are delays in any activity from requirements gathering through User Acceptance Testing. Delays due to inexperience with tools and components (e.g. Testing tools, programming languages, inexperienced testers, underestimation of effort, delays resulting from inexperience and delays due a contributor missing deadlines.

A waterfall project is not immune to delays. Waterfall projects are not designed to share learning. Therefore, a mistake in one part of development could spread to other parts of the project and not be discovered until the end. These mistakes can lead to delays in development, more work than is required, less scope for future development, and a lower quality product.

Waterfall tends to be used in larger projects, which are more complex than other methods of development. They are also more likely to undergo changes. The Change Management process is responsible for addressing all requests in a timely manner. However, as the project’s duration increases, so does the likelihood that it will become overwhelmed by requests for changes and buffers for analysis. All of the available resources will be exhausted. This can lead to budget overruns, project delays, and even budget cancellations.

Rapid Application Development

Rapid Application Development aims to cut down on the time needed to develop software applications. This approach has the primary benefit of eliminating change requests. The theory is that if there’s a fast enough turnaround, then no need for any changes. However, this is a double-edged sword. The project’s ability and willingness to accommodate change requests will be severely limited by the fact that the method is dependent on them not being made.

Software applications’ fitness for use will be one of the biggest risks to this project. It is possible that the market or the business might change during the project. If this happens, the software application may not be able respond to the request for a change within the original timeline. The change could cause the schedule to be delayed, or it could result in the construction of a system that is not suitable for the client’s needs.

To be successful with the RAD method, you need a small team and a small feature set in order to make it easy. The lack of a required skill set in the team could lead to one possible outcome. Another result of small teams is a lack of redundancy in their skill sets. This means that illness can’t be absorbed without delaying the work schedule or seeking outside assistance.


This method of development is unique because it does not have a project manager. A team leader replaces this role. Although the team leader may be a project manger, it is unlikely that an experienced project manager will be sought out by the performing organization to fill this role. To speed up development, the method doesn’t require that a project manager manage the project. This approach poses a risk to the team’s ability to manage change, requirements, schedule management quality management cost management human resources management procurement management and risk management.

A lack of project management discipline can lead to a project not being able to properly accommodate change, which could result in changes being ignored or incorrectly implemented. A lack of experience in managing human resources could lead to unresolved conflicts and inappropriate work assignments.

Iterative Methods

RUP (Rational Uniified Process) is the main iterative method. These methods use an iterative approach to development and design so they are combined here. This is to allow for changes that dynamic businesses may require. Each cycle of requirements design, design, build and test takes only a few weeks. It depends on the methodology. Iterative design allows project team members to learn from past errors and make improvements quickly.

Iterative approaches all depend on the division of the system into components that can then be designed, built and tested. This method has the advantage of delivering a working model very early in the project. The downside to this approach is that it does not allow the system to be separated into components that can be demonstrated independently. This creates the possibility that users will not learn from their mistakes until they test the system.

In iterative development, there is a trade-off. Develop the core functionality that can first be demonstrated versus develop the component which will yield the greatest learning. It is possible to choose core functionality to be developed, but you may not learn enough about the system in order to make it work for future iterations. The risk of not producing the system that the client requires could be present if you choose the most complicated or difficult component.

Activities-specific Risks

Each activity within a development cycle is subject to its own risks regardless of how it was done. There are three risks associated with requirements gathering: incomplete requirements, misstated requirements, and excessive time.

There will be risks during the design part of the cycle. For example, the design may not accurately interpret the requirements so that the functionality created will not meet customer needs. It is possible that the design calls for greater complexity in the code. A programmer may not be able to write code that functions properly because the design was written in such a way. It is possible for the design to be unclear or hard to follow. This could lead to a lot more follow-up questions and possibly bad implementation. There could be many stages to design, starting with a Commercial Specification and ending with a Detail Design Manual. Each stage can lead to misinterpretation of the requirements.

Even though the specifications are clearly written, programmers may make mistakes and create an application that is not compliant with requirements. Slippery unit, function, or system testing can lead to errors in the QA environment which will take extra time to fix. Different programmers could interpret the same specification differently in developing modules and functions that have to work together. A section of functional specification could deal with the input and output of two modules. This is an example of how different programmers might interpret the same specification. There is a risk that discrepancies will not be discovered until the software has been integrated and tested.

Here, testing refers to Quality Assurance and User Acceptance testing. Although these activities may be different from the tester’s perspective, they can be combined for our purposes. Due to the amount of errors found, the actual testing effort could be greater than the planned effort. A high number of errors during testing can lead to excessive rework and repetition. The specifications that test script writers work from may be different than those of analysts, programmers, clients, or programmers. Because User Acceptance Testers are part of the business community, they can be subject to business demands for reduced or elimination of their availability.

Experts in Subject Matter (SMEs)

Because of their expertise, Subject Matter Experts are crucial to the success and sustainability of the project. While Subject Matter Experts can help with all aspects of the project, they are most useful for requirements gathering, analysis change requests, business analyses, risk identification, risk analysis and testing. Key risk for SMEs: The SMEs that are critical to your project could not be available at the time they promised. This can be particularly harmful if the SME responsible for a critical path deliverable.

Risk Workshops

Risk workshops are a great tool to identify risks. These workshops offer the benefit of bringing together Subject Matter Experts in one room, so that their knowledge can be shared. It should result in the identification and mitigation of multiple risks that could not be discovered by polling the SMEs separately.

This article is not intended to provide advice on how you can conduct productive workshops. However, I will give you some suggestions that may help you get going.

  1. You need to invite the right SMEs – they must cover all phases and activities of the project.
  2. Share all details you know about the project. These include deliverables, milestones, priorities, etc.
  3. Ask for the active support of your project sponsor. If possible, this should include attending the workshop.
  4. For each phase or area, invite at least one SME.
  5. You can divide the group into smaller groups based on expertise, project phase, or other factors.
  6. Encourage new ways of looking in your area by ensuring that the risk is communicated to all groups and SMEs.

The risk workshop doesn’t end with the identification and assessment of risks. These risks need to be identified, analyzed, compiled, assessed for impact and probability, and mitigation or prevention strategies developed.


When your Subject Matter Experts cannot be present at the workshop, polls and surveys are an acceptable alternative. However, you must make up for the lack of synergy you experience with workshops. It is your responsibility to provide all information that might be useful to the Subject Matter experts you identified at the beginning of the exercise. Once you have done that, you can send the SMEs forms to capture the risks, the source, and how the event may impact project objectives.

Collect the risks once you have received them. Look for risk events that are different approaches to describing the risk. These allow you to combine both risk events or use the same mitigation strategy.

A poll or survey is not as effective if there aren’t enough participants. While you may be able manage with one SME or area of expertise in a project phase, you will need to continue to follow up with reluctant contributors. Do not hesitate to ask your project sponsor for their assistance in obtaining the level of participation that you desire. They may be willing to send out the survey and invitation forms first.

Meetings for teams

The planning phase of a project is the main source of all identified risks. Proper execution during the planning phase will enable you to compile a comprehensive list. However, these lists will reflect more risks from earlier phases of the project than those in later phases. You must maintain your risk register once you have created it. As you learn more about the project, you will need to update that document. Risks become obsolete when the work you are exposing to risk has been completed.

Your risk register can be updated in team meetings. When the team is discussing its progress towards completing deliverables, the issues that are raised will often be related to the risks involved in meeting deadlines. To assess the impact of the week’s passage on existing risks, you might want to designate a section of your meeting to review the probability scores and impact of those risks. It is important to keep an eye on the team for new risks. You should also monitor the team for any new risks. Projects may discover new work when they are completed. This is not something that was considered when risks were identified.

In cases where your team is not sufficiently familiar with project risks, you may consider holding separate risk strategy meetings with your SMEs. This approach should be used in conjunction with your team meetings if your software development project is large enough that it requires sub-projects. Examine each risk and evaluate the effect of time on each one. The likelihood and impact of a risk event/event will usually increase as work progresses. As more work is completed, the impact and likelihood of the event decreases.

The project plan should be reviewed for any work that has been done. You should discuss risk probability and impact of work completed recently.


We are a team of professionals with each having two decades of experience in start-ups, sales, marketing, finance, HR, large scale project and profit centre management and running mature cross functional operations. At Molw.net we are big believers that knowledge transfer is critical to our industry’s evolution. We love to share our experiences and learnings through our online resources.

Related Articles

Back to top button