Gold Plating in Project Management: Guide & Examples [2026]

Every team has a member who finishes early and thinks, "the customer will love this." The intention is good, the feature may even be impressive, and the result is still a problem. Nobody asked for it, nobody approved it, and somebody now has to pay for it, test it, and support it. This guide explains gold plating in project management: what it is, why teams do it, how it differs from scope creep, real examples, how to prevent it, and how it appears on the PMP and CAPM exams.

What is gold plating in project management?

Gold plating in project management is adding features or extras to a deliverable that the customer did not request and that were not approved through change control. It usually comes from the project team, often with good intentions. The extras may be small or large, free-looking or expensive, but they share one trait. No one with authority over the scope agreed to them.

The term borrows from jewelry, where a thin layer of gold makes an ordinary object look more valuable. On a project, the gold is the unrequested extra (an additional report, a more elaborate design, a feature that "only took an afternoon"). Like the jewelry, it looks like added value but costs more than it appears to.

PMI is explicit about this. The PMBOK® Guide, Eighth Edition, defines project management as applying knowledge, skills, tools, and techniques to project activities to meet or exceed the intended value. It then adds that meeting or exceeding value "does not mean to endorse or accept gold plating or scope creep." In other words, PMI wants teams to exceed value through deliberate, value-driven decisions, not through extras added on their own initiative. The same guide lists preventing gold plating as part of continuous scope management.

Why do teams gold plate?

Teams usually gold plate for understandable reasons, such as pleasing the customer, showing their skill, filling spare time, or making up for a weakness elsewhere in the deliverable. Very few teams do it carelessly. That is exactly why it is hard to stop.

The most common causes are the following:

• Pleasing the customer. A team member believes the customer will be delighted by the extra and assumes approval is a formality.
• Showing skill. A developer, designer, or engineer wants the work to reflect their craftsmanship, beyond what the requirement needs.
• Spare capacity. A task finishes early, and the time is spent improving the same deliverable instead of moving to the next approved item.
• Covering a defect. An extra is added to distract from, or compensate for, a requirement that was not fully met.
• Vague acceptance criteria. When a requirement is underspecified, team members fill the gaps with what they think the user "obviously" wants.

Note that the last cause is a project management problem, not a team problem. If acceptance criteria are vague, the team has to guess where "done" ends, and guesses tend to grow.

Ready to take the next step in project management?

200,000+ Professionals Taught by Our Instructors

PMP® Certification Training

PMP Training →

CAPM® Certification Training

CAPM Training →

Learn Project Management

PM Course →

Why is gold plating bad?

Gold plating is bad because it spends the project's time and money on work that has no approved value, and it adds risk that nobody planned for. Even when the extra is genuinely useful, the way it arrived bypasses the decisions that protect the project.

The main consequences are the following:

• Cost and schedule. Every hour spent on the extra is an hour not spent on approved work. On a fixed-price contract, the seller absorbs the cost.
• Risk and quality. The extra was not planned, so it was not designed, reviewed, or tested like the rest of the scope. It can introduce defects into work that was otherwise sound.
• Acceptance problems. The customer may not want the extra. The team then has to remove it, which is rework, or argue about it at acceptance.
• Expectation creep. A customer who receives free extras learns to expect them. Future projects inherit a standard that was never priced.
• Lost traceability. Work that traces to no requirement weakens the link between what was approved and what was delivered, which is what audits and acceptance depend on.

Consider a team that adds an elaborate dashboard to a reporting tool "at no extra cost." Three weeks later, a security review finds that the dashboard exposes data the customer's policy restricts. The fix delays the release, and the customer never wanted the dashboard in the first place.

Gold plating vs. scope creep

Gold plating and scope creep both add work that was never properly approved, but they start in different places. Gold plating is extra work the team adds on its own initiative. Scope creep is uncontrolled growth in the scope, usually driven by requests from the customer, the sponsor, or other stakeholders.

The two problems are closely related. Both bypass change control, both add cost and risk without approved value, and both are prevented by the same basic discipline. Every change to the scope is documented, assessed, and approved before the work is done. As a result, the project manager is responsible for preventing both.

Examples of gold plating

Examples make the line between gold plating and good service easy to see. The difference is never the quality of the idea. It is whether the idea went through an approval.

The unrequested feature. On a customer self-service portal, a developer finishes a module early and adds a live chat widget because "customers always want chat." The chat widget was deliberately placed in the won't-have category for this release in the team's MoSCoW prioritization, because the support team cannot staff it yet. The widget is gold plating. It also reopens a decision the stakeholders had already made.

The over-engineered deliverable. A construction team installs higher-grade fixtures than the specification requires, believing the client will appreciate the upgrade. The client's budget did not include them, and the maintenance contract does not cover their parts.

The same idea, done correctly. On a software project, a team member suggests adding electronic invoicing. The project manager presents the idea to the customer with its cost and schedule impact. The customer approves it through a change request, and the plan is updated. The feature is identical to an unrequested extra, but this time it is approved scope, not gold plating.

Is gold plating ever acceptable?

No. By definition, gold plating is unapproved work, so it is never the right way to add value. Exceeding the customer's expectations is acceptable, and even encouraged, but only when the extra value goes through the same decision that approves any other scope.

