Failure to Launch: Scope Creep and Other Causes of Failure from an Actor-Network Theory Perspective

Scope Creep And Requirements Triage

Scope Creep is defined as any additional requirements arising during the course of a software development project (Nurmuliani, Zowghi, & Fowell, 2004; Thakurta, 2013; Zowghi & Nurmuliani, 2002). Scope creep is a specific type of Requirements Volatility where the additional requirements are added instead of changed or removed. Any requirements changes that occurs throughout the development process will likely affect the completion of the project. Additional resources (likely including human, technical and financial resources) are then needed, and this will also affect the time needed to finish the project (Brooks, 1995; A. M. Davis, 2005). The Project Management Body of Knowledge (PMBoK) considers that project scope is a serious issue and has a whole section on Project Scope Management and the problems of scope creep (Project Management Institute, 2013). This includes discussion on the collection of project requirements, defining project scope, creating a Work Breakdown Structure, verifying scope and controlling scope.

Although scope creep is considered undesirable by most developers, the reality is that scope creep will often emerge during the development process and is often inevitable (Khan, 2006). Any change in the users’ business needs, changes to the external environment, or even only changes in users’ minds would justify the need to add additional features (A. M. Davis, 2005; A. M. Davis, Nurmuliani, Park, & Zowghi, 2008) and managing scope creep becomes an essential task within a software development project (Thakurta, 2013; Thakurta & Ahlemann, 2011; Zowghi & Nurmuliani, 2002).

Scope creep is not something that is unusual in any engineering of information technology project, including software engineering. Good project management is required to keep the project on the right course towards completion. All the project’s stakeholders need to understand the impact of scope creep toward project completion and also at the end of the project, the functionality of the software produced. Having to understand the impact of any change in requirements the stakeholders can then decide if the changes were needed and justified. However, different stakeholders have different views on what changes are needed. The project manager needs to try to achieve compromise and consensus among the stakeholders.