Which of following is complete and correct list of software risk components?

We recognise that software development is inherently difficult to predict and plan. By nature software is intangible and often involves a large number of stakeholders. This combination of factors can create a number of risks that need to be considered and managed from the outset of a software project.

While we can estimate the threat these risks will have on your software project, the likelihood and impact of them occurring will vary depending on the methodology you are using. You can download your own risk assessment template if you want to determine the threat of each of these risks on your own project.

We also interviewed experts in software development to find out about their experiences in dealing with risk. You can watch the video below.

So let’s get started with some of the biggest risks in software development. How many of these have you struggled with before?

1. Inaccurate Estimations

Though estimations are an often unavoidable part of software development (because of the pressure from customers or other stakeholders to obtain a price or timeframe), they can create risk if the estimations create expectations that can’t be met.

Inaccurate estimations occur when the length of a project, milestone or iteration is underestimated by the project group. Software estimations can cause problems between developers and clients because they lead to increase project timeframes, and therefore also project expenses.

From our own experience, and the experience of external projects done by our partners, this particular risk has been identified as very likely to occur, and cause severe impact to project delivery if it does.

How do you accurately estimate software? There are a number of mitigation strategies available to minimise the risk:

  • Elaborate only the work that has immediate priority;
  • Include Tech Spikes in your estimations (i.e. an allocation of time for developers to research and de-risk a particularly complex or unfamiliar part of the project);
  • Add an allocation factor to the estimation (i.e. a calculated time factor that a development team spends during the work week on task outside of the project); and
  • Consider the Cone of Uncertainty when estimating.

For more information on how you can apply some of these risk management strategies to your project, you can read our article on How do you manage expectations in software development?.

2. Scope Variations

What is scope change? Scope variations occur when the scope of an iteration changes after a timeframe had been agreed upon. Due to the value from receiving frequent customer feedback, stakeholders or product owners will often ask to vary the scope of a project.

However, scope variation creates a severe risk to projects. When a scope varies, it significantly impacts the ability of the developers to stick to the original timeline of a project.

So, how do you manage project variations? Managing customer expectations around how scope variation can impact the original estimations of a project is an important mitigation strategy for this risk.

From our experience, using a variation metric to measure the scope changes, allows for greater visibility to the customer of how the requests have impacted the project.

The following are some other valuable strategies for dealing with scope variations:

  • Short, manageable iterations (or using the Agile methodology) allow for more frequent opportunities to reflect upon and vary the project scope; and
  • Elaboration of only prioritised work.

3. End-user Engagement

This risk is where a product is released to the market but the users are resistant to change, or there is conflict between users.

Why is user engagement important? Ensuring that the users of a product will actually adopt the software will directly link to its success. In the case of a company building software for an external customer, it will correlate with profitability. In the case of an enterprise building software for internal use, it can determine whether the software will actually improve productivity within the company.

How do you improve user engagement? You might be surprised how simple the answer is - listen to your users. Some possible mitigation strategies for this risk include:

  • User testing and surveys;
  • Focus groups;
  • Frequent releases; and
  • Beta testing.

These mitigation strategies are far easier to apply using agile development.

The chance of poor end-user engagement is far more likely for projects following a waterfall methodology. This is because these types of projects are unable to adapt to end-user feedback during development. The nature of waterfall development requires no scope variations.

4. Stakeholder Expectations

Though we have talked about managing stakeholder expectations as a mitigation strategy, the uptake of this strategy can in itself become a project risk.

So what is a stakeholder in software development? Stakeholders are any person or group who can either impact, or will be impacted by an outcome of the software project. These stakeholders can range from business owners, to the development team, or even investors in the project. It is this close relationship to the project outcome that make managing the expectations of each of these stakeholders a challenge.

So how do you set expectations with stakeholders? From our experience, here are some of the key considerations:

  • Effective communication;
  • Obtain frequent approval and acknowledgment of the project from a stakeholder;
  • Follow tested development methodologies (such as the Way of Working);
  • Involve stakeholders in important meetings; and
  • Ensure stakeholders maintain reasonable response lines for communication with development teams.

5. Poor Quality Code

When the quality of a project does not align with stakeholder expectations, there is a significant risk that the project will not be successful. Poor quality code can occur for a number of reasons, for example when projects are underestimated and developers rush to complete the iteration.

What is bad code? Poor quality code can mean a number of things. The code may be difficult to read, meaning it is difficult for other developers to review or make changes. It might have been rushed and released without testing, therefore full of bugs that could have been prevented. In other words, poor quality code creates a risk of technical debt.

How do you define technical debt? Technical debt is essentially any code that decreases the agility of a software project in the long-term. Usually it is created by taking shortcuts when writing code, in order to achieve goals faster. However, code quality is important because it reduces the long-term development effort of a project by making the project more easy to understand, maintain, and extend.

How can you improve code quality? It is important for developers to maintain a high standard for their code. This can be done by considering the following strategies:

  • Implementing User Acceptance Criteria to have stakeholders affirm the project is up to standard;
  • Code reviews;
  • Clear coding standards and guides;
  • Testing of all code;
  • Appoint a dedicated Product Manager to monitor the quality of the project and take ownership to all stakeholders for the success and failures; and
  • The Way of Working.

