Why are software delivery teams eternally engaged in a battle to contain one of the most volatile aspects of software engineering, the scope?

Containment of scope is as much an art as it is a science. This article analyzes the root causes of scope expansion.

Since scope is a collection of requirements, let me define a 'good requirement.' A requirement is considered good if it is:
• Unambiguous • Comprehensive • Consistent • Enduring • Stable

Scope expansion is induced by the two main stakeholders: the customer and the delivery team.

Customer-induced scope expansion
Given below are various reasons for customerinduced scope expansion:

• • The customer operates in a greenfield (working in a new environment where there is no prior experience) that does not have mature processes and experienced staff to provide unambiguous requirements.
• • The customer does not have a central decision-making authority to come up with the final requirement. Before starting the requirement gathering exercise, it is then helpful to conduct a stakeholder analysis to understand the organization structure and identify the decision-makers for each functional area. This will help the delivery team to revalidate the requirements with the right stakeholders, if required.
• • The customer is experiencing frequent attrition, losing key people who had defined the requirements. Risk emanating from this needs to be accepted with a mitigation strategy adopted for potential scope instability and expansion.
• • A requirement tends to move from a state of instability to stability till that requirement is approved/baselined. Once this milestone is achieved, the requirement stability starts waning due to changes in the business and operational ecosystem. Hence, it is extremely risky to delay the delivery of a signed off requirement.

• • The delivery team is not familiar with the business domain. The vendor needs to take steps to ensure the right skill sets exist in the delivery team before embarking on delivery activities.
• • Poor business analysis skills to probe the customer to extract implicit requirements. With business modelling tools (like BPMN), this risk can be mitigated.
• • The business analyst is not looking at the requirements holistically. In large transformation projects, this risk is particularly high.
• • The poor communication skills of business analysts hamper in capturing requirement.
• Poor communication practices and skills in the delivery team impede the conveying/ translating of the business requirements to the solution building blocks.
• • Ambiguous and incomplete requirements are not supported with sufficient assumptions. Unfortunately, there is no easy way to acquire the skills to understand and frame the right assumptions. They can only be acquired with experience.
  
  

• • Poor tools used in capturing and articulating requirements. Completely relying on defining requirements in the chosen language may not be enough, especially when dealing with requirements that have complex business logic, process flows and decision controls.
  
  Degree of scope expansion risk related to maturity

• • Poor customer management – There is a tendency to gold plate the solution to keep the customer happy. There is not much benefit in adding scope that the customer never asked for explicitly.
• • Creeping elegance – This occurs due to over-enthusiastic team members who want to exhibit their technical prowess. These team members tend to add bells and whistles to the solution to make it appear more elegant, though the customer had not asked for those. Project managers should keep an eye on such tendencies.
• • The vendor is experiencing frequent attrition of key people who had captured the requirement and were well aware of the customer’s business model, their corporate culture, and business strategy and direction.