Full theory with code examples
Stakeholder mapping technique
Power/Interest grid: High power + high interest = manage closely. High power + low interest = keep satisfied.
Low power + high interest = keep informed. Low power + low interest = monitor only.
For each key stakeholder: document their success criteria, concerns, preferred communication channel.
Review stakeholder map monthly. Influence and interest change as project evolves.
In interviews: show you think systematically about stakeholder management, not just 'I talked to everyone'.
Stakeholder map exampleconst stakeholderMap = {
highPowerHighInterest: [
{ name: "Client Product Owner", concerns: ["Timeline", "Feature completeness"],
communication: "Weekly call + written status", successMetric: "On-time delivery with core features" },
{ name: "Internal Sponsor", concerns: ["Budget", "Resource utilization"],
communication: "Bi-weekly email + monthly review", successMetric: "Within budget, team stable" }
],
highPowerLowInterest: [
{ name: "Legal", concerns: ["Compliance"],
communication: "As needed + milestone review", successMetric: "No compliance issues" }
],
lowPowerHighInterest: [
{ name: "End users (beta group)", concerns: ["Usability", "Performance"],
communication: "Release notes + feedback form", successMetric: "Positive feedback" }
]
};
Status update best practices
Status structure: Progress summary → Upcoming milestones → Risks/blockers → Decisions needed.
RAG status (Red/Amber/Green): Red = off track, needs intervention. Amber = at risk. Green = on track.
Be honest. If it's red, say it's red with recovery plan. Hidden problems explode later.
Executives want: 3-sentence summary, decision needed Y/N, help needed Y/N.
Consistency: same format every week. Stakeholders learn to scan quickly for changes.
Weekly status templateconst weeklyStatus = {
project: "E-commerce Platform v2",
period: "Week 12",
overallStatus: "AMBER",
summary: "Development on track. Integration testing delayed due to vendor API issues.",
progress: {
done: ["User authentication", "Product catalog", "Cart functionality"],
inProgress: ["Payment integration (blocked)", "Order management"],
upcoming: ["Shipping integration", "Admin panel"]
},
risks: [
{ risk: "Vendor API delay", impact: "Release may slip 5 days", mitigation: "Building fallback, escalated to vendor" }
],
blockers: [
{ blocker: "Waiting for PCI compliance approval", owner: "Legal", eta: "Friday" }
],
decisionsNeeded: [
{ decision: "Approve scope cut for v1: defer admin analytics", deadline: "Wednesday", owner: "Product Owner" }
],
nextWeekFocus: "Complete payment integration, start shipping module"
};
Escalation framework
Escalation triggers: deadline at risk >1 week, budget overrun >10%, unresolvable stakeholder conflict, legal/compliance issue.
Structure: What happened → Why it matters (impact) → Options considered → Your recommendation → Decision deadline.
Timing: escalate early. 'I'm escalating because we have time to fix this' > 'I'm escalating because we're already late'.
Never surprise your boss. If you're escalating to their boss, tell them first.
Follow up: after decision, communicate outcome to all affected parties.
Escalation email templateconst escalationEmail = {
to: "VP Engineering",
cc: ["PM Manager", "Tech Lead"],
subject: "[Escalation] Payment Integration - Decision Needed by Friday",
body: {
situation: "Vendor (PaymentCo) delayed API delivery by 2 weeks. Our release date is June 1.",
impact: "Without decision by Friday, we will miss June 1 deadline, affecting Q2 revenue targets.",
optionsAnalyzed: [
{ option: "Wait for vendor", pros: "No additional cost", cons: "Miss deadline by 2 weeks", risk: "High" },
{ option: "Build fallback in-house", pros: "Meet deadline", cons: "$12K cost, team overtime", risk: "Medium" },
{ option: "Cut payment from v1", pros: "Meet deadline, no cost", cons: "Core feature missing", risk: "High (business)" }
],
recommendation: "Option 2: Build fallback. Cost is lower than revenue risk of delay.",
decisionNeeded: "Approve Option 2 by Friday EOD to start implementation Monday.",
attachments: ["cost_analysis.pdf", "timeline_comparison.pdf"]
}
};
Conflict resolution for PMs
Most conflicts stem from: unclear priorities, resource competition, miscommunication, different success metrics.
Step 1: Understand each position. What do they really want? What's their underlying concern?
Step 2: Find shared goal. Both want project success — they disagree on path.
Step 3: Propose compromise with explicit criteria. 'Let's prioritize by revenue impact'.
Step 4: Document decision. Prevent same argument recurring. If compromise impossible, escalate with both positions.
Conflict resolution exampleconst conflictResolution = {
conflict: "Sales wants Feature A for Q2 client. Engineering wants to pay down tech debt first.",
positions: {
sales: { want: "Feature A by June 1", underlying: "$500K deal depends on it" },
engineering: { want: "2 sprints for tech debt", underlying: "Current debt slows all future work by 30%" }
},
sharedGoal: "Maximize Q2 delivery capacity and revenue",
analysisApproach: "Calculate: revenue from Feature A vs. velocity gain from tech debt",
compromise: {
proposal: "1 sprint tech debt (critical items only), then Feature A, then remaining tech debt",
criteria: "Prioritize tech debt items by velocity impact. Feature A simplified to MVP.",
outcome: "Both get core needs met. Feature A ships June 8 (1 week slip), velocity improves 15%"
},
documentation: "Decision logged in project wiki with owners and rationale"
};
Managing stakeholder expectations
Set expectations early. Better to under-promise and over-deliver than reverse.
When scope/timeline changes: communicate immediately with impact and options.
Regular cadence builds trust. Stakeholders trust you more when they hear from you consistently.
Bad news delivered early is manageable. Bad news delivered late is a crisis.
Use explicit language. 'We will try' is not commitment. 'We will deliver X by Y' is commitment.
Expectation setting exampleconst expectationManagement = {
scenario: "Client asks: 'Can you add feature X to the sprint?'",
badResponse: "We'll try to fit it in.",
goodResponse: {
acknowledge: "I understand Feature X is important for your Q2 launch.",
assess: "Let me check impact with the team and get back to you by EOD.",
followUp: {
option1: "Yes, we can add X if we move Y to next sprint. Y would then ship June 15 instead of June 1.",
option2: "We can deliver X MVP (core functionality only) this sprint, full X next sprint.",
option3: "Adding X without cutting scope would push release by 1 week to June 8.",
askForDecision: "Which option works best for your timeline?"
}
},
principle: "Never commit without understanding impact. Always give options."
};