This is a place for me to keep notes from across multiple sources regarding the definition of “feature creep.”
It seems there are multiple project management phenomena being conflated with the term. My personal definition of “feature creep”, based on my practical work in IT and without having reviewed the MIS and PM literature, would have been something like this:
Changes to an existing spec that introduce new functionality and requires additional development work.
Some details:
- Changing a spec prior to sign-off, hand-off, or the beginning of development would not be feature creep.
- Changing an existing spec by removing features is not creep.
- Changing a spec by swapping features with zero effect on the overall amount of work done is not creep.
- “Creep” also implies multiple slow changes over time, though my definition would disregard interval and scale of changes.
That definition needs to be compared to the literature. Considering that much of the management information systems (MIS) literature deals with “traditional” waterfall development methodologies, it seems natural that the definitions seem to include some delineation between phases of waterfall development.
Boehm (1991) lists “Continuing stream of requirements changes” as a top-10 software risk item, and suggests the following items for managing that risk: “High change threshold, information hiding, incremental development (deferring changes to later increments)” (p. 35). This is “based on a survey of several experienced project managers” but the survey is uncited.
Aside from the descriptive name for this risk, Boehm does not provide a definition. Since change management seems to be the controlling mechanism, one might presume Boehm is talking about a risk that happens after a spec is defined and handed off.
Lee & Lee (2015) cite Norman (1998):
adding and emphasizing features has become more popular than in the past, and many products, such as software, now have excessive functionality. This phenomenon of adding features to or emphasizing the current features of a product is termed ‘feature creep’ (Norman, 1998).
Here, feature creep is bloat, without regard for whether the additional (unnecessary) features are part of the original spec.
This is like Shmueli’s definition, which uses “over-requirement”: “When a product or a service is specified beyond the actual needs of the customer or the market” (Shmueli, 2014, p. 380). Over-requirement is defined as synonymous with over-specification and gold-plating. The implication is that over-requirement only happens during spec writing:
The over-requirement phenomenon is common in software projects and it is seldom reversible since it is very difficult, if not impossible, to eliminate from the overall project scope software features that were introduced during the requirement-engineering phase or later (Shmueli, 2014, p. 380 citing Dominus, 2006 and Wetherbe, 1991).
Surowiecki’s (2007) definition defines feature creep by describing projects that embody it. With this definition, we have no way of telling when the bloat happened.
too often it seems to make things harder, leaving us with fifty-button remote controls, digital cameras with hundreds of mysterious features and book-length manuals, and cars with dashboard systems worthy of the space shuttle. This spiral of complexity, often called “feature creep,” costs consumers time, but it also costs businesses money.
Elliott (2007) describes creep after requirements gathering and spec writing are done. By attempting to reduce risks associated with time-to-market, organizations are more prone to feature creep:
From a project manager’s point of view, feature creep is defined as changes in features while a product is still in development. It is also known as requirements creep, mission creep, scope creep or featuritis. In a small, fastmoving product development organization characterized by rapid innovation, ideas come quickly, rigid procedures do not. The organization counts on the good judgment and experience of its members to release a successful product in the market, without the bureaucratic overhead of rigid procedures (p. 304).
An extended Elliott excerpt explains there are many sources of bloat, both before and after specs are defined and development begun. Emphasis is mine for a later point:
New features may come from several sources, first from customers or their representatives in the organization, usually Sales, Marketing, or Applications – the people who have customer-facing jobs. Such new features are compelling because they come directly or indirectly from someone who may buy the product. Similar to the internal customer-facing folks, members of upper management may come forward with new features, possibly from interactions and pressure from customers or their representatives, or just from their own innovation. For that matter, anyone in the company may come up with a good idea that results in a feature on an upcoming product.
Once a project is launched, the engineers involved in design and development may also generate new features. This is a natural result of building something new and exploring new territory, What needs to be done cannot be fully known at requirements writing time. New needed features become apparent as the developers plunge into the details of the product and the technology. However this tendency of engineers to identify, self-approve, and implement new features can turn into a non-optimal behavior from a project completion standpoint. This behavior may derive from perfectionist tendencies engineers often exhibit, which is a positive trait when applied to developing a robust product and crushing bugs, but can be less than optimal when trying to stop feature creep. This is a case of the ”perfect” feature list becoming the enemy of the “good enough” set of features. This situation generates the often used phrase: “It’s time to shoot the engineer and release the product.”
It is clear that engineer-generated new features represent built-in creep because they sometimes discover the necessary features after the requirements definition phase, when the development starts. However, new features will creep in from outside the engineering organization as well, after the project starts. Fundamentally, during the finite time that always exists between requirements definition and product release, conditions change. Besides the engineers’ new visibility into technology issues, customers and their representatives may achieve new visibility in the market during that time. Also, the actual business conditions can change, such as the market itself changing or a competitor may change how they are addressing the market, which is known as the Killer-App source of feature creep [1] (p. 304).
I think the bold text illustrates the core feature creep risk, as I understand it. While engineers can have great insight that leads to interesting new features, they can also threaten projects with the same behaviors. Even when late feature ideas originate outside the product team, they still need to be accepted and implemented by those creating the product. My interest here is: To what extent does their identification with the technology being created impact these behaviors? If IT identity does affect risk behavior, what sort of interventions would most benefit projects?
Citations
- Boehm, B. W. (1991). Software risk management: principles and practices. IEEE Software, 8(1), 32–41. https://doi.org/10.1109/52.62930
- Elliott, B. (2007). Anything is possible: Managing feature creep in an innovation rich environment. 2007 IEEE International Engineering Management Conference, 304-307.
- Lee, B. & Lee, W. (2015) Feature Creep in Design Students’ Works: Why and How it Happens in Student Design Processes, The Design Journal, 18(3), 345-365, https://doi.org/10.1080/14606925.2015.1059603
- Norman, D. (1998). The invisible computer: Why good products can fail, the personal computer is so complex, and information appliances are the solution. Cambridge, Mass.: MIT Press.
- Shmueli, O., Pliskin, N., & Fink, L. (2015). Explaining over-requirement in software development projects: An experimental investigation of behavioral effects. International Journal of Project Management, 33(2), 380–394. https://doi.org/10.1016/j.ijproman.2014.07.003
- Surowiecki, J. (2007, May 21). Feature Presentation. The New Yorker. Retrieved from https://www.newyorker.com/magazine/2007/05/28/feature-presentation