Blog Archives

Tip #3: How to Avoid Feature Creep and Scope Creep During Product Development Lifecycle

Scope Creep. Feature Creep. Creeping Featurism. Featuritis. Project Creep. These are all terms used to describe the state in a project where the scope or features of the product continually change as the project progresses. Many of the articles written regarding scope/feature creep discuss software feature creep or methods of managing creep. Of course, feature creep is an issue that can adversely impact any project, including software, hardware, or service. If it isn’t avoided and managed properly, the project will end up at the point of no return.

Here are some methods of avoiding feature creep during the product development process.

A. Focus the team on the project priorities. There is always a tradeoff between product cost, program schedule, and product features/scope that cannot be ignored. One objective cannot be changed without affecting the others and a successful team leader is one who will prioritize these objectives. If the team is focused on these priorities then feature creep will take a back seat to proper program management. For example, if Project Scope is prioritized on the program, then it would be acceptable for the program manager to methodically consider new features. But if Product Cost or Program Schedule were the highest priority, changes in features would typically never be considered. One program that was successfully introduced into the market in less than six months was the Floe Winter Drainage System by Apt Innovations located in Northern Ireland, United Kingdom. The Managing Director Jason Paul was very thoughtful in his approach to managing the project. He stated clearly that the priorities of the program were (1) Program Schedule, (2) Program Scope, and (3) Product Cost. This allowed him to make wise decisions about avoiding any creep of the product features when he learned more about new potential customer segments for his product. He left these changes to the next product iteration.

B. Create and manage a product requirements document. It is extremely important that a program is initiated with a formal phase of documenting the program requirements. These requirements are driven by the customer and require in depth research to determine exactly what the customer wants and needs. Once the customer requirements are documented, the engineering team can translate these customer requirements into engineering requirements. This allows the engineering team to initiate their work and begin design and qualification. When features are changed or new features are introduced, the engineering team needs to revisit the engineering requirements document and rework many of the designs and qualification tests already performed. This results in wasted time and money.

C. Feature scope, if any, should only be customer driven. If a product program is being managed with a top priority of product scope, changes in the scope or features can be considered. Sometimes it is necessary to make changes to the features based on new learning from the market and customers. It should be noted though that the marketing team needs to be careful that they don’t react too quickly to requests by customers as this will end up whip cracking the engineering and development team. If features changes are going to be made, make sure that the customer was the original reason for the change.

D. Create a process to evaluate all potential changes to the feature list. When changes are going to be seriously considered, it is necessary to have a team process that is used to make a decision to implement or discard the new feature. The program manager should implement a review process that the whole team understands and follows. The evaluation team should consist of all functional members including technical, financial, marketing, and sales so that all member’s needs are considered. The decision criteria should be an objective metric that considers all financial and schedule outcomes of the decision such as net present value (NPV).

Successful product development teams focus on their original product requirements and don’t let scope and feature creep derail their schedule and financial goals.

Need more information? Please contact us with any questions or contact me directly at joseph.donoghue ( at ) leardon.com