Project Management

Project Management Central

Please login or join to subscribe to this thread

How do you deal with gold plating in your project?
How do you deal with it in reality?
Sort By:
Page: 1 2 next>
Try and educate the team that gold plating is actually more detrimental than beneficial.
From a software perspective, sometimes it's an obvious case, if the project is getting behind schedule, or if there are more quality issues than expected. (sort of an "I told you so" situation) :-)
Ugh...When you get pushback on missing items from a requirement, but time was spent on items not in the requirements [disucssion] at all.

The stories of when development best practice is ignored b/c not explicitly spelled out in the requirements; decided to make business functionality decisions on their own b/c they thought it was a good idea .... go figure
Edcuate the team and make sure they are aware of what Gold Plating and Padding are. Both could be detrimental to your project and reputation.
This is a benefit of having explicit acceptance criteria for all work items as those tell folks when to stop adding in functionality...

Sometimes team member out of enthusiasm, and their perception of value to customer, provides more effort to do their best. As a PM, one must be vigil and on lookout for the team members. Best is proactively to educate the team as quoted above by Sante and Rami.
Put the WBS and all associated requirements documents under configuration control. Then implement formal change control. Any changes to requirements or scope must be justified, a case made for it, and the change control board approves it. This is what we do and it's very effective.

sometimes gold plating is good (e.g. result delights the customer, keep team experimenting and happy, improve requirements as understanding increases),
sometimes it may be detrimental (e.g. if the team is procrastinating, if schedule slippages occur, if stated requirements are tweaked without concurrence by the client), so it is a situational balance.

If you want to avoid it, be clear to yourself why and it is really what you want.
Strategies to avoid gold plating are, for example
- keep schedule pressure on the team, e.g. by using critical chain principles
- define development policy accordingly
- communicate expected behaviours
- establish tight change control

Often, gold plating starts from the top down by promoting priorities such as Exceed Customer Expectations, Delight the Customer, etc.

One of the responsibilities of the PM is to manage expectations. Configuration control by itself is not enough, because by design the WBS is written to provide some limited flexibility. Not every pen stroke requires a change board, or you get bogged down in bureaucracy. Teams can lock down a bloated work statement easily, if nobody is scrutinizing the plan against the requirements.

In some organizations where managing scope creep is a high priority, the PM has to scrutinize every entry in the WBS to determine if it is appropriate per contract, or excessive. (Must have vs. nice to have)

One place I worked, we held formal reviews we called "Bright Light", named after the old police dramas where they shined a light in the faces of people being interrogated. I personally thought The Spanish Inquisition was a bit much, however we frequently found cases of "while we're in there we might as well do this too...", or cost padding at every layer resulting in as much contingency funding as there was expected work.
Making the work to help people who are in charge to take the requirements and make them a reality about the risk and issues that gold plating creates mainly when is out of control without some type of change management control. And mainly helping them to understand the extra work they will take themself. It is a matter to work on quality systems implementation then it has been taken from a system theory perspective.
Page: 1 2 next>  

Please login or join to reply

Content ID: