Recognition and Rewards

Resource technique · See it on the map

Runnable here

Formally acknowledging and rewarding behavior the project needs more of — explicitly tied to what actually helped the project, not handed out generically for morale.

When to use it

Use it when you can name the specific behavior you're reinforcing and it's one you genuinely want repeated: a person who flagged a risk early, a pair who fixed a shared bottleneck together, a team that hit a hard deadline through real collaboration.

When to avoid it

Be careful what you're actually rewarding, because you will get more of it. An individual award for work that needed collaboration teaches people to protect credit instead of sharing it. Rewarding a hero who saved a deadline with a weekend of unplanned overtime teaches the team that heroics are the expected response to bad planning, rather than fixing the planning that made the heroics necessary in the first place. If you find yourself about to reward the fix, ask first whether the problem it fixed should have been prevented.

Steps

1. Name the specific behavior before deciding on the reward — "good work this quarter" reinforces nothing in particular and teaches nothing repeatable.
2. Check whether the behavior was actually collaborative or individual, and match the reward's shape to it: a team outcome gets a team recognition, not a single name on it.
3. Ask whether the situation being rewarded should have been preventable — if a hero saved a deadline that a better plan would have made unnecessary, fix the plan and recognize the effort quietly rather than celebrating the rescue publicly.
4. Deliver the recognition close to the event, not batched into an end-of-project ceremony where the specific behavior has been forgotten by everyone including the person who did it.

What it produces

• A specific behavior publicly reinforced, with the team able to see what earned it

Common pitfalls

• Rewarding the visible fix and never asking why the problem existed, which reliably produces more visible fixes and no fewer underlying problems.
• Giving individual recognition for work that was actually a team effort, which teaches the team to compete for credit on the next collaborative task instead of sharing it.
• Rewarding hours worked (staying late, working weekends) rather than outcomes, which reinforces overwork as the default response to a schedule problem instead of raising the schedule problem itself.

Worked example

A regional insurance broker's claims-system migration project nearly misses a regulatory deadline because two analysts spot a data-mapping error the week before go-live and work through the weekend to fix it. The PM recognizes their effort directly with the pair, but does not make the weekend rescue the project's headline story — instead the postmortem asks why the mapping error wasn't caught in the review three weeks earlier, and the review step's checklist is fixed for the next phase.

Source

• PMBOK-6 §9.4.2.5

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.