Creeping Functionality, also known as Scope Creep is often described as “Death by a thousand cuts.”. It occurs when new functionality and features are constantly being added to a project that is already in progress. It can increase cost, push back the completion date, and severely damage development strategy for a project.
How does Creeping Functionality occur? After the Information Gathering phase of a project is completed with the Project Specifications and/or Proposal having been drafted and a contract is signed to develop and complete the project. During the Development Phase the client asks the Developer to make a negligible change. The change is so small compared to the entire scope of the project that it doesn’t seem to warrant a Change Order. These changes pile up during the Development Phase and after awhile the full scope of the negligible changes becomes apparent. The idea of writing twenty or thirty or a hundred change orders to account for the total time spent on changes outside the scope of the project becomes in and of itself a daunting and time consuming task.
Why does Creeping Functionality occur? One of the reasons that Creeping Functionality occurs is improper scoping of the project during the Information Gathering phase. Features and Functionality that are considered important were forgotten or not conceived during the Information Gathering phase and are now trying to find their way into the project after a contract has been signed.
Another reason that Creeping Functionality can occur is perceived value. Everyone wants the most bang for their buck and will try to slip in added functionality or cool features that will raise the perceived value of the finished product. At times individuals that were not involved in the Information Gathering phase of the project will begin to take an interest in the project and attempt to interject their own opinions and ideas into the project scope. Developers want to keep the Client happy and making small changes that allow them to look flexible can be a persuasive path to take. However, it comes at a cost.
Creeping Functionality can go unnoticed by Project Managers on both sides of the ball until budget and scheduling problems arise and bring the problem into the light. The budget can increase exponentially as hours worked on features and functionality outside the project scope pile up. Those hours that should have been spent on building the features and functionality inside the project scope push back the completion date of the project.
This is where perceived value and actual value come into play. It’s great to get the most out of your money, but at what other costs? Is the actual value of adding a negligible feature to a project more then having the project completed on time and within budget? The answer is a resounding no.
Creeping Functionality also taints any Development Plan that was put into place in order to keep the project on schedule and within budget. It divides developer/client attention between completing the project as defined by the contract and making the website as cool and feature packed as possible. It can be overwhelming and also cause tension. It can be very hard for a developer to say no to making a small change, and hard for a client to understand why when the developer does say no.
Managing Creeping Functionality is a very important part of Project Management. Getting the Project Scope right the first time and regular reviews of the Project Scope can keep it under control as to prevent problems.
It is important for both the Client and the Developer to be aware of Creeping Functionality and how to prevent it. At Storm Code we use a phased approach to development that can not only help prevent Creeping Functionality but also increases Actual Value, as opposed to Perceived Value.
Consider the original features and functionality of the project to be List A. Any features and functionality that were discussed during the Information Gathering phase that were seen as unnecessary or outside the current project scope, budget or time line are added to List B. List A has a deadline and a budget. After the deadline the website, or web application is released and the client makes it known that they have a new website or web application and people begin going to the site to check it out. This results in exposure, sales, leads, and much more. If Creeping Functionality had been allowed into the project then the release date would be pushed back and that exposure and everything that goes along with it would not exist.
List B consists of everything discussed during the Information Gathering phase that was not inside the original project scope, as discussed above. List B also consists of all the features and functionality that were thought up during the Development phase. In other words, all of the Creeping Functionality that could have effected the budget and time line. List B is considered to be Phase 2 of the project. After the website or web application is released, work on Phase 2 can begin. A new project proposal is drafted and contract signed. A new deadline and budget is created and work begins again anew. When the Phase 2 project is completed the Client can then spread the word that their website or web application (that is now no longer considered new) has some cool new features and functionality that everyone should come check out. If everything had been piled onto List A, it’s possible that the original project may not even have been completed by this time, and if it had, that would be it. No opportunity to invite users and potential clients back to the website or web application because no new features would be coming along.
A website or application is a marketing tool and nothing speaks better about a company or individual then if they keep their website or application up to date and constantly evolving with new, thought out, features.
For more information on Creeping Functionality please read this article by Steve Holder How to Keep Scope Creep from Sapping Project Profit