6. Poor Productivity

When a project group falls behind on planned timeframes, you might need to examine the productivity of the development team. Though unlikely, poor productivity may be the cause.

How do you measure developer productivity? To determine the productivity levels of your development team you can utilise tools such as burn-down charts or iteration reports.

If your company has undergone a decent hiring process, it is not likely you will face this risk, however the impact on a project if it does occur can be detrimental to the successful delivery of a project.

It is therefore valuable to consider the following strategies:

  • People culture of your company;
  • Set achievable timeframes and a sustainable pace during your project estimations to avoid burn-out of staff; and
  • Find a Product Manager who is directly involved and collaborates with the team.

It is important to remember that humans aren’t machines and it is therefore unrealistic to expect them to be productive every hour they spend at work. To find out more about what hinders productivity and how you can minimise time waste, read our article on [how many hours a day workers are productive]().

7. Inadequate Risk Management

Inadequate risk management can occur when any of the project specific risks are not properly recognised and mitigated by the stakeholders.

What is adequate risk management for a software development project? The path to adequate risk management starts with first spending time acknowledging that risks exist. The ostrich strategy of burying your head in the sand and pretending you can deliver software without facing any of these problems will only cause long term stress.

A far better solution is to consider mitigation strategies from the outset, and continuously throughout the software project. There are many risks when building software, and if a risk is effectively identified, then it can be mitigated.

How do you mitigate software development risks? Some mitigation strategies include:

  • Including risk in estimations; and
  • Utilising a Risk Register on estimations, and in the project requirements backlog.

It is important that you determine which risks are specific to your project and set methods to mitigate them from the outset of your project. To help identify the impact a particular risk could have on the software project, you can use a risk matrix. To determine which are the greatest risks in your project, you will need to determine the impact, and likelihood the risk will occur.

To help you get started with your software risk assessments we have mapped the impact and likelihood of the 10 biggest software risks for an average waterfall or agile software project. You can download this spreadsheet for free here.

However, the types of risks that could be present in your project may differ from the 10 discussed in this article. It is therefore important to conduct a risk analysis at the start and end of all iteration meetings. If you would like to learn more about creating a risk management plan or conducting risk assessments using a risk multiplier, you can read our article on [identifying and managing risks in software development]().

8. Low Stakeholder Engagement

What is low stakeholder engagement? This is where a client or stakeholder you are collaborating with is not engaging with your team at the frequency necessary to maintain high productivity levels. Low stakeholder engagement is a significant risk to projects because slow responses from the customer can impede delivery timeframes.

The opportunity for low stakeholder engagement is actually increased when implementing agile methodologies. This is because iterations are more frequently delivered, and therefore require more frequent feedback from stakeholders to the development team.

How can stakeholder engagement be improved? Some mitigation strategies that can be considered include:

  • Clear agreements with the customer or stakeholders around response times, particularly for any User Acceptance Testing; and
  • Effective selection of Delivery and project goals/priorities.

9. Inadequate Human Resources

Though unlikely, occasionally a stakeholder or development team member must leave a project unexpectedly. This can create a risk to the project, particularly if project knowledge is not adequately documented.

How do you reduce this software risk? Throughout a project it is valuable to:

  • Maintain up-to-date documentation;
  • On-board new or replacement stakeholders with a learning guide; and
  • Monitor the invoice schedule and team utilisation frequently.

10. Lack of Ownership

Why is a sense of ownership important for software development? Ownership in software is important to ensure there is always someone in the team who takes responsibility for the software being delivered, and is accountable for the successes and failures.

Unfortunately, this risk usually only becomes apparent when something goes wrong in a project. It therefore must be clear from the outset who is responsible for what aspects of the project, and when it is to be delivered.

How do you create accountability in software development? Some possible strategies include:

  • Setting responsibilities for stakeholders;
  • Open clear lines of communication between stakeholders by valuing transparency and honesty;
  • Record or document meetings and action items that may arise; and
  • Ensure User Acceptance Criteria are completed and approved by a Product Manager.

Though this list is by no means complete, it includes some important initial project considerations. Risk identification and management are crucial parts to the success of any software project.

Which of the following is the complete correct list of the software risk components?

Have you addressed all the risks properly in your Test plan or Test strategy? As testing is the last part of the project, it's always under pressure and time constraint..
#1) Schedule Risk..
#2) Budget Risk..
#3) Operational Risks..
#4) Technical Risks..
#5) Programmatic Risks..

What are the software risk components?

Using principal component analysis we identify six software risk components: 1) scheduling and timing risks, 2) functionality risks, 3) subcontracting risks, 4) requirements management, 5) resource usage and performance risks, and 6) personnel management risks.

Which of the following is a software risk?

There are three main classifications of risks which can affect a software project: Project risks. Technical risks. Business risks.

Which of the following are components of risk?

Three Risk Components.
values..
hazard..
probability..