There are often very good reasons to consider features after the scope has been defined and ratified, but feature additions introduce risks that need to be managed carefully to avoid overruns in cost or schedule, or jeopardize a 60601 submission or FDA audit.
A development project has a much greater chance of success if the following sections are included in the proposal and agreed to by all parties:
Project Deliverables. The Deliverables section of a project statement lists every feature or element that is to be verified to demonstrate completion of the project. If it’s in the deliverables list, then incorporating it adds risk to budget, timeline, and regulatory compliance.
Scope of Work. The Scope statement delineates what type of work will be undertaken to achieve each deliverable. The Scope Statement should include only everything necessary to complete the project objectives – nothing more, nothing less. If there is any risk of confusion, listing work that is out of scope is a good idea.
Risks and Assumptions. It’s important to identify risks areas for scope creep. It’s equally important to provide a mechanism for new features to be incorporated into scope as the project unfolds and new discoveries are made.
Here are some good reasons why under-the-hood features and hooks should be included within the scope of the project:
- Future-proofing the hardware, if the hardware life cycle is long
- Design for Manufacture, Design for Test, Design for Regulatory Compliance
- Early-stage feature evaluation and development – it’s best to fail early
- Risk reduction prior to major investments in design iterations
Here are some bad reasons:
- To “wow” the client or the client’s business partners
- To demonstrate future product variants or potential that may or may not have been discussed, or that might or might not be aligned with the client’s stated business case
- To evaluate potential solutions for future development work on a similar platform, either for this or for other projects or clients
I find it best to discuss feature options with clients before the project starts, or as the ideas arise once a project is underway. I like to log them for future reference so they become part of the “lessons learned” at the end of the project.
Effective scope management prevents death – or at least serious maiming – by a thousand cuts to the project budget and/or timeline. It also minimizes the risk of trouble with 60601 and FDA submissions and audits.