This post is in response to a post written by Jennifer Bedell on the PMStudent blog about goldplating.
Goldplating is very common in application development and can be very expensive. If you're dealing with Waterfall, it's a little more obvious when it's happening. Some may argue, but I've seen it happen in Agile as well. I've sat across the table from a vendor and asked, are you prepared to roll back every one of these changes? Their eyes get big because why wouldn't the client want these changes? Well, too many times a developer is in the code and they think, while here, why not make this additional change we planned to do next month. Or, now that I'm here, it makes a lot more sense if I do it like this versus what we originally thought.
In short, Jennifer wrote about goldplating caused by testers. She asked
why is it always the developers who get blamed for goldplating? When you consider the cost of change increases as the project timeline progresses, it becomes evident that, in addition to increasing scope, goldplating by a developer can also be costly. Goldplating by a tester can occur when a tester goes beyond the stated requirements in an effort to produce a “quality” product. A tester may feel that their suggestion would improve the customer experience so they log this in the defect log. While their suggestion may do exactly what they envisioned, if it was not within the scope of the stated requirements, it becomes a form of goldplating or “feature creep”. A tester’s job is to ensure that a quality product is delivered, but many testers rely on their own definition of quality rather than using the requirements to define quality...
I’ve seen team members at every stage of the Software Development Life Cycle (SDLC) attempt to goldplate, with the best of intentions. Regardless of where you are in your development process, any time there is a requested change to the baseline, there should be a control mechanism. I call that mechanism a triage. Be it the customer or a customer representative (Project Manager, Product Owner, or BA), someone needs to vet anything and everything which could impact the baseline. These changes need to be prioritized and reviewed. I'm not saying changes should not be made. I'm saying they need to be properly vetted. Changes impact the schedule, the budget, and in the end...customer satisfaction.
Without this control point, I think you’re guaranteed to see creep somewhere in your project and you will see it begin to bleed time, money, or both.
Yes, we certainly want to deliver the greatest value to the customer. But, creep increases risk and that’s not value.
Am I just a control freak or do you agree with me?