once worked with a developer who showed up at every product demo and constantly suggested improvements for the product. Don't get me wrong. Feedback is important and you shouldn't discourage developers from providing it. But there is a time and place for everything.

Besides the fact that this developer kept taking the demo off track and wasting everyone's time, his feedback, when accepted, had a huge impact on the project schedule.

"It's just a button" was his answer to every objection based on the project schedule. This guy always managed to convince Product Management that he could do it in 5 minutes. I'm sure he could add a button to a UI in 5 minutes, but this button had a lot of repercussion.

For one, this button needed an action attached behind it, which didn't yet exist. Furthermore, adding a button would mean updating the SRS, user documentation, and test cases. Finally, it had impact on other applications that were affected by the action attached to this button. Not only did we now need to modify these other applications, we needed to write an upgrade script for our existing customers who were migrating from an earlier release to this new and improved version of our software.

To make a long story short, his 5 minute button lead on average to a 4 day effort.

If you're still at the Definition stage of your process, then you should at least consider the value behind this button, and whether or not it's worth the effort. If you're approaching the end of the Construction phase or entered the Verification phase, don't! Make it clear that gold-plating is not acceptable and that under no circumstance will you risk your deadlines for it.

Don't confuse the scenario where a developer who likes to hear his/her own voice constantly proposes gold-plating features with that of a lead customer who discovers a show stopper that must be rectified. The first is a classic mistake that you must control, and the second is strictly a fact of dealing with customers - one that can be reduced in frequency by introducing best practices such as Rapid Prototyping or JAD sessions!

Luc Richard is professional speaker and author with over 10 years of experience managing the development of software applications. He can be reached via The Project Mangler (http://www.projectmangler.com).

Article Source: http://EzineArticles.com/?expert=Luc_Richard