How to Deal with "Bonus" Features

Here’s the situation: You’ve created the best requirements document ever written. You are eagerly reviewing the output from the development team (High Level Design Documents if you are lucky, early releases otherwise). And then it happens… you find out that there are “features” coming from the development team that weren’t included in the requirements. This situation—developers adding features to the system that are not specified in the requirements—is known as gold plating.

What do you do?

Ideally, you stop the gold plating. Gold plating frequently indicates one or more organizational problems, such as:

• The organization does not understand that gold plating is a problem and that there is a high cost for this unnecessary development in the form of additional testing, documentation, and maintenance.
• The development process is not well-defined and the organization has not established a process for development which adheres to the requirements.
• The development process is well-defined, but management has either failed to communicate it or failed to enforce it.

If there is an organizational problem, it will typically take some time to fix. Unfortunately, while product managers can be the catalyst for organizational change, we typically do not have the authority to impose change. If you can’t immediately stop the gold plating, how do you address this situation?

Features have been added to the system, so the entire team needs to know about them in order to properly address them: the documentation team will need to write about them, the quality assurance team will need to test them, etc. The information about these features should be added to the documents used within your organization to understand the capabilities of the system. If you have design documents, it will fit nicely there.

When the requirements documents are the primary documents used to understand the capabilities of the system, my line of reasoning says the information belongs there. However, these new features are really not requirements because the business unit has not asked for them. What’s a product manager to do?

I was recently faced with this situation. After soliciting advice from my colleagues, I decided the best approach would be to add the information about these features to an appendix in the Software Requirements Specification. It worked well as features were documented in an obvious location, yet not presented as requirements.

And, for those of you who are wondering, yes, the entire team is working on process improvement as well.