Let’s Talk IT Project Failure: What Causes Requirements Volatility?

Scope change and frequent requirement modifications impact projects execution. Unpredicted changes that occur outside project planning are all encompassed by the concept of volatility. Lack and insufficient predictability of change creates volatile dynamics that impact execution and project’s deliverables. Endeavours with objectives to find and develop solutions suffer most from volatility, a phenomenon that directly correlate to the volatility degree. Although little control can be exercised on volatility, some instances can be managed or averted. However, the level of uncertainty exerts great influence on the overall volatility of the project.

Projects execution implies working with known unknowns. These referred to as known risks that may have or will have impact on the successful execution of the project. When lacking a clear strategy on how to manage this category of risks, the consequences that may have on the execution create volatility. In addition, variability within the working ecosystem of the project and unplanned events contribute to volatility. Lacking a clear understanding of the impact of these events on the execution phase rendered them unmanageable.

Volatility has been identified as one of the causes of IT projects failure. Volatility touches various aspects of the project, the technology in use, the relationship with the suppliers, resourcing and business requirements. I’ve experienced two examples of events that created project volatility with nearly failure consequences. In one instance, a key supplier withdrew from their contractual agreement with the project halfway execution. This has created a technology procurement void that was difficult to replace fast. The repercussion were the termination of the project and a lawsuit against the supplier. In another instance, over eighty percent of the project resources resigned in protest of the management style and decision. This has created a drain in local knowledge. Similar events in isolation or in combination can have detrimental consequences on projects. However, as business analysts we more concerned of a specific type of volatility: Requirements Volatility.

Frequent and unpredictable change in requirements leads to requirements volatility. Requirements volatility persists irrespective of software development methodology (Agile, Waterfall, JAD, etc.) or the requirements management process in place. None of the methodologies or processes guarantees no volatility.

‘Requirements Volatility’ is empirically defined as frequent changes to the requirements from the design phase to implementation. All software development methodologies assume that when requirements move to the design phase, then they are ‘complete’ and are not subject to change. However, that is not always the case. There is always some level of uncertainty and unpredictability throughout the development lifecycle. Even though Agile ‘welcomes change’ and claims the ‘collaborative and adaptive’ approach facilitates unpredictable change, this assumption will be challenged when the frequency of change is high. Requirements volatility imparts a significant risk to the project outcome. However, The BABOK ‘Requirements Management’ process does not include activities to manage volatility.

We should emphasise that requirements volatility is not ‘scope change’. They are two different things.

1. Requirements Volatility: Here, the scope remains static, whereas the requirements are dynamic. This is a micro-level change that eventually impacts the subsequent phases of designing and developing a solution.
2. Scope Change: Scope change manifests through ‘I want more’. This is a macro-level change that impacts the whole end-to-end solution. It is a redefinition of the initial agreed outcome.

Change in the scope can bring volatility to the requirements, but this is not always true.

Ideally, when requirements are validated and approved by the stakeholders, it is normally assumed that they are stable and that there will be very little change, if any. However, the requirements volatility defies the norm and invariably arise due to multiple causes. From my own experience, the reasons are unlimited but can be summarized as below:

1. Changes in the stakeholders’ needs
2. External factors
3. Internal factors
4. The magnitude of the change
5. The requirements analysis process
6. Organizational culture

Requirements volatility can have a significant impact on the development of a solution. This worsens when the degree of volatility is high. Some instances of volatility can be prevented; however, there is little control over certain causes of volatility. For example, external changes such as government regulation are not within the control of the delivery team.

Our needs are an offshoot of an ever-evolving mechanism. We tend to frequently change our minds, and sometimes we want the same thing with a slight variation. It is embedded deep within the human nature to change our minds.

External factors vary, but the most common ones are government regulation, market change, and economic climate. These factors might appear to be frivolous but have far-reaching consequences that sometimes lead to rigid changes, resulting in requirements volatility.

Although these are mostly ignored as factors of change, these are real, and they tend to skyrocket the level of volatility in the process. The following two scenarios are most pertinent:

