Everyone knows about scope creep and the detrimental effect it can have on a project. But we seem to have misplaced the blame for its causes. Traditionally the view has been that the project manager is responsible or that there weren’t proper change procedures in place. In reality, this comes from how the scope is defined in the first place. In an article for Project Times, Robin Goldsmith sheds some light on what the real culprits are when it comes to scope creep:
- Scope defined in inappropriate terms
- Scope defined (often dictated) prematurely
- Scope predicated on presumed product
Keeping That Creep Away
The scope of most projects starts out pretty ill-defined. Many are a sentence or two long, outlining objectives to be achieved. The problem therein is that it leaves too much room for interpretation and creates an ambiguous view on how to achieve these objectives. Even when tasks are lined up in specific terms, which is a tactic employed by vendors, a project can still suffer from scope creep if the client chooses to continually add more tasks to the preexisting ones.
Another way scope creep occurs is when an executive mistakenly assumes that their stance in the company gives them the knowledge required to dictate the scope of the project. Granted, some organizations might conduct feasibility analysis to reinforce decisions, but the findings are often smoke and mirrors intended to validate the current stance. Goldsmith even goes on to say that agile is particularly susceptible to not defining the scope properly:
Organizations that consider themselves Agile may not be defining the scope explicitly at all. They may simply leave it up to the Product Owner to decide what goes into the backlog, which some may consider defining the scope. Also, Agile projects would seem highly unlikely to have formal project initiation procedures. Recognize though that these Agile actions actually may reflect informal, implicit decisions that are equally premature. Thus, the backlog may include only stories that fit the Product Owner’s possibly fuzzy impression of what is in scope; and that impression could constantly change, though perhaps without awareness or thoughtful consideration.
Goldsmith goes on to say that the scope shouldn’t be dictated by the product that is expected to be produced, because the product as originally envisioned may not have real value. A product must be defined according to high-level business requirements before it can be reliably used to set scope.
You can view the original article here: https://www.projecttimes.com/articles/avoid-the-top-three-real-causes-of-scope-creep.html