Why Do Software Projects Fail? Understanding the Root Causes
Software projects often fail due to a combination of challenges inherent in the development process. Complex project scopes, poor communication across large teams, and insufficient requirements gathering are all common pitfalls that can derail even the most ambitious initiatives.
How Often Do Software Projects Fail?
The failure rate of software projects is alarmingly high. Research from Boston Consulting Group and McKinsey highlights that an estimated 70% of digital transformation projects fail. But why?
A study by Info-Tech Research Group reveals that 70% of these failures stem from issues with requirements gathering. Combining these findings suggests that approximately 49% of digital transformation projects fail due to poor requirements management. That’s nearly half of all projects—a striking insight into the critical importance of clearly defining and managing project requirements.
To mitigate these risks, organizations must focus on fostering clear communication, detailed planning, and rigorous requirements analysis.
Improving the Requirements Analysis Using AI
To improve the analysis of requirements and therefore improve the quality of software from the outset, Inflectra has partnered with QRA Corp, the creator of the QVscribe requirements analysis tool to develop a new SpiraApp that will allow you to perform automated analysis of your requirements natively inside your requirements management tool for the first time.
We plan on releasing this new functionality in Q1 2025 both as a free SpiraApp for existing QVscribe customers (with a Bring Your Own License option) and a paid add-on for Spira customers that are not already QVscribe customers. In this article we are going to outline some of the new functionality you can expect to see in the final release. If you are already a joint QVscribe and Inflectra customer, please contact us to join our beta program.
Analyzing a Single Requirement
Using the new menu entry added to the requirements detail page, you can choose the option to analyze the current requirement. For this to be available, the requirement needs to be in an editable status:
Once you have chosen the option to analyze the requirement, the SpiraApp will contact the analysis service, send the requirement name (and optionally description) to be evaluated, and once the analysis is complete, update the requirement with a graphical score from 1-5.
Analyzing Multiple Requirements
In addition to analyzing a single requirement, you can also use a similar new menu entry on the requirements list page to analyze multiple requirements at the same time. You simply select the checkboxes for the requirements to be analyzed, and then click the Analyze Requirement menu entry:
Once the analysis is complete, a special Score custom property will be populated with the analysis Score (1-5). You can sort/filter this column as well as view the score graphically.
Viewing the Analysis Score and Identified Nouns
Now lets take a deeper look at what the results of the analysis look like. Firstly, regardless of whether you analyzed a single requirement, or multiple, the system will update the Score value, provide detailed recommendations as to what needs to be changed, and finally displayed a marked-up version of the requirement so that you can see the recommendations in context:
The requirements analysis Score is a measure of the quality of the requirement. It can have the following values:
- Score 1 (Very High Risk): The requirement lacks an imperative, or contains multiple imperatives, and/or contains excessive vague terms. The requirement could also have multiple instances of low-risk errors such as excessive continuances, vague phases, etc which have a cumulative effect on the score. Consider rewriting the requirements or separating into multiple concise requirements.
- Score 2 (High Risk): Includes multiple instances of vague, subjective, or weak terms, and/or negative imperatives. Replace negative or ambiguous terms with clear and concise terms.
- Score 3 (Medium Risk): Includes a single instance of a vague, subjective, or weak term, and/or a single negative imperative. Replace the negative or ambiguous term with a clear and concise term.
- Score 4 (Low Risk): May include excessive use of continuances, and/or No directives. Check the flow and clarity of the requirement.
- Score 5 (Very Low Risk): Includes clear and unambiguous terminology to express the requirement.
In addition to the Score, the analysis service will return back a list of key Nouns that it has identified in the requirement. The plugin has an optional setting which tells the SpiraApp to update the requirement tags with the list of nouns. That lets you more easily find related requirements that refer to the same nouns. This can be done by just clicking on the tag in question.
In the Detailed Analysis section of the requirement, the SpiraApp will list out all of the reasons that explain why it was given a specific score. For each reason the SpiraApp will also give a positive and negative example of the specific reason, as well as giving hints and guidance for how to correct it.
Below the reasons, the detailed analysis will also include a bulleted list of nouns that were identified in the requirement text.
Finally the Markup section shows you the original requirements' text with the reasons and nouns highlighted inline (if applicable)
This information will help the business analysts improve the quality and specificity of the system's requirements.
Requirements Analysis Dashboard
Once you have completed the initial analysis of the product's requirements, you can add a special Requirements' Analysis Summary widget to the Product Home dashboard. This will show you the number, and percentage of requirements that are in each Score category:
As your business analysts and other team members follow the recommendations to improve the requirements' quality score, you can simply refresh this page to observe the improvements in real-time.