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

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

Samiaji Sarosa (Accounting Department, Atma Jaya Yogyakarta University, Yogyakarta, Indonesia) and Arthur Tatnall (Victoria University, Melbourne, Australia)
DOI: 10.4018/ijantti.2015100101
OnDemand PDF Download:
No Current Special Offers


One of the main causes of delayed and failed information systems project development is scope creep. The increasing number of features demanded by stakeholders to be built into the applications within a fixed time limit is a recipe for failure. This article looks into the process of a web application development failure, where scope creep was deemed as the main cause. An in depth look into the time line of the project also reveal another cause, which was the failure of the application itself along with the platform (hardware and software) to actually execute the software. It is believed that an Actor-Network Theory framework is appropriate to analyse this case where a number if both human and non-human actors were involved. Data for this research was collected using participative observation. An analysis was conducted to find patterns of negotiations and communications between all the stakeholders during the design process. Actor-Network Theory was used to explain the power plays between actors. A model was constructed showing all the actors (stakeholders) and how the interplay among them developed.
Article Preview

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.

Complete Article List

Search this Journal:
Open Access Articles: Forthcoming
Volume 9: 2 Issues (2017)
Volume 8: 4 Issues (2016)
Volume 7: 4 Issues (2015)
Volume 6: 4 Issues (2014)
Volume 5: 4 Issues (2013)
Volume 4: 4 Issues (2012)
Volume 3: 4 Issues (2011)
Volume 2: 4 Issues (2010)
Volume 1: 4 Issues (2009)
View Complete Journal Contents Listing