The instigators are all well-intentioned – executives talk to potential customers who “must have” a few more things; or the technical team edicts some “technically elegant” options that they can’t resist adding before release. The result is a bloated first product which finally collapses under its own weight, or is too late and too expensive for the intended customer.
The best product is one that is highly focused, and has the absolute minimum number of features to do the job. The solution is to do the right job up front on requirements, document and approve specifications, and have the toughest person you know do the project management. Here are five basic rules to live by:
-
Document the requirements. A well-run requirements phase is your best chance to ensure that scope creep will be recognized when it happens, and it will. If initial requirements are not documented, then there is no base, and no one can recognize that the stack is getting higher as time passes.
-
Lock down the sign-off authority. In all documents, clearly define who must sign off on content and provide business-side feedback. If you are the sign-off, don’t be afraid to say “no.” Draw the line between need versus want. Founders who constantly give in to changes will get more until the startup breaks.
-
Final features approval event. Make a visible event at the executive level out of the final specification approval, detailing features, costs, and time frames. Make sure everyone knows that changes after this point will have personal consequences, and will delay the product and increase the cost.
-
Define milestones for cost review and sign-off. Milestones are for early warning, because there is no recovery when you are out of time and money. Good milestones include completion of specifications, prototype, beta testing, final documentation, and final delivery.
-
Implement and enforce a change process. Changes will be required to every project, so plan for them. The market changes, executives learn new things, customers demand changes, and technology changes. Change requests should be documented, sized, and tradeoffs presented for approval or disapproval.
Efforts to discourage scope creep are not designed to punish creativity. Rather, team members should be encouraged to contribute to a database of additional features that they think would be interesting and useful, and submit them as change requests on a weekly basis.
Change requests must be visibly reviewed by executives frequently. If the features are interesting but not necessary for initial release, they can be scheduled for further development on later releases of the project, whether it be new software, a car, or any other sort of device.
There's always going to be something newer, something faster, something bigger; and the perfect product is a never ending chase — but only if you allow it to be. Remember that in new product development, as in writing, addition by subtraction is the Golden Rule.