1. In one of my projects, during the design phase, there was an organization structure change that resulted in a new project sponsor who adapted a divergent direction, changed priorities, and refocused on different aspects of the scope.
2. In another project during the development phase, the company made an acquisition and wanted to include the new company in the revised scope.

The complexity of the project is directly proportional to the magnitude of the change. Large and complex business transformations tend to be vulnerable to volatility. This is due to the large amount of information processed and the substantial risk of the unknown and quantum change that needs to be implemented. To top it all, there could also be an associated time constraint.

This is a phase where volatility can be minimized. The contributors can be classified into the following four types:

1. Process Maturity
2. Requirements Analysis
3. Business Analyst Experience
4. Organization Culture

Process Maturity:

This implies the maturity level of the process. Different organizations have varying levels of maturity in their project execution process. The Software Capability Maturity Model defines five levels of process maturity.

Simply stated, the less mature the process, the greater the possibility for volatility. Less rigorous processes lead to higher incidences of volatility.

Requirements Analysis:

The requirements analysis process is not an exact science and is invariably dependent upon the subjectivity of the stakeholders involved in the exercise. The inability to define the exact needs sometimes translates into inaccurate or ineffective requirement analysis. This results in a deviation from an ideal scenario that facilitates the determination of exact requirements.

A simplistic definition of requirements analysis could be to transform the unknown entity into a known entity.

• What are unknown entities?

Unknown entities generally take the form of undiscovered business needs whose impact is felt or a self-diagnosed problem that may or may not exist. A common ailment like a headache is often self-diagnosed, treated, or dismissed by most of us as an ordinary occurrence, whereas a doctor’s approach would differ significantly because the condition will first need to be validated before it can be treated. Here, the role of a business analyst can be aptly compared to that of a doctor.

• Transforming unknown into known

This is where a business analyst’s expertise enters the frame. The unknown factors that define a problem faced by a business are discovered and examined thoroughly by a business analyst. It is similar to when a doctor carries out a few diagnostic tests to gain insight into the patient’s headache.

If a high level of unknowns still persists at the time of moving on to the design phase, then the requirements volatility could potentially be high.

Business Analyst Experience:

A business analyst is primarily responsible for ascertaining and defining the requirements through an analytical process of requirement analysis. The requirements captured during this phase are as good as the BA’s ability to draw out the key requirements based upon inputs provided by multiple stakeholders. Further, a BA adds value to this process by using her/his expertise and experience to guide and facilitate accurate identification, capture, and definition of the requirements. Furthermore, it is his prerogative to ensure a comprehensive list that covers all possible aspects that are key to implementing the desired outcome. A lousy business analyst is the worst nightmare possible and will ruin the prospects of even the simplest requirement analysis endeavour.

Organizational Culture:

Every organization has its own set of values, rules, and practices that contribute to the culture of that entity. The culture can impact the requirements analysis process both directly and indirectly. Attitude toward requirements management can be a reflection of the organization’s culture. From my own experience, ‘lightweight organizations’ tend to communicate requirements and expect change irrespective of the projects phase. The impact of organizational culture on project execution and requirements management is a complex and undiscovered area of study.

Among the execution strategy options, Agile methodology is found to be the most suitable under requirements volatility. However, this does not imply that volatility has no impact on the project budget and schedule in Agile. Agility doesn’t imply a lack of volatility. Processes can get chaotic whether the execution methodology is ‘Agile’, ‘Waterfall’, ‘JAD’, etc. It makes a difference to have an experienced delivery team and seasoned business analysts.

Nobody likes unpredictability! It is risky and impacts the project cost. Requirements are the foundation for developing a solution. They provide the baseline for cost estimate and schedules; thus these are the ‘source of input’ for the subsequent phases of assessment, design, development, and testing.

Author: Adam Alami, PhD Fellow, IT University of Copenhagen

Adam Alami is a PhD fellow at the IT University of Copenhagen. Adam has a wealth of experience in information technology practices. He started his career as a software developer, then moved to business analysis and project management. His 20 years’ experience revolves around major business transformation projects and process improvement. He accumulated a wealth of cross industry experience in major projects in the areas of Enterprise Transformation, Integration, Migration, and Systems Modernization.