Containing Volatility of Scope
This article is based on the author’s experience in delivering software solutions in the capacity of an architect. The article delves into various reasons for scope expansion, and classifies these reasons in terms of customer- and vendor-induced expansions. An attempt is also made to define a good requirement, as that is an important building block for the overall scope of delivery.
Why are software delivery teams eternally engaged in a battle to contain one of the most volatile aspects of software engineering, the scope? Regardless of the amount of effort and best practices employed to contain this, it has the uncanny ability to escape the confines established by the delivery team. Containment of scope is as much an art as it is a science. The three key players of the delivery team, the business analyst (BA), architect, and project manager, are equally accountable for containing the scope that can rear its ugly head from different areas of the overall solution at the wrong time. This article is an attempt to analyze the root causes of scope expansion, putting agreed cost, time, and eventual quality at risk.
There are various terminologies in vogue when it comes to scope, like scope creep, creeping elegance, gold plating, etc. For simplicity, I will use the term scope expansion to indicate all such scope changes that impact cost, time, and
Please log in or sign up below to read the rest of the article.