This is where PMI's definition helps. The PMBOK® Guide asks project teams to meet or exceed the intended value, through a value-driven decision-making process. A good idea from the team is welcome. The project manager's job is to turn that idea into a decision. That means presenting it to the customer or product owner, showing its cost and impact, and letting them choose. If they approve it, the idea becomes part of the scope and stops being gold plating. If they decline, the team has avoided spending money on something the customer did not value.

In other words, delighting the customer and gold plating can produce the same feature. The difference is that one was chosen by the customer and the other was chosen for them.

How to prevent gold plating

Gold plating is prevented by making the scope clear, making "done" measurable, and giving good ideas an approved path. A team that knows exactly what is required, and knows how to propose more, has little reason to add extras on its own.

1. Define the scope and acceptance criteria clearly. A precise project scope statement and measurable acceptance criteria tell the team where the work ends.
2. Use a definition of done in agile projects. A shared definition of done, together with clear acceptance criteria on each user story, removes the guesswork that leads to extras.
3. Trace work back to requirements. A requirements traceability matrix read backward shows any deliverable that traces to no approved requirement.
4. Give ideas a channel. Make it easy for team members to propose improvements to the project manager or product owner, so ideas are captured instead of quietly built.
5. Redirect spare capacity. When a task finishes early, move the time to the next approved work item rather than to polishing the finished one.
6. Talk about it openly. Explain to the team why gold plating hurts the project, even when it is well-intentioned. Most team members stop once they see the cost.

What to do when you discover gold plating

When gold plating is discovered, the project manager should not hide it and should not simply remove it on their own authority. The extra is now part of the deliverable, so its fate is a scope decision.

The appropriate response is to assess the impact of keeping or removing the extra, disclose it to the customer, and route the decision through change control. Removing it may itself carry cost and risk, and keeping it may need testing, documentation, and support. Our requirements traceability matrix guide walks through this exact situation, where a backward-traceability review finds an unapproved feature shortly before release. After the decision, look for the cause. A discovered extra is usually a symptom of vague acceptance criteria or a missing channel for ideas, and fixing the cause is what keeps it from happening again.

Gold Plating on the PMP® and CAPM® Exams

In the PMP exam, gold plating appears in scenarios, never as a definition question. A typical scenario describes a team member who added something the customer did not request, a customer who has not noticed yet, or a sponsor who likes the extra. If a question asks what the project manager should do next, the correct answer usually assesses the impact and involves the customer through change control. Hiding the extra, removing it on the spot, or simply accepting it are the common distractors.

Note that in the exam, some questions ask how to prevent gold plating rather than how to respond to it. In those questions, look for the root cause in the scenario. If the team is guessing because requirements are vague, the best answer fixes the requirements, not the team. Our best-selling PMP Complete Study Guide, the most complete study guide on the market, covers scope control and these distinctions the way the exam tests them.

The CAPM® exam tests gold plating in the same situational way, with shorter and more contained scenarios. A CAPM question may ask you to recognize gold plating in a scenario, separate it from scope creep, or identify the right next step. Candidates starting from scratch can learn scope management step by step in our CAPM Certification Training.

PMP Practice Question: Gold Plating

An agile team is midway through a fixed-budget release of a hospital's staff-scheduling application. For the third iteration in a row, the iteration review shows stories delivered with extras that no one requested: animated charts, additional export formats, and a dark mode. Several must-have stories planned for the release are now two iterations behind. When asked, the developers explain that the acceptance criteria on the user stories are usually a single line, so they build what a user would obviously want. The product owner has thanked the team for the extras at each review.

What should the project manager do to prevent this from continuing?

a) Raise a change request to add the delivered extras to the release scope baseline and re-plan the remaining iterations around them.

b) Work with the product owner to write explicit acceptance criteria for upcoming stories during backlog refinement, and agree that any idea beyond them goes to the product owner as a new backlog item.

c) Hold a workshop with the hospital's stakeholders to re-elicit the requirements for the rest of the release, since the team's extras show the original requirements were incomplete.

d) Let the team continue adding extras, since the product owner values them, but cap the extra work at a fixed share of each iteration.

Correct answer: B.

Rationale: The question asks how to prevent the problem, so the answer must remove its cause. The cause is stated once, in the developers' explanation: the acceptance criteria are a single line, so the team fills the gaps with its own ideas. Option b) fixes exactly that. Clear acceptance criteria tell the team where each story ends, and the product owner gets a channel for new ideas, where they can be prioritized against the must-haves that are slipping. Option a) is the reflex answer to unapproved work, borrowed from the situation where an extra is discovered before release. It would formalize the extras already built, but it does nothing to stop the next iteration from producing more. Option c) borrows the remedy for conflicting or missing requirements. Here the requirements are not wrong or contradictory, they are underspecified, and a full re-elicitation workshop would cost time the slipping must-haves do not have. Option d) is tempting because the product owner seems pleased. However, thanks at a review are not a prioritization decision, and the extras are already pushing must-haves two iterations behind. Budgeting for gold plating still spends the release on work no one prioritized. PMI's way is to find the root cause and fix it at the source. For full-length, realistic, scenario-based practice with detailed explanations, built to train the PMI® mindset, take our PMP practice exams or, at the entry level, our CAPM practice exams.

Ready to take the next step in project management?

200,000+ Professionals Taught by Our Instructors

PMP® Certification Training

PMP Training →

CAPM® Certification Training

CAPM Training →

Learn Project Management

PM Course →

Frequently asked questions