Client Management

1. Stakeholder Influence/Interest Matrix

2. RACI Matrix

3. Executive Presentation Structure

4. Difficult Conversation Framework

flowchart TD
    A[Separate facts, interpretation, and impact] --> S{Safe and appropriate for direct discussion?}
    S -->|No| X[Pause and use approved HR, legal, compliance, or safety route]
    S -->|Yes| B[Listen for context and emotion]
    B --> C[Share perspective and test interpretation]
    C --> D[Explore options]
    D --> E{Clear agreement}
    E -->|Yes| F[Document commitments]
    F --> G[Follow up]
    E -->|No| H{Pause, continue, or escalate?}
    H -->|Continue| B
    H -->|Pause or escalate| X

5. Project Scoping Template

6. Statement of Work (SOW) Components

7. Risk Register & Mitigation

8. Change Request Process

flowchart TD
    A[Record request and authority] --> B{Already required by controlled scope or contract?}
    B -->|Yes| C[Assess priority, capacity, dependency, and acceptance]
    B -->|No| D[Assess value, cost, schedule, quality, risk, legal, data, and stakeholder impacts]
    C --> E{Authorized decision}
    D --> E
    E -->|Approve or exchange priority| F[Update contract or SOW, scope, budget, schedule, roles, baselines, risks, and communications]
    E -->|Defer| H[Record trigger, owner, and revisit date]
    E -->|Reject| I[Record rationale and notify affected parties]
    F --> J[Implement, validate, and monitor]

9. Feedback Collection Methods

10. Relationship Mapping Tool

Why This Matters: Mental Models & Client Wisdom

Client management is where technical excellence meets human dynamics. Understanding why stakeholder frameworks work—and why they fail—is critical for preventing project derailment. This section explores the psychology of stakeholder engagement, examines relationship failures, and compares competing philosophies.

Mental Models: Why Client Management Frameworks Work

1. What RACI can and cannot clarify

RACI can expose an unnamed work owner, missing consultation, or poor communication. It does not prove that multiple accountabilities cause diffusion, and the social-psychology bystander effect should not be transferred into an organizational law without evidence.

The coordination principle: Name who coordinates the work and decision, then record every governing authority, required approval, contributor, affected party, and recipient. The emergency contact may be different from the legal or final decision authority.

Authority vs. Responsibility: RACI distinguishes doing the work (R) from owning the outcome (A). This matters because the person doing the work often isn't empowered to make decisions. Separating R and A surfaces this gap early.

Example: A product launch has unclear ownership:

• Product team thinks Marketing is accountable (they're doing the campaign)
• Marketing thinks Product is accountable (it's their product)
• Result: No one books the launch venue, reserves PR, or coordinates timing

RACI prompts the team to verify who coordinates the launch and who actually holds each approval. Clarity can reduce avoidable handoff confusion, but execution still depends on evidence, capability, incentives, and controls.

Why It Works: It prompts explicit work, decision, approval, and communication roles. If authority is unclear, verify the governing process before execution rather than assuming a RACI label creates it.

Why It Fails: When the matrix conflicts with actual law, governance, contract, delegated authority, or a genuinely collective decision. A single “A” can clarify some tasks, but committees, boards, dual controls, and multiple required approvals can be legitimate. Document the real decision rule instead of forcing false singularity.

2. Why Stakeholder Mapping Works: Influence and Interest Dynamics

Stakeholder mapping is a provisional attention aid, not a ranking of human worth or rights. Power and interest do not capture legitimacy, expertise, dependency, representation, legal rights, public interest, or potential harm.

Power Asymmetry: Formal authority and informal influence can be unevenly distributed. A finance officer may hold budget authority while frontline staff hold operational evidence, safety knowledge, protected rights, or implementation dependence. Engagement should follow the decision, rights, evidence, and harm—not power alone.

Interest Levels: Engagement is effortful, but interest does not reliably predict reading behavior or information need. Tailor format and cadence through accessibility, role, decision need, legal notice, risk, preference, and feedback rather than assuming a quadrant determines attention.

Quadrant Logic:

• High Power, High Interest: verify authority, conflicts, information needs, and decision role; close engagement may be appropriate.
• High Power, Low Interest: agree a concise cadence and exception path without presuming indifference or withholding required detail.
• Lower Formal Power, High Interest: include relevant expertise, dependency, rights, representation, and harm; “low power” does not mean no veto, remedy, or decision role.
• Lower Formal Power, Lower Expressed Interest: monitor context and provide accessible notice or engagement where rights, impact, safety, or public obligations require it.

Potential value: The map can expose mismatches between decision authority, evidence, impact, and current engagement. It should not be used to dismiss lower-power groups or optimize only sponsor support.

Why It Fails: When labels become fixed or obscure rights, informal influence, harm, and changing context. Update at decision-relevant events rather than relying on a universal quarterly cadence.

3. Why Communication Cadences Work: Expectation Management

Regular communication can improve predictability and coordination, but it does not create psychological safety or guarantee tolerance of uncertainty. Content, credibility, voice, confidentiality, decision rights, prior experience, and the ability to challenge or escalate also matter.

Predictability Reduces Anxiety: A known update window may help some stakeholders plan attention. Others need event-triggered notice, different accessibility, confidentiality, or faster escalation. Test preferences and obligations rather than treating cadence as an anxiety intervention.

Information Hierarchy: Different stakeholders need different levels of detail:

• Executives: "Are we on track? Red/yellow/green status."
• Functional leaders: "What decisions do I need to make this week?"
• Team members: "What blockers exist?"

Communication plans can differentiate content by decision need, but monthly/weekly/daily patterns are constructed examples, not a hierarchy or universal cadence.

Example: A project without cadences:

• Month 1: PM sends 5 emails to CEO
• Month 2: PM sends 0 emails to CEO
• Month 3: CEO asks "what's happening?" (PM assumed "no news is good news")

With cadences:

• Every month: PM sends 1-page summary to CEO on Friday at 3 PM
• CEO knows: "If it's Friday at 3 PM, I'll hear from the PM"

Potential value: A reliable cadence can reduce ad hoc status requests when content, timing, ownership, and exception triggers meet stakeholder needs.

Why It Fails: When cadence becomes ritual, suppresses material event-triggered disclosure, or delivers low-quality information. One missed update does not automatically break trust, and content, candor, accessibility, and recovery can matter more than mechanical consistency.

4. Why Escalation Protocols Work: Rapid Decision-Making

Escalation protocols can clarify triggers, authority, evidence, and response paths; they do not prevent bottlenecks or replace judgment, emergency duties, legal reporting, or direct access to protected channels.

Decision Latency: Decision delay is one project risk among many. Set escalation triggers from consequence, urgency, authority, contract, safety, and legal obligations rather than a universal 48-hour rule.

Escalation Paths: Clear paths prevent "escalation ping-pong": "I escalated to my manager, who escalated to their manager, who said it's not their decision, escalate to Finance." A protocol says: "For budget issues: PM → Sponsor → CFO. For scope issues: PM → Product Owner → Steering Committee."

Example: A vendor misses a deadline. Without escalation protocol:

• PM waits 1 week hoping vendor recovers
• PM mentions it to sponsor in weekly meeting (Week 2)
• Sponsor says "handle it" (not clear if this is direction or abdication)
• PM negotiates with vendor (Week 3-4), gets nowhere
• PM escalates again to sponsor (Week 5), who finally involves legal
• Total delay: 5 weeks

With escalation protocol:

• "If vendor misses deadline, escalate within 24 hours to Sponsor"
• "Sponsor decides within 48 hours: Accept delay, replace vendor, or invoke penalties"
• Delay: 3 days

Potential value: A well-designed path can reduce avoidable routing delay. Decisions do not happen automatically; the authorized owner still needs adequate evidence, capacity, and accountability.

Why It Fails: When protocols aren't followed. If the PM escalates and the sponsor doesn't respond within the SLA (48 hours), the protocol becomes meaningless. Enforcement requires leadership accountability.

Composite Teaching Scenarios: When Client Management Breaks Down

The following cases are fictional composites created to test governance, scope, and escalation choices. They are not accounts of a named consulting firm or client, and their timing, staffing, budgets, dialogue, and outcomes are illustrative rather than empirical.

Composite Case 1: Unclear Accountability

Situation: A fictional consulting firm begins a six-month strategy engagement with a large client. The constructed scenario uses three consultants, five client stakeholders, and no agreed responsibility map.

What Went Wrong: Month 1: Consultants interviewed stakeholders. Everyone said they were "involved" but no one was "accountable."

Month 3: Consultants delivered interim findings to the VP of Strategy. VP said: "This looks good, but check with the CFO—he controls the budget."

Consultants presented to CFO. CFO said: "Strategy looks fine, but Operations needs to approve—they'll execute it."

Consultants presented to COO. COO said: "I like it, but the CEO needs to sign off."

Month 5: After presenting to 5 stakeholders, still no decision. Consultants asked: "Who approves this?" Answer: "The steering committee" (which met quarterly—next meeting in 2 months).

Month 6: Engagement ended. No decision made. Client didn't renew contract. Consultants blamed "client indecision." Client blamed "consultants didn't understand our process."

What Framework Failed: No RACI. Without a single Accountable stakeholder, every stakeholder had implicit veto power. This created a "consensus trap"—everyone needed to agree, so no one could decide.

What Would Have Worked: RACI established Week 1:

• Accountable: CEO (final decision-maker)
• Responsible: Consultants (do the work)
• Consulted: CFO, COO, VP Strategy (provide input)
• Informed: Steering committee (aware of decision, don't approve)

With RACI, consultants present to consulted stakeholders (gather input), then present to CEO (the one Accountable), who decides. No steering committee delay.

Lesson: Before client work, map who recommends, decides, approves, advises, and receives notice under the actual governance process. A committee or consensus rule can be legitimate; clarify quorum, reserved matters, tie-breaking, delegated authority, escalation, and decision deadlines rather than assuming collective authority will stall.

Composite Case 2: Scope Expansion and Stakeholder Misalignment

Situation: A software implementation project had a signed SOW: "Implement CRM for Sales team, $500K, 6 months." Month 3, the VP of Marketing asked: "Can you also add Marketing automation?" PM said "sure" (trying to be helpful).

What Went Wrong: Month 4: Marketing automation requirements added (scope creep). PM didn't update SOW (assumed it was a "small addition").

Month 5: Development team realized Marketing automation required 3 additional months. PM went to client sponsor (VP Sales): "We need timeline extension."

VP Sales: "Why? SOW says 6 months." PM: "Marketing asked for additional features." VP Sales: "Marketing isn't paying for this. I have a 6-month deadline."

Month 6: PM faced impossible choice:

1. Deliver CRM only (Marketing unhappy, but meets SOW)
2. Deliver CRM + partial Marketing automation (both Sales and Marketing unhappy)
3. Delay (Sales unhappy, blames PM)

PM chose option 2. Sales got a buggy CRM (rushed). Marketing got incomplete automation (not usable). Both stakeholders rated the project "failed."

What Framework Failed: Stakeholder mapping wasn't maintained. VP Marketing was originally Low Power (not sponsor), Low Interest (not in scope). When they showed interest, PM elevated their influence without updating the stakeholder map or escalating to the sponsor (VP Sales).

What Would Have Worked: Change control process:

• Month 4: VP Marketing requests features
• PM: "That's a scope change. Let me evaluate impact." (Runs impact analysis: +$200K, +3 months)
• PM presents to sponsor (VP Sales): "Marketing wants X. Cost: $200K, Timeline: +3 months. Approve as change order or defer to Phase 2?"
• VP Sales decides: "Defer to Phase 2. We need CRM on time."

Marketing's request is documented (they feel heard) but not approved (Sales' priorities preserved).

Lesson: Stakeholder mapping isn't static. When a stakeholder's interest increases (Low → High), trigger change control. Don't accommodate requests without sponsor approval.

Case 3: Executive Decision Stall - Escalation Path Missed

Situation: A digital transformation project required executive approval for $10M cloud infrastructure investment. The PM presented to the CTO, who said: "Looks good. Present to the CIO for IT approval."

What Went Wrong: Week 1: PM presents to CIO. CIO says: "I need Finance to approve the budget." Week 3: PM presents to CFO. CFO says: "I need the business case validated by Strategy." Week 5: PM presents to Chief Strategy Officer. CSO says: "This needs board approval." Week 8: PM requests board meeting slot. Board meets quarterly; next meeting is 6 weeks away. Week 14: Board approves (finally).

Total delay: 14 weeks for a decision that should have taken 1 week.

What Framework Failed: Escalation path wasn't defined. PM didn't know: "Who is the ultimate decision-maker for $10M investments?" PM discovered this through trial and error (presenting to 5 executives before finding the right one).

What Would Have Worked: Escalation protocol defined Week 1 (during project charter):

• Investments <$1M: CTO approval
• Investments $1-10M: CFO approval (requires business case)
• Investments >$10M: Board approval

With this protocol:

• Week 1: PM knows "$10M requires board approval" (not CTO)
• Week 2: PM requests board meeting slot (6 weeks ahead)
• Week 3-7: PM prepares board materials (while waiting for meeting)
• Week 8: Board meeting, decision made

Total time: 8 weeks (vs. 14 weeks). Difference: 6 weeks saved by knowing the path upfront.

Lesson: Define decision authority BEFORE you need a decision. Include in project charter: "Who approves scope changes? Who approves budget increases? What's the threshold for board involvement?"

Competing Schools: Different Philosophies for Client Management

1. Stakeholder-Centric vs. Task-Centric Management

Stakeholder-Centric: Prioritize relationships over tasks. Invest time building trust, understanding motivations, and managing politics.

Philosophy: "Projects succeed through people, not processes."

Strengths:

• High trust = forgiveness when things go wrong
• Political savvy prevents blockers
• Stakeholder buy-in ensures adoption

Weaknesses:

• Time-intensive (1:1s, relationship-building takes hours/week)
• Can sacrifice delivery for relationships ("we're behind schedule, but stakeholders are happy")
• Hard to scale (can't build deep relationships with 50 stakeholders)

When to Use:

• Political environments (government, large enterprises)
• High-visibility projects (board-level scrutiny)
• Change management projects (adoption is THE metric)

Task-Centric: Prioritize execution over relationships. Follow processes (RACI, change control) and let results speak.

Philosophy: "Deliver on time and on budget, stakeholders will be satisfied."

Strengths:

• Efficient (no time wasted on "relationship management")
• Clear accountability (RACI, not politics)
• Scales (processes work with 100 stakeholders)

Weaknesses:

• Low trust = stakeholders don't give benefit of doubt when issues arise
• Misses political dynamics (blockers emerge late)
• Low adoption (stakeholders comply but don't commit)

When to Use:

• Technical projects (engineering, IT, operations)
• Low-stakes projects (operational, not strategic)
• Mature relationships (trust already established)

Hybrid (Best Practice): Invest in relationships with high-power stakeholders (Manage Closely quadrant), use processes for others.

Example:

• Sponsor: Weekly 1:1s (stakeholder-centric)
• Steering committee: Monthly formal meetings (process-centric)
• Project team: Daily standups (process-centric)

2. Formal Governance vs. Relationship-Based Trust

Formal Governance: Use steering committees, change control boards, formal decision logs. Transparency through process.

Philosophy: "Document everything. Governance creates accountability."

Strengths:

• Audit trail (who decided what, when)
• Protects against political shifts (decisions documented, can't be reversed arbitrarily)
• Scales (governance works with rotating stakeholders)

Weaknesses:

• Bureaucracy (decisions take weeks through committees)
• Stifles agility (formal change requests slow iteration)
• Low engagement (stakeholders attend meetings out of obligation, not interest)

When to Use:

• Regulated industries (healthcare, finance, government)
• Large, multi-division organizations with formal governance dependencies
• High-risk projects (failures have legal/financial consequences)

Relationship-Based Trust: Minimal formal governance. Rely on trust, informal communication, and handshake agreements.

Philosophy: "Trust accelerates decisions. Process slows them down."

Strengths:

• Speed (decisions in 1:1s, not committees)
• Flexibility (pivot without formal change requests)
• Engagement (stakeholders feel valued, not managed)

Weaknesses:

• Fragile (if key relationship breaks, project derails)
• No audit trail (decisions can be reversed, "I never agreed to that")
• Doesn't scale (trust requires stable, small group)

When to Use:

• Startups (small, tight teams)
• Stable teams (same stakeholders for years)
• Low-risk projects (experimentation, pilots)

Hybrid (Light Governance with Trust): Use governance for major decisions (scope, budget, timeline) but trust for day-to-day (feature details, priorities).

Example:

• Scope change: Formal change control (steering committee approval)
• Feature prioritization: Informal (PM and Product Owner decide in weekly 1:1)

3. Frequent Communication vs. Minimal Overhead

Frequent Communication: Daily standups, weekly summaries, monthly deep dives. Stakeholders are always informed.

Philosophy: "Transparency builds trust. Communicate often."

Strengths:

• No surprises (stakeholders always know status)
• Quick course correction (issues raised daily, not monthly)
• Engagement (frequent touchpoints build relationships)

Weaknesses:

• Overhead (meaningful PM time spent communicating)
• Fatigue (stakeholders tune out if updates are repetitive)
• Noise (too much communication = stakeholders miss critical updates)

When to Use:

• High-risk projects (need tight monitoring)
• Agile projects (sprint-based, frequent changes)
• Stakeholder anxiety (visible project, executives watching closely)

Lower-Frequency Engagement: Use a lower cadence only when rights, potential harm, decision timing, evidence needs, obligations, accessibility, and escalation paths support it. Silence is not evidence of trust or informed consent.

Strengths:

• Efficiency (limited PM time spent on communication)
• Focus (stakeholders aren't distracted by routine updates)
• Trust (assumes stakeholders don't need hand-holding)

Weaknesses:

• Surprises (stakeholders blindsided by issues)
• Anxiety (stakeholders check in constantly: "Is everything okay?")
• Slow correction (issues discovered late)

When to Use:

• Low-risk projects (routine, proven processes)
• Mature relationships (trust established)
• Autonomous teams (don't need frequent oversight)

Tailored Engagement: Set participation, channel, content, cadence, decision access, accommodation, and escalation for each stakeholder or represented group from rights, legitimacy, harm, impact, expertise, dependency, evidence need, urgency, and applicable obligations. Power/interest quadrants are prompts only: low reported interest does not justify minimal communication, and no weekly, monthly, bi-weekly, or quarterly cadence follows automatically from a quadrant.

Stage Dependency: How Client Management Evolves with Scale

The stage contrasts below are constructed heuristics, not employee thresholds, maturity stages, or governance prescriptions. Choose structure from coordination load, risk, regulation, interfaces, decision rights, uncertainty, accessibility, and affected populations.

Startup: Informal, Relationship-Based Management

Context: This small-team scenario assumes fewer than 20 people, direct communication, and high trust; formal client-management mechanisms may be lighter, but rights, authority, evidence, and affected-party needs still apply.

Approach:

• Stakeholders: 3-5 people (founders, early customers)
• Governance: Informal (daily conversations, no committees)
• Communication: Constant (Slack, shared workspace)
• RACI: Implicit (founders own everything)

Example: A startup with 5 employees launching a product:

• Stakeholder management: Daily standups with whole team
• Decision-making: Founder decides in real-time
• Communication: Slack channel (everyone sees everything)

Why It Works: Small teams = low coordination overhead. Everyone knows everyone, trust is high, formal processes add bureaucracy.

Failure Mode: When startups scale to 50+ people and keep informal processes → chaos (no one knows who decides, decisions bottleneck at founder).

Scale-Up: Emerging Formal Structures

Context: This scale-up scenario assumes 20–200 people, multiple departments, external stakeholders, and increasing coordination complexity; some client-management mechanisms may need to become more explicit.

Approach:

• Stakeholders: 15-30 people (cross-functional leaders, key customers)
• Governance: Emerging (weekly standups + monthly business reviews)
• Communication: Structured (weekly summaries, monthly deep dives)
• RACI: Explicit (documented for key decisions)

Example: A scale-up with $20M revenue managing a product launch:

• Stakeholder mapping: 20 stakeholders (Product, Sales, Marketing, Finance, key customers)
• RACI: Defined for launch decisions (CMO Accountable, Product and Sales Consulted)
• Communication: Weekly email summary to all stakeholders, bi-weekly 1:1s with Manage Closely group
• Governance: Monthly steering committee (CMO, CFO, CRO)

Why It Works: Formal structures prevent chaos while maintaining agility. Stakeholders know who decides (RACI) and when they'll be updated (cadences).

Failure Mode: When scale-ups over-formalize (monthly steering committees become weekly, 5-page memos for every decision) → bureaucracy slows growth.

Enterprise: Formal Governance, Multiple Stakeholders

Context: This enterprise scenario assumes 1,000+ people, dispersed decision-making, and high accountability needs; governance may need more explicit coordination, review, and escalation, but size alone does not determine the design.

Approach:

• Stakeholders: 50-100 people (multiple business units, geographies, functions)
• Governance: Formal (monthly steering committees, quarterly board updates)
• Communication: Tiered (daily team updates, weekly functional leads, monthly executives)
• RACI: Mandatory (documented in project charter, audited)

Example: An enterprise with $5B revenue implementing a global ERP system:

• Stakeholder mapping: 80 stakeholders (BU presidents, regional CIOs, functional VPs, board members)
• RACI: Comprehensive (200+ tasks, each with explicit A)
• Communication:
  • Daily: Team standups (20 people)
  • Weekly: Functional lead syncs (10 people)
  • Monthly: Steering committee (5 executives)
  • Quarterly: Board presentation (CEO, CFO, CIO)
• Governance: Steering committee makes scope/budget decisions, board approves >$10M investments

Why It Works: Formal governance ensures accountability at scale. With 80 stakeholders, informal trust doesn't scale. Processes create clarity.

Failure Mode: When governance becomes theater (committees meet but don't decide, documentation exists but isn't read) → bureaucracy without accountability.

Stage Comparison:

Table 12.9 — Constructed scale-context comparison. Stakeholder counts, cadences, and governance examples are not maturity benchmarks.

Contrarian Thinking: When Client Management Orthodoxy Fails

The contrasts below are constructed teaching hypotheses and practitioner prompts, not a systematic evidence review or prevalence claim. Replace any empirical or causal claim with inspected, adjacent evidence before publication.

1. The Client Is Not Always Right

Conventional Wisdom: "The customer is always right. Give clients what they want."

Contrarian Challenge: Clients often don't know what they need. Your job is to diagnose the real problem, not implement their requested solution.

Constructed consumer-product scenario:

A product team runs a blind preference test for a reformulated product and interprets the result as approval to replace the incumbent brand. The test did not measure attachment to the existing product, switching behavior, channel reaction, or response to removing choice. This is a hypothetical illustration of construct validity, not a retelling of the New Coke case.

What the scenario surfaces: The research answered a narrower sensory-preference question than the replacement decision required. The team should define the actual decision, population, alternatives, behavior, uncertainty, and consequences before treating one measure as customer authorization.

Client Management Parallel:

Bad consultant: "You asked for a new CRM system? Here's the RFP for Salesforce."

Better consultant: “You requested a new CRM. Before selecting a solution, let us test the workflow, data, incentives, capability, and system constraints that may contribute to the observed problem.”

Lesson: The professional obligation depends on the engagement and governing duties. The practical principle is to distinguish the requested solution from the evidence-supported problem and to disclose material disagreement.

When to Push Back:

• Client requests a solution before diagnosing the problem
• Client solution won't address root cause (treats symptoms)
• Client request violates best practices or will create future problems

How to Push Back (Without Burning the Relationship):

Framework: "I understand... and I want to make sure we solve the right problem."

Example:

• Client: "We need to build a custom analytics platform from scratch."
• You: "I understand you want better analytics. Before we commit to a 12-month custom build, let's validate whether off-the-shelf tools (Tableau, Power BI) meet most needs. Custom builds can cost more and take longer. Let's explore both options and compare ROI."

Practitioner note: Treat customer input as evidence about needs, not as a substitute for diagnosis.

2. Over-Communication Can Be as Harmful as Under-Communication

Conventional Wisdom: "Communicate frequently. Stakeholders want constant updates."

Contrarian Challenge: Too many status updates create noise, not signal. Busy executives ignore low-value communications, training them to ignore ALL your communications.

Constructed attention heuristic:

Information Overload Heuristic:

• Busy executives receive far more messages than they can carefully process
• They open relatively few emails from external consultants
• They read even fewer thoroughly
• They act on only the clearest asks

Result: Low-value communications may be ignored; test attention, comprehension, decision response, and accessibility rather than assuming a universal rate.

Root Cause: Low signal-to-noise ratio. If you send daily status emails with trivial updates ("completed task X, Y, Z"), executives tune out. When you send a CRITICAL update (major risk, decision needed), they've already developed the habit of ignoring your emails.

Client Management Anti-Pattern:

Bad practice:

• Daily email: "Today we completed requirements gathering session #3."
• Daily email: "Today we completed requirements gathering session #4."
• Daily email: "URGENT: Project timeline slipping 2 months due to scope change."

Result: Executive ignores all three emails (trained to ignore daily noise). Misses the urgent message. Surprised at board meeting when timeline slip is revealed.

Good practice:

• Week 1: No email (work in progress, nothing to escalate)
• Week 2: No email (work in progress)
• Week 3: Email: "Decision needed: Scope expanded materially, which delays timeline 2 months OR we descope features X, Y, Z to maintain timeline. Need your decision by Friday."

Result: Executive opens email (rare communication = high importance). Makes decision. Project stays on track.

Lesson: Communicate strategically, not frequently. Reserve communications for:

1. Decisions needed: Executive must choose between options
2. Risks escalated: Issue beyond your authority to resolve
3. Milestones hit: Major progress worth celebrating
4. Status changed: Red → Yellow or Yellow → Red

Don't communicate:

• Routine progress (save for weekly summaries)
• FYI information (no action required)
• Internal team matters (they don't care about your internal staffing)

Communication Frequency by Stakeholder Tier:

Practitioner note: Treat executive attention as scarce and design messages for clear action.

3. Stakeholder Alignment Is Often Impossible (And That's OK)

Conventional Wisdom: "Get all stakeholders aligned before proceeding. Consensus is critical."

Contrarian Challenge: Perfect alignment is a myth. Stakeholders have conflicting incentives. Your job is to manage conflicts, not eliminate them.

Constructed alignment scenario, not prevalence evidence:

Enterprise software scenario:

• A complex project may miss time, budget, or scope expectations when assumptions, dependencies, authority, or evidence are weak.
• Stakeholder conflict and analysis paralysis are possible mechanisms to investigate, not universal causes or prevalence claims.

Paradox: Trying to eliminate stakeholder conflict creates analysis paralysis, which also causes failure.

Client Management Reality:

Conflicting Stakeholder Incentives:

These incentives conflict. You cannot satisfy all four simultaneously.

Bad approach: Try to get all four to agree. Spend 6 months in meetings. Make no progress. Project dies from inaction.

Good approach: Escalate to decision-maker (CEO). Present trade-offs. Get CEO to prioritize. Accept that 3 stakeholders will be partially unhappy.

Decision Framework (for CEO):

"We have four stakeholder groups with conflicting priorities:

• CFO wants lowest cost: $500K solution (basic features)
• CTO wants best tech: $2M solution (cutting-edge)
• COO wants stability: 18-month implementation (no disruption)
• CMO wants speed: 6-month implementation (fast to market)

Recommendation: $1.2M solution, 12-month implementation (balanced trade-off)

• CFO: 2.4x budget (vs. ideal $500K) → Partially unhappy
• CTO: Mid-tier tech (not cutting-edge) → Partially unhappy
• COO: 12 months (not 18) → Manageable, some risk
• CMO: 12 months (not 6) → Partially unhappy

ALL stakeholders compromise. But project proceeds."

Lesson: Don't aim for perfect alignment. Aim for "good enough" alignment where the CEO makes a decision and stakeholders accept it (even if they disagree).

Red Flag: If stakeholders appear fully aligned without debate, you probably haven't dug deep enough. Surface-level agreement often hides underlying conflicts that will emerge mid-project.

Practitioner note: Treat stakeholder alignment as an active risk area, not a one-time kickoff artifact.

4. Client Satisfaction ≠ Project Success

Conventional Wisdom: "If the client is happy, the project succeeded."

Contrarian Challenge: Clients can be very satisfied with projects that fail to deliver business value. Satisfaction is a lagging indicator measured too early.

Constructed outcome-measure scenario:

Consulting impact pattern:

• A consulting project can receive positive feedback at completion while its later business value remains uncertain.
• Outcome evidence may be harder to obtain after delivery; define ownership, timing, attribution, and measurement before treating a satisfaction signal as impact.

Why the Gap?

Satisfaction is measured at delivery (Month 6), not at impact (Month 18).

Example:

Project: Digital transformation (new e-commerce platform) Month 6 (Project End):

• Delivered on time, on budget
• Platform looks great, modern UI
• Client satisfaction score: 9/10 ("Excellent work!")
• Consultant celebrates, moves to next client

Month 18 (12 months post-launch):

• E-commerce revenue: +5 percent (below 20 percent target)
• Conversion rate: Flat (no improvement)
• Customer complaints: Up 30 percent (platform harder to use than old one)

Root cause: Platform was beautifully designed but didn't address real customer pain points (checkout friction, mobile experience). Consultant optimized for client satisfaction (impressive demos), not customer outcomes (revenue).

Lesson: Measure success by business outcomes, not client satisfaction. Satisfaction is necessary but not sufficient.

Success Metrics Hierarchy:

1. Tier 1 (Outcomes): Revenue, profit, cost savings, customer retention
2. Tier 2 (Outputs): Features delivered, systems deployed, processes redesigned
3. Tier 3 (Satisfaction): Client feedback scores, relationship strength

Constructed heuristic: Teams may overemphasize Tier 3 because it is available at closeout; pair satisfaction with outcome, output, risk, adoption, and attribution evidence rather than ranking projects by one tier.

How to Align on Outcomes:

At project kickoff, define success metrics:

• Bad: "Deliver CRM system" (output)
• Good: "Increase sales productivity 20 percent (measured by revenue per rep)" (outcome)

Track metrics throughout:

• Month 3: Early indicators (CRM adoption rate)
• Month 6: Intermediate indicators (pipeline growth)
• Month 12: Outcome indicators (revenue per rep)

Client Management Implication:

Sometimes you need to make clients UNHAPPY in the short term to drive long-term outcomes.

Example:

• Client wants to skip user training (speeds up launch)
• You insist on training (delays launch 1 month)
• Client frustrated (satisfaction drops)
• 6 months later: High user adoption relative to the target -> Outcomes achieved

Practitioner note: Validate consulting impact against business outcomes, not only closeout sentiment.

5. Re-scope, suspend, or exit an engagement through governance

Conventional Wisdom: "The client pays your salary. Never fire a client."

Decision challenge: A relationship can become economically, ethically, operationally, or professionally untenable. Re-scope, suspend, non-renew, or terminate only through the applicable contract, authority, professional duties, transition obligations, and legal review.

Evidence:

Maister's professional-services work frames management as balancing client service, professional careers, and firm economics; it does not establish a universal client-exit rate or prove that exiting a client will improve morale or profit. ^[6]

Economics of a Bad Client:

Good Client:

• Revenue: $500K
• Delivery cost: $300K (team time)
• Profit: $200K (40 percent margin)
• Team satisfaction: High (normal hours, clear scope)

Bad Client:

• Revenue: $500K (same)
• Delivery cost: $600K (scope creep, endless revisions, weekend work)
• Profit: -$100K (negative margin!)
• Team satisfaction: Low → 2 team members quit → $200K replacement cost

Total cost of bad client: -$300K ($100K loss + $200K turnover)

Issues requiring review rather than a numeric firing rule:

1. Scope creep: Every request expands beyond SOW, refuses change orders
2. Payment issues: Delinquency, disputed invoices, insolvency risk, or collection concerns under the actual contract and law
3. Abusive behavior: Yells at team, unreasonable demands (weekend calls, 24-hour turnarounds)
4. Misaligned values: Asks you to do unethical work (hide data, mislead stakeholders)
5. Unrealistic expectations: Expects 10x results with 1x budget, blames you for external factors
6. Project failure risk: High likelihood of project failure (bad data, no sponsorship) → Damages your reputation

How to govern a possible exit:

Step 1: Attempt to salvage (if possible)

• Have difficult conversation: "Our engagement isn't working. Here's why: [scope creep, payment issues]. Here's what needs to change: [clear boundaries, payment terms]. Can we agree?"
• If client agrees and changes behavior → Continue
• If client refuses or reverts → Proceed to Step 2

Step 2: Execute an authorized exit if selected

• Counsel and accountable leaders determine notice, cure, suspension, non-renewal or termination rights, fees, work completion, transition, data and records, confidentiality, privilege, publicity, and survival obligations.
• Communicate accurately and preserve the decision record; do not use a generic letter as a legal script.

Step 3: Learn and filter

• Post-mortem: What red flags did we miss in sales process?
• Update client screening: Add criteria to filter future bad clients

Example:

Situation: Client consistently scope creeps, refuses change orders, and demands weekend work.

Consultant response: "We value our partnership, but our engagement has expanded significantly beyond the original SOW. We've delivered $800K of work for $500K of revenue. Going forward, we need to operate within the SOW or execute change orders for additional requests. Are you able to commit to this?"

Client response (bad): "You're being inflexible. We're a high-value client. Just do the work."

Possible decision: The authorized firm representatives may re-scope, suspend, non-renew, or terminate under the governing agreement after legal and financial review. The sample facts do not determine which remedy is available.

Alternative client response (good): "You're right. Let's set clear boundaries. I'll approve change orders for out-of-scope work."

Consultant decision: Continue the engagement (with new boundaries).

Lesson: Revenue quality, delivery cost, independence, team welfare, client harm, transition duties, and capacity all matter. Exiting can free capacity, but it can also create loss, liability, or harm; model both sides.

Practitioner note: Maister's professional-services work supports treating client selection as a strategic management decision, not only a sales decision.

Input/Output Interlinkages: How Client Management Connects to Other Business Functions

Purpose: Show how client management inputs come from (and outputs feed into) other business domains.

Client Management as a System

INPUTS (From Other Functions) → CLIENT MANAGEMENT → OUTPUTS (To Other Functions)

Inputs:
- Sales: Client expectations, contract terms, pricing
- Delivery: Project status, risks, technical constraints
- Finance: Budget, payment terms, invoicing
- Legal: SOW terms, liability, IP ownership
- HR: Team availability, skills, capacity
- Marketing: Brand promises, case studies, referrals

Outputs:
- Sales: Upsell opportunities, renewal likelihood, referrals
- Delivery: Prioritized requirements, stakeholder decisions, scope changes
- Finance: Change orders, payment approvals, budget adjustments
- Legal: Contract amendments, dispute resolution
- HR: Resource requests, team feedback, retention issues
- Marketing: Success stories, testimonials, case studies

Example: Enterprise Software Implementation

Inputs Required:

Client Management Activities:

1. Align stakeholders on scope (manage expectations from Sales)
2. Negotiate timeline (balance delivery capacity with client expectations)
3. Manage scope changes (client requests materially more features mid-project)
4. Escalate payment delays (client delayed payment milestone 2)
5. Request more resources (project needs 60 percent allocation, not 40 percent)

Outputs Delivered:

Interconnections:

• Sales → Client Management: Client expectations set during sales process
• Client Management → Delivery: Stakeholder decisions enable delivery progress
• Delivery → Client Management: Technical constraints require stakeholder trade-offs (time vs. features)
• Client Management → Finance: Scope changes generate change orders
• Finance → Client Management: Budget constraints limit scope expansion
• Client Management → HR: Client satisfaction drives team morale (happy client = happy team)

Example: Management Consulting Engagement

Inputs Required:

Client Management Activities:

1. Refine problem statement: Interviews with 15 stakeholders
2. Align on hypotheses: Why is revenue declining? (5 hypotheses)
3. Prioritize analysis: Focus on top 2 hypotheses (time constraint)
4. Manage interim findings: Present findings Week 4 (early feedback)
5. Navigate politics: CFO wants cost cuts, CMO wants growth investment (conflicting)

Outputs Delivered:

Interconnections:

• Sales → Client Management: Sales sold strategy work; client wanted implementation too (upsell)
• Client Management → Delivery: Stakeholder prioritization focused analysis (avoided boiling the ocean)
• Delivery → Client Management: Findings created stakeholder conflict (CFO vs. CMO) requiring mediation
• Client Management -> Marketing: Successful project generates proof points and referrals

Cross-Functional Client Management Challenges

Challenge 1: Sales Over-Promised, Delivery Must Under-Deliver

Situation: Sales sold "30 percent cost reduction in 6 months" to close deal. Delivery team estimates 15 percent reduction in 12 months (realistic).

Client Management Problem: Client expects 30 percent in 6 months (per sales). You must reset expectations.

Solution:

1. Acknowledge sales promise: "I understand the proposal mentioned 30 percent cost reduction."
2. Present reality: "Our detailed analysis shows 15 percent is achievable in 12 months. Here's why 30 percent in 6 months isn't feasible: [data, constraints]."
3. Offer options:
   • Option A: Deliver 15 percent in 12 months (realistic)
   • Option B: Pursue 30 percent, but high risk of failure (unrealistic)
4. Escalate to decision-maker: Client CFO decides: "Let's go with Option A. I'd rather get 15 percent than miss 30 percent."

Lesson: Client management bridges Sales (promises) and Delivery (reality). Your job: Reset expectations without blame.

Challenge 2: Client Requests Unethical Work

Situation: Client asks you to "massage the data" to show positive results in board presentation (actual results are negative).

Client Management Problem: Client is your revenue source, but request violates ethics.

Solution:

1. Clarify request: "Just to confirm: You're asking me to present data in a way that hides the negative results?"
2. State boundary: "I can't do that. It violates our professional standards and misrepresents reality."
3. Offer alternative: "I can present the data accurately and help you explain the results to the board (e.g., 'Results fell short, here's why, here's our plan to improve')."
4. Escalate if needed: If client insists, escalate to your firm's leadership or exit the engagement.

Lesson: Some client requests are non-negotiable. Protect your professional integrity even if it means losing revenue.

Challenge 3: Client Delays Payment, Delivery Continues Work

Situation: Client is 90 days overdue on $200K invoice. Delivery team continues work (doesn't want to stop mid-project).

Client Management Problem: Delivery is exposed to financial risk. Finance wants to halt work.

Solution:

1. Align with Finance: Confirm payment policy (e.g., "No work if >90 days overdue")
2. Notify client: "We haven't received payment for Invoice #123 ($200K, 90 days overdue). Per our contract, we must pause work until payment is received."
3. Offer payment plan: "If cash flow is an issue, we can work out a payment plan. But we can't continue work without resolving this."
4. Route the boundary: If payment remains unresolved, follow the governing agreement and approved finance/counsel process for notice, cure, suspension, collection, transition, essential-service, safety, and client-protection consequences. Do not continue or stop work unilaterally.

Lesson: Client management enforces financial boundaries. Delivery's desire to "keep project moving" can't override Finance's need for payment.

Enhanced Troubleshooting: Navigating Difficult Client Situations

Problem: Client Ghosting (No Responses to Emails/Calls)

Symptoms:

• Client stops responding to emails (3+ emails unanswered)
• Client cancels meetings repeatedly
• Client avoids decision-making

Diagnosis:

Root Cause 1: Client is overwhelmed (not ignoring you, just underwater)

Solution:

• Simplify requests: Instead of "Need your feedback on 50-page document," ask "Need decision on 1 question: Option A or B?"
• Reduce meeting frequency: Weekly → Bi-weekly (give them breathing room)
• Async communication: Send video summary (5 min) instead of requesting 1-hour meeting

Root Cause 2: Client lost interest (project no longer a priority)

Test: "I've noticed we've missed the last 3 meetings. Has project priority changed? If so, let's discuss adjusting scope or timeline."

If yes: Rescope project to match new priority level (smaller scope, slower timeline) If no: "Great. Let's reschedule. When works for you?"

Root Cause 3: Client is avoiding bad news (knows project is failing, doesn't want to confront it)

Test: Schedule in-person meeting (harder to ghost than email). Say: "I'd like to discuss project status and address any concerns you have. I know we've hit some roadblocks, and I want to ensure we're aligned on the path forward."

In meeting: Create psychological safety: "It's okay if the project isn't meeting expectations. Let's talk honestly about what's working and what's not, and figure out how to get back on track."

Problem: Client Constantly Changes Requirements (Scope Creep)

Symptoms:

• Every meeting generates new requests
• "Quick asks" pile up (each takes 2-4 hours)
• Project timeline slips because baseline keeps expanding

Diagnosis:

Root Cause 1: Client didn't understand original scope (thought they were buying more than SOW specified)

Solution:

• Review SOW together: "Let's align on what's in scope vs. out of scope. Here's what the SOW says..."
• Visual scope boundary: Create diagram showing In Scope (green), Out of Scope (red), and Gray Area (yellow)
• Agree on change process: "Any new requests go through change request process (we estimate effort, you approve budget)."

Root Cause 2: Client's needs are evolving (original scope was right, but situation changed)

Solution:

• Acknowledge change: "I understand your needs have evolved since we started. That's normal."
• Present options:
  • Option A: Finish original scope, then start Phase 2 for new requests
  • Option B: Pause project, re-scope to include new needs (adds 2 months, $200K)
  • Option C: Descope original items to make room for new requests (stay on timeline/budget)
• Client chooses: Force decision (don't let scope expand without trade-offs)

Root Cause 3: Client doesn't understand cost of changes ("It's just a small tweak")

Solution:

• Quantify impact: "This 'small tweak' requires 40 hours of work ($8K cost), 2-week timeline delay, and creates risk of breaking feature X."
• Change log: Track all "small tweaks" and show cumulative impact: "We've had 15 'small tweaks' totaling 300 hours ($60K) and 2 months delay."
• Escalate: "We're $60K over budget due to scope changes. Should we proceed, or pause to re-scope?"

Problem: Client Rejects Your Recommendations (Even Though Data Supports It)

Symptoms:

• You present analysis with clear recommendation
• Client says "Interesting, but we're going a different direction"
• Client ignores data, makes decision based on gut feel

Diagnosis:

Root Cause 1: Data threatens client's pre-existing beliefs (cognitive dissonance)

Example:

• Client believes: "Our premium pricing is our competitive advantage"
• Your analysis: "Price is 30 percent higher than competitors with no quality difference -> Losing market share"
• Client reaction: Rejects analysis (accepting it means admitting pricing strategy was wrong)

Solution:

• Frame as evolution: "Your premium pricing WAS the right strategy (2015-2020). Market has shifted. Competitors caught up on quality. Time to evolve."
• Provide exit ramp: "Let's test: Lower prices 10 percent in one region, measure impact. If it works, scale. If not, revert."

Root Cause 2: Recommendation conflicts with client's incentives (political issue)

Example:

• Your recommendation: "Shut down Division X (unprofitable, no turnaround path)"
• Client (VP of Division X): Rejects recommendation (shutting down = loses job)

Solution:

• Escalate above the conflicted stakeholder: Present recommendation to CEO (who has authority to shut down division)
• Offer alternative with face-saving: "Merge Division X into Division Y (preserves team, eliminates standalone losses)"

Root Cause 3: Client wants different outcome (hired you for validation, not truth)

Example:

• Client wanted you to prove: "Our product is the best in market"
• Your finding: "Your product is mid-tier (ranked #5 of 10)"
• Client rejects finding (not what they wanted to hear)

Solution:

• Reset expectations: "My job is to provide accurate analysis, even if it's not what you hoped. Here's what the data shows: [evidence]. How would you like to proceed?"
• Escalate if needed: If client asks you to change findings to match their desired narrative, refuse (ethical boundary)

Problem: Project Stuck in Analysis Paralysis (Client Won't Make Decisions)

Symptoms:

• Every decision requires "more analysis"
• Meetings produce action items like "Let's analyze this further"
• Timeline slips, but no progress on deliverables

Diagnosis:

Root Cause 1: Client lacks decision-making authority (needs boss approval, doesn't want to ask)

Solution:

• Identify true decision-maker: "Who has authority to approve this? Let's include them in the next meeting."
• Escalate: Schedule meeting with CEO/CFO (whoever has authority)

Root Cause 2: Client is risk-averse (afraid of making wrong decision)

Solution:

• Reduce decision stakes: Instead of "Should we invest $5M in new product?", ask "Should we invest $50K in 3-month pilot?"
• Reversible decisions: "This decision is reversible. If we launch and it doesn't work, we can shut it down in 6 months."
• Structured decision: Present 2-3 options with pros/cons. Make it easy to choose.

Root Cause 3: Client is avoiding decision because all options are bad (no-win scenario)

Solution:

• Acknowledge difficulty: "I know this is a tough decision. All options have downsides."
• Reframe: "The question isn't 'Which option is perfect?' It's 'Which imperfect option is least bad?'"
• Set deadline: "We need a decision by Friday. If we don't decide, the default is [Option X]. Is that acceptable?"

Summary: Client Management Toolkit

Table 12.5 — Constructed framework-selection aid. Time, cadence, and use examples depend on the decision, evidence, authority, and context; they are not benchmarks.

How To Get Started: Managing Your Client Relationship

Constructed-methodology boundary: The rapid and detailed setup examples below are fictional teaching scenarios. Hours, days, stakeholder counts, meeting durations, cadences, scores, thresholds, dates, and outputs are not defaults; replace each with a named owner, rationale, authority, evidence source, accessibility/privacy condition, tolerance, and review rule.

Client and stakeholder management can materially affect access, decision quality, adoption, and implementation, but it does not outrank technical delivery in every engagement. Trust and voice can help; success still depends on evidence, competence, ethics, authority, resources, implementation, and context.

Quick Version: Rapid Stakeholder Setup (2-3 days)

For immediate application when starting any client engagement:

Day 1: Stakeholder Identification & Mapping (2-3 hours)

1. List all stakeholders (30 min)

   • Who is directly involved? (client team, project team)
   • Who could affect the project? (finance approvers, executive sponsors, competing projects)
   • Who could be affected? (end users, operations, support)
   • Include the smallest sufficient set supported by influence, impact, rights, expertise, dependency, and representation; there is no universal 15–25-person minimum

2. Map Power/Interest (1 hour)

   • Create 2x2 matrix (Power on x-axis, Interest on y-axis)
   • Plot each stakeholder
   • Use the visualization as a prompt, not a target count; document rights, legitimacy, impact, expertise, dependency, representation, and uncertainty that the two axes omit

3. Develop engagement strategy (1 hour)

   • For every stakeholder or represented group, select participation, decision access, evidence, channel, cadence, accommodation, consent/notice, and escalation from rights, risk, impact, expertise, dependency, urgency, and information need
   • Quadrant labels do not authorize minimal engagement, fixed weekly/monthly/bi-weekly/quarterly cadence, or exclusion from decisions

Output: 1-page stakeholder map with engagement plan

Day 2: RACI & Scoping (2-3 hours)

1. Define major work streams (30 min)

   • 5-8 categories of work (e.g., "Requirements gathering," "Technology selection," "Implementation")
   • List 3-4 tasks per stream

2. Identify key roles (15 min)

   • Client: Client Project Manager, Sponsor, Department heads
   • Consultant: Engagement Manager, Team Lead, Individual contributors
   • Other: Finance, IT, vendor partners

3. Map RACI (1-1.5 hours)

   • Create table: Rows = tasks, Columns = roles
   • Assign R/A/C/I for each task
   • Key rules:
     • Name a coordinating owner or collective decision rule only when the governing model permits it; do not force one accountable person where a board, committee, dual control, statutory, contractual, professional, or shared rule applies.
     • "R" and coordinating accountability may be the same person, but verify actual authority and required approvals.
     • Multiple consulted contributors are fine; multiple approvers may be required when the governing instrument says so.

4. Validate RACI (30 min)

   • Share with 2-3 key people
   • Ask: "Does this reflect how we're working?" or "Am I missing something?"
   • Update based on feedback

Output: RACI matrix (spreadsheet or Confluence page) with stakeholder alignment

Day 3: Project Scope & Risk (2-3 hours)

1. Scope in/out (1 hour)

   • What ARE we delivering? (write 5-7 items)
   • What are we NOT delivering? (write 5-7 items)
   • Why not? (dependency, out of budget, separate project)

2. Top 5 risks (1 hour)

   • Identify biggest threats to project success
   • Estimate probability × impact
   • Define mitigation for top 3
   • Assign owner for each

Output: 1-2 page scope document + 5-item risk register

Detailed Version: Full Client Management Setup (2-4 weeks)

For larger engagements requiring comprehensive stakeholder management:

Week 1: Discovery & Mapping

Monday-Tuesday: Stakeholder Interviews (1 hour each, 10-12 people)

Interview guide (questions for each person):

• "What's your role in this project?"
• "What's success look like from your perspective?"
• "What concerns do you have?" (most important)
• "Who else should I talk to?"
• "What's your biggest constraint?" (time, budget, politics, technical)

Document: Name, role, interest, power, concerns, constraints

Wednesday: Stakeholder Map Workshop

Participants: Client sponsor, key client PM, your engagement leader (30 min)

• Review interview notes
• Plot all stakeholders on Power/Interest matrix together
• Identify:
  • Champions: Will actively support (ask them to help sell internally)
  • Skeptics: Need convincing (give regular updates, address concerns)
  • Resistors: May block (understand objections, involve in solution)
  • Informals: Have hidden influence (get input, leverage for influence)

Output: Stakeholder map with engagement strategy per person

Thursday: RACI Development Workshop

Participants: Your team + 2-3 key client people (2-3 hours, multiple meetings)

Pre-work:

• Draft list of 15-20 major tasks/decisions
• Group into 5-8 work streams

Workshop:

1. Present draft RACI (30 min)

   • Walk through each task
   • Explain your thinking

2. Gather input (1 hour)

   • "Who should be Responsible?"
   • "Who should be Accountable?" (usually same as R)
   • "Who needs to be Consulted?"
   • "Who just needs information?"

3. Resolve conflicts (30 min)

   • Address overlaps ("Why are both Jane and Tom Accountable?")
   • Clarify Consulted vs. Informed ("Do you need input or just updates?")

4. Document decisions (30 min)

   • Update RACI matrix
   • Send to all participants
   • Ask for formal sign-off ("This reflects our agreement, yes?")

Key guidance:

• Name one coordinating owner only when the governing instrument permits it; otherwise document the collective decision rule, required approvals, quorum, tie-breaker, reserved matters, and escalation route.
• More Consulted = more meetings, more coordination (estimate 1 hour per Consulted person per week)
• Disagreement here often reveals political dynamics; address openly

Friday: Scope & Risk Initial Assessment

Meeting (1 hour): Client sponsor + PM + your engagement lead

Agenda:

• "Here's what I understand we're delivering..." (1-page scope summary)
• "Here's what's NOT in scope..." (avoid scope creep)
• "Top risks I'm seeing..." (5 items with probability/impact)
• "What am I missing?"

Output: Initial draft of scope document + risk register

Week 2: Formal Scoping & Relationship Building

Monday-Tuesday: Detailed Scoping Session (2-3 hours total)

Process:

1. Draft detailed scope (with client PM)

   • "Included" section: 10-15 specific deliverables with owners
   • "Not Included" section: 5-10 things that might be assumed
   • Timeline with milestones
   • Assumptions (what does client need to do?)
   • Dependencies (what must happen before we start?)

2. Get stakeholder feedback

   • Share draft with "Manage Closely" stakeholders
   • Listen for: "But we also need..." (scope creep signals)
   • Document concerns

3. Finalize & get sign-off

   • Incorporate critical feedback
   • Sponsor signs off ("This is what we're doing")
   • Reference this when scope disputes arise

Wednesday-Thursday: Relationship Building

1:1s with key stakeholders (30 min each):

Invite: Each "Manage Closely" and "Keep Satisfied" person

Script:

• "I want to understand your perspective on this project"
• "What's important to you about this?"
• "What concerns do you have?"
• "How can I help you succeed?"
• "What's the best way to keep you updated?" (frequency, medium, detail level)

Outcome: Personal relationship + understanding of what matters to them

Friday: Risk Management & Governance Setup

Risk Workshop (1 hour with client PM + sponsor):

• Brainstorm top 10-12 risks
• Estimate: Probability (1-3), Impact (1-3)
• Identify owner for each top risk
• Define mitigation for top 3-4 risks

Governance Definition (30 min):

• Confirm meeting cadence:
  • Weekly: Client PM + your lead (30 min status)
  • Bi-weekly: Extended team (60 min working sessions)
  • Monthly: Steering committee with sponsor (60 min, status + decisions)
• Define escalation path (when/how to escalate issues)
• Define decision-making process ("How do you decide on scope changes?")

Output:

• Risk register (spreadsheet)
• Governance model (who meets when, how decisions made)

Week 3-4: Ongoing Management

Weekly Rhythms:

Every Week:

• Stakeholder 1:1s (with "Manage Closely" people): 15-30 min each

  • Quick sync on progress, blockers, decisions needed
  • Ask: "How are we doing?" (gauge satisfaction)

• Project Status Update (email to all)

  • "What we completed this week"
  • "What's coming next week"
  • "Any decisions needed?"
  • Tailor depth: Executives get 1-pager, teams get detailed list

• Risk Register Review (with client PM)

  • Update probabilities based on new info
  • Close risks that are no longer threats
  • Add new risks
  • Escalate high-score risks (>6 out of 9)

Every Two Weeks:

• Working Team Meeting (60 min)
  • Workstream updates (15 min each for 4 workstreams)
  • Issue review (blockers, decisions)
  • Next steps

Every Month:

• Steering Committee (60 min)

  • Executive summary of progress (5 min)
  • Metrics/KPIs against plan (10 min)
  • Top issues & decisions needed (20 min)
  • Risk review (10 min)
  • Next steps (5 min)

• Stakeholder Feedback (pulse check or quick 1:1)

  • "How clear are goals?" (1-5)
  • "How aligned is team?" (1-5)
  • "Anything we're not addressing?"

Common Pitfalls & How to Avoid Them

Pitfall 1: Wrong RACI, Unclear Accountability

• Problem: Coordination and authority are ambiguous or conflict with the governing instrument.
• Fix: Name a coordinating owner where useful, preserve required shared authorities, and document the decision and escalation route.
• Risk: Delay, rework, or unsafe informal decisions; no universal month estimate applies.

Pitfall 2: Not Surfacing Resistance Early

• Problem: Resistor stakeholder silently blocks project at last minute
• Fix: Map resistors early (Stakeholder Mapping), understand concerns, involve them in solution design
• Cost of skipping: Project delayed/killed in execution phase

Pitfall 3: Absent Sponsor

• Problem: Sponsor approves project but then unavailable for decisions/escalations
• Fix: In Week 1, establish that sponsor needs to be in monthly steering committee and available for decisions within 5 days
• Cost of skipping: Decisions bottleneck, project stalls

Pitfall 4: Scope Creep Without Change Management

• Problem: Client keeps asking for more; no process to say "that's a change"
• Fix: Establish scope document in Week 1. Any scope change requires sponsor approval + time/budget adjustment (or priority trade-off)
• Cost of skipping: material project budget overrun, team burnout

Pitfall 5: Not Closing Feedback Loop

• Problem: Stakeholder says "communication is poor" but nothing changes
• Fix: After feedback, explicitly say: "You mentioned X, here's what we're doing about it" (and do it!)
• Cost of skipping: Stakeholders lose faith in feedback process, become disengaged

Measurement: How to Know Stakeholder Management is Working

Weekly:

• ✓ Risk register updated (no surprises)
• ✓ No escalations from "Manage Closely" stakeholders (they're satisfied with communication)
• ✓ RACI is being referenced to clarify roles (sign it's useful)

Monthly:

• ✓ Steering committee has strong attendance (sign they view it as valuable)
• ✓ Decisions made within target timeframe (not bottlenecked)
• ✓ Feedback check shows above-target scores on "clear goals" and "aligned team"
• ✓ <2 change requests requiring rework (scope is clear)

Project Completion:

• ✓ Client rates satisfaction >8/10
• ✓ Scope changes stay within the agreed tolerance
• ✓ No surprises at final delivery (communication worked)
• ✓ Sponsor would work with you again

Red Flags: When Stakeholder Management is Failing

• ✗ Weekly escalations from sponsor → You're not solving issues before they escalate
• ✗ Steering committee attendance dropping → Stakeholders losing confidence
• ✗ Frequent "I didn't know about that" comments → Communication breakdown
• ✗ Scope change requests monthly → Original scoping was poor
• ✗ RACI being ignored ("We'll figure it out as we go") → Political dynamics undermining structure
• ✗ Resistor stakeholder suddenly says "This isn't what we agreed" → Didn't surface concerns early
• ✗ Team complaining stakeholders are hard to reach → Sponsor not enforcing availability
• ✓ One-page status email gets "thank you, very clear" → You're communicating at right level
• ✓ Scope change requests have clear business reason + sponsor approval → Good governance
• ✓ Sponsor proactively removes blockers → Strong sponsorship

Constructed Case Example: Enterprise Transformation Program

All organizations, people, amounts, durations, counts, actions, and outcomes in this case are fictional teaching assumptions, not a report of a real engagement or evidence that the frameworks caused success.

Situation: $3M, 12-month IT transformation for Fortune 500 company. Complex stakeholder group (IT, Finance, Operations, C-suite).

Application:

1. Stakeholder Matrix: Mapped 40+ people; focused on 8 high-power, high-interest sponsors
2. RACI: 23 major work streams defined with clear accountability (prevented "he said/she said")
3. Executive Presentations: Monthly steering committee (Slide 2-13 structure above) + board-level updates (more strategic, less detail)
4. Difficult Conversations: 3 major ones: CFO concerned about cost overruns, VP Ops worried about disruption, CTO questioned vendor selection
   • Each addressed through scoping, communication, and involving skeptics in solution design
5. Relationship Mapping: Identified that COO (low formal power) was key influencer of CFO; got COO as active supporter early
6. Risk Register: 8 major risks tracked; biggest one (key resource leaving) mitigated by documenting knowledge weekly
7. Change Control: 6 scope change requests submitted; 3 approved (integrated into timeline), 3 deferred to Phase 2

Illustrative outcome: The scenario assumes delivery on its stated budget and timeline and a 9/10 client rating; a real review would also test adoption, business value, harm, control performance, and attribution.

Question to investigate: Which stakeholder, technical, commercial, governance, and operating factors contributed to the result, and what evidence would disconfirm the team's preferred explanation?

Operating Manual: Your Client Engagement Playbook

Constructed-policy boundary: All hours, durations, counts, cadences, scores, thresholds, scripts, and outputs in this operating manual are fictional teaching assumptions. Replace them with approved engagement-specific evidence, contract, safety, regulatory, accessibility, workforce, procurement, confidentiality, and governance constraints.

This operating manual contains constructed sample hours, durations, counts, cadences, scores, thresholds, scripts, and outputs. None is a benchmark, contractual commitment, or guarantee. Replace each sample with a named owner, rationale, authority, privacy/accessibility needs, evidence source, tolerance, and review trigger. Use it alongside project execution in Chapter 11.

Weeks 1-2: Stakeholder Mapping & Engagement Planning

Objective: Identify all stakeholders, understand their interests and influence, and establish engagement protocols before work begins.

Week 1: Stakeholder Identification & Power/Interest Assessment (16-20 hours)

Day 1-2: Stakeholder Discovery (8-10 hours)

Activities:

• Stakeholder Brainstorming (2 hours):

  • With project sponsor: "Who will be affected by this project? Who cares about outcomes? Who can block or support us?"
  • Start list: Typically 20-50 people for medium-large projects
  • Categorize by function: Executives, managers, end users, vendors, regulators, customers (if B2B)
  • Document names, titles, departments, contact info
  • Tool: Excel spreadsheet or stakeholder management tool
  • Output: Initial stakeholder list

• Stakeholder Interviews - Round 1 (6-8 hours):

  • Interview sponsor and 3-5 key executives (30-60 min each)
  • Questions:
    • "Who else should I talk to?" (snowball sampling to find hidden stakeholders)
    • "Who will support this project? Who might resist?"
    • "Who has been involved in similar efforts before?" (learn from history)
  • Output: Expanded stakeholder list (now 30-70 people typical)

Day 3-5: Power/Interest Assessment (8-10 hours)

Activities:

• Power Assessment (3-4 hours):

  • For each stakeholder, rate power (High/Medium/Low):
    • High Power: Can approve/veto project, control budget, or mandate requirements
      • Examples: Sponsor, C-suite executives, board members, major customer executives
    • Medium Power: Can influence decisions, provide resources, or escalate concerns
      • Examples: Department heads, senior managers, key customers, regulatory contacts
    • Low Power: Affected by project but limited influence on decisions
      • Examples: End users, frontline staff, junior employees
  • Criteria: Decision authority, budget control, political capital, relationships with high-power stakeholders
  • Document rationale: "CFO rated High Power because controls budget approval"

• Interest Assessment (3-4 hours):

  • For each stakeholder, rate interest (High/Medium/Low):
    • High Interest: Personally affected, accountable for outcomes, or passionate about topic
    • Medium Interest: Somewhat affected or interested but not primary focus
    • Low Interest: Minimal personal impact; may not care
  • Sources: Interview feedback, organizational impact, job role alignment
  • Example: "VP Sales has High Interest because sales team is primary user"

• Stakeholder Matrix Plotting (2 hours):

  • Plot each stakeholder on 2×2 Power/Interest grid:

    High Power, High Interest → MANAGE CLOSELY (top priority)
    High Power, Low Interest → KEEP SATISFIED (don't ignore)
    Low Power, High Interest → KEEP INFORMED (engage regularly)
    Low Power, Low Interest → CHECK RIGHTS, IMPACT, ACCESS BARRIERS, AND CHANGE
    

  • Identify the stakeholders needing decision engagement and the low-power or affected groups needing accessible input or remedy; do not use a fixed count.
  • Output: Stakeholder matrix (visual grid + prioritized list)

Outputs (Week 1):

• Stakeholder list sized to the decision and affected population
• Power/Interest assessment for each
• Stakeholder matrix (2×2 grid showing priorities)
• Decision authorities, affected groups, and engagement priorities identified with rationale

Red Flags:

• 2 people claim to be "the" decision-maker → Escalate to clarify authority

• Sponsor unable to identify stakeholders → Project scope unclear; revisit charter
• More than half of stakeholders rated "Low Interest" -> Risk of disengagement; revisit communication strategy
• High-power stakeholder actively opposes project → Major risk; address immediately

Resource Requirements:

• Project Manager: 16-20 hours
• Sponsor: 4-6 hours (initial interviews, validation)

Week 2: RACI Development & Communication Planning (16-20 hours)

Day 1-3: RACI Matrix Development (10-12 hours)

Activities:

• Decision Inventory (2-3 hours):

  • List all major decisions the project will require
  • Categories:
    • Strategic: What are we building? What's the scope? (5-10 decisions)
    • Tactical: How will we build it? What vendors? What approach? (10-20 decisions)
    • Operational: Day-to-day execution decisions (ongoing, too many to list all)
  • Example decisions:
    • "Approve project scope"
    • "Select technology vendor"
    • "Approve design specifications"
    • "Sign off on testing results"
    • "Approve go-live"
  • Output: Decision inventory (15-30 major decisions documented)

• RACI Assignment (6-8 hours):

  • For each decision, assign roles using RACI:
    • Responsible (R): Who does the work? (Often multiple people; project team)
    • Accountable (A): Who owns the outcome or decision under the chosen RACI convention? Verify actual authority; some decisions require a board, committee, dual control, or several approvals.
    • Consulted (C): Who provides input before decision? (Subject matter experts, impacted stakeholders)
    • Informed (I): Who is told after decision is made? (FYI recipients)
  • Example:

    | Decision | Sponsor | PM | Tech Lead | End Users | Vendor |
    |----------|---------|----|-----------|-----------|----- --|
    | Approve project scope | A | R | C | C | I |
    | Select technology vendor | A | R | R | I | C |
    | Approve design | C | R | A | C | I |
    | Go-live approval | A | R | C | I | I |
    

  • Rules:
    • Use one "A" only when it faithfully represents the real governance model; otherwise document the collective or multi-approval rule explicitly
    • "R" can have multiple people (team collaborates on work)
    • Size "C" from expertise, rights, impact, representation, and decision need rather than a universal limit
    • Size "I" from notice obligations, usefulness, confidentiality, and accessibility rather than assuming broad circulation is harmless
  • Common mistake: Using RACI labels to overwrite actual authority; reconcile ambiguity with the governing owner instead of automatically consolidating to one decider
  • Output: RACI matrix (decisions × stakeholders grid)

• RACI Validation (2 hours):

  • Review RACI with sponsor and top 5 stakeholders
  • Check: "Do you agree you're Accountable for X?" (get confirmation)
  • Resolve conflicts: "Both of you think you're Accountable for vendor selection. Who makes final call?"
  • Document and circulate approved RACI
  • Output: Approved RACI matrix

Day 4-5: Communication & Engagement Planning (6-8 hours)

Activities:

• Communication Plan Development (4-5 hours):
  • For each stakeholder group (not each individual), define:
    • Frequency: How often to communicate? (daily, weekly, bi-weekly, monthly, as-needed)
    • Medium: Email, meeting, dashboard, presentation, 1-on-1
    • Content: What information do they need? (Status summary, detailed metrics, decisions needed, risks)
    • Owner: Who delivers communication? (PM, team lead, sponsor)
  • Example plan:

| Stakeholder Group | Frequency | Medium | Content | Owner |
|-------------------|-----------|--------|---------|-------|
| Project Sponsor | Weekly | Email | 1-page status (RAG status, top risks, decisions needed) | PM |
| Steering Committee | Monthly | Meeting (2h) | Detailed review: progress, budget, risks, decisions | PM |
| Project Team | Daily | Standup (15min) | Progress, blockers, help needed | PM/Team Leads |
| End Users | Bi-weekly | Email | Updates on progress, training schedule, go-live timeline | PM |
| Executives (High Power, Low Interest) | Monthly | Email | High-level summary (1 paragraph) | Sponsor |
```

• Tool: Communication matrix (spreadsheet)

• Output: Communication plan document

• Escalation Protocol (1-2 hours):

  • Define when and how to escalate issues:
    • Level 1 (Team): Issues team can resolve (blockers, minor delays)
    • Level 2 (PM): Issues requiring PM decision (resource conflicts, minor scope changes, <1 week delays)
    • Level 3 (Sponsor): Issues requiring sponsor decision (budget changes, scope changes, >1 week delays, high-impact risks)
    • Level 4 (Steering Committee): Strategic issues (major scope changes, project viability, multi-month delays)
  • Escalation timeline: 24 hours for Level 1 → 48 hours Level 2 → 72 hours Level 3 → Immediate for Level 4
  • Document: "If you encounter X, escalate to Y within Z hours"
  • Output: Escalation protocol (1-page decision tree)

• Engagement Kickoff Prep (1 hour):

  • Schedule stakeholder kickoff meeting (1-2 hours, Week 3)
  • Invite all high-priority stakeholders (Manage Closely + Keep Satisfied quadrants)
  • Agenda:
    • Project overview (objectives, scope, timeline)
    • Stakeholder roles (present RACI)
    • Communication plan (how we'll stay connected)
    • Q&A
  • Prepare slide deck (10-15 slides)
  • Output: Kickoff meeting scheduled and materials prepared

Outputs (Week 2):

• RACI matrix (approved by sponsor and stakeholders)
• Communication plan (frequency, medium, content, owner for each group)
• Escalation protocol (when and how to escalate)
• Stakeholder kickoff meeting scheduled

Red Flags:

• 2 stakeholders claim "Accountable" for same decision → Conflict; must resolve before proceeding

• RACI shows sponsor has no "A" assignments → Disengaged sponsor; risk of decision delays
• Communication plan has >10 different meeting cadences → Too complex; simplify to 3-4 standard rhythms
• Escalation protocol unclear or >5 levels → Bureaucratic; streamline

Resource Requirements:

• Project Manager: 16-20 hours
• Sponsor: 4-6 hours (RACI validation, escalation review)
• Key stakeholders: 2-4 hours total (RACI validation input)

Week 3: Stakeholder Kickoff & Alignment

Objective: Formally launch stakeholder engagement; ensure alignment on roles, communication, and expectations.

Stakeholder Kickoff Meeting (2-3 hours)

Attendees: Sponsor, PM, top 10-15 stakeholders (Manage Closely + Keep Satisfied quadrants), key team leads

Agenda:

1. Welcome & Objectives (15 min):

   • Sponsor introduces project: Why we're doing this, what success looks like
   • PM presents objectives, scope, timeline (high-level)

2. Stakeholder Roles & RACI (30 min):

   • Present RACI matrix: "Here's who is Responsible, Accountable, Consulted, Informed for key decisions"
   • Highlight each person's specific role: "Sarah, you're Accountable for vendor selection. John, you're Consulted on design."
   • Q&A: "Do you have questions about your role?"

3. Communication & Engagement Plan (20 min):

   • Present communication plan: "Here's how we'll keep you informed"
   • Review meeting cadence: Daily standups (team), weekly email (sponsor), monthly steering committee (executives)
   • Escalation protocol: "If issues arise, here's how we escalate"

4. Expectations & Ground Rules (15 min):

   • Set expectations:
   • Responsiveness: "We need decisions within 48 hours for critical items"
   • Availability: "Monthly steering committee attendance is mandatory for Accountables"
   • Scope discipline: "Changes require formal change request; no informal adds"

• Ground rules:
  • Transparency: "We'll share bad news early"
  • Collaboration: "We're one team; no finger-pointing"
  • Data-driven: "Decisions based on data, not opinions"

5. Risk & Issue Discussion (20 min):

   • Present top 5 risks (from project plan)
   • Ask: "What concerns you most? What are we missing?"
   • Document feedback; incorporate into risk register

6. Q&A & Next Steps (20 min):

   • Open floor for questions
   • Confirm next milestones: "Week 4-6: Requirements gathering. We'll need your input in interviews."
   • Confirm next steering committee meeting (typically 4 weeks out)

Outputs:

• Stakeholder alignment on roles, communication, and expectations
• Meeting minutes (decisions, action items, concerns raised)
• Updated risk register (based on stakeholder input)

Red Flags:

• Less than half of invited stakeholders attend -> Low engagement; reschedule or 1-on-1 follow-ups
• Stakeholders challenge RACI in meeting → Insufficient pre-alignment; pause and resolve offline
• Major concerns raised that weren't in risk register → Risk identification was incomplete; extend planning

Weeks 4+: Ongoing Stakeholder Engagement (Recurring Cadence)

Objective: Maintain stakeholder alignment through regular communication, proactive issue management, and relationship building.

Weekly Activities (3-5 hours/week)

1. Sponsor 1-on-1 (30-60 min)

• Timing: Every Monday (or weekly recurring)
• Format: 1-on-1 meeting or call
• Agenda:
  • Progress update (5 min): What was completed last week, what's planned this week
  • RAG status (5 min): Schedule (Green/Amber/Red), Budget (G/A/R), Scope (G/A/R), Risk (top 3)
  • Decisions needed (10-20 min): Present 1-3 decisions where sponsor is Accountable
  • Escalations (5-10 min): Any issues requiring sponsor intervention
  • Relationship health check (5 min): "How do you feel about progress? Any concerns?"
• Output: Decision log (what was decided), action items (what sponsor will do)

Red Flags:

• Sponsor cancels >2 consecutive meetings → Disengagement; escalate to their manager or steering committee
• Sponsor defers all decisions → Decision paralysis; simplify choices or escalate
• Sponsor micromanages (wants daily updates) → Reset expectations; provide more transparency but maintain boundaries

2. Status Reporting (2-3 hours)

• Timing: Every Friday (or weekly recurring)
• Format: 1-page email to all stakeholders (use template for consistency)
• Content:
  • Header: Project name, reporting period (Week X), PM name
  • Executive Summary (3-4 sentences):
    • Overall status: Green/Amber/Red
    • Key accomplishment this week
    • Biggest concern or risk
    • Ask (if any): "We need your input on X by Y"
  • Progress This Week (5-7 bullets):
    • Completed: "Finalized requirements document (signed off)"
    • In Progress: "Vendor selection (3 demos completed, decision next week)"
    • Planned for Next Week: "Begin design phase, kick off user interviews"
  • RAG Status:
    • Schedule: GREEN - On track for Month 8 go-live
• Budget: AMBER - Trending 5 percent over budget due to vendor costs
  • Scope: GREEN - No changes this week
  • Top 3 Risks:
    • Risk 1: Key resource (Sarah) may leave company (Probability: Medium, Impact: High, Mitigation: Cross-training backup)
    • Risk 2: Vendor delivery delayed by 1 week (Probability: Low, Impact: Medium, Mitigation: Compressed testing timeline)
    • Risk 3: End user adoption concerns (Probability: Medium, Impact: High, Mitigation: Enhanced training program)
  • Decisions Needed (if any):
    • Decision: Approve additional $50K for vendor customization
    • Owner: Sponsor
    • Due Date: Monday, Week X+1
    • Context: Vendor standard product doesn't meet 2 critical requirements; customization needed
  • Next Milestones:
    • Week X+2: Design review with stakeholders
    • Week X+4: Steering committee meeting
• Tool: Email template (reuse every week for consistency)
• Output: Weekly status email (distributed Friday afternoon)

Red Flags:

• Stakeholders stop reading/responding to status emails → Email fatigue; shorten format or add visual dashboards
• Status always "Green" for >8 weeks → Unrealistic; likely hiding issues
• Same risks on list for >4 weeks without mitigation progress → Risk management ineffective; escalate

3. Stakeholder Pulse Check (1 hour/week)

• Timing: Ad hoc throughout week
• Activity: Informal check-ins with 1-2 high-priority stakeholders
• Purpose: Build relationships, surface concerns early, prevent surprises
• Format: Casual conversation (coffee chat, hallway conversation, Slack message)
• Questions:
  • "How's the project going from your perspective?"
  • "Any concerns I should know about?"
  • "Is there anything we're not communicating that you need?"
• Output: Notes on stakeholder sentiment (add to stakeholder register)

Monthly Activities (6-10 hours/month)

1. Steering Committee Meeting (2-3 hours)

• Timing: Monthly (typically last Friday of month)
• Attendees: Sponsor, steering committee (3-7 executives), PM, key team leads
• Format: In-person or video meeting
• Agenda (2-hour meeting):
  • Progress Update (20 min):
    • Slides 1-3: Accomplishments this month, planned for next month, overall status (Green/Amber/Red)
    • Focus on outcomes, not activities: "Delivered working prototype" not "Had 10 meetings"
  • Financial Review (10 min):
    • Slide 4: Budget vs. actual (table showing planned, actual, variance by category)
• Forecast to complete: "We'll finish $50K over budget (5 percent variance) due to vendor costs"
  • Ask if additional funding needed: "Request approval for $50K contingency release"
  • Schedule Review (10 min):
    • Slide 5: Gantt chart showing critical path and milestones
    • Status: "On track for Month 8 go-live" or "At risk: 2 weeks behind due to vendor delay"
    • Mitigation if behind: "We're compressing testing timeline and adding resources"
  • Risk & Issue Review (20 min):
    • Slides 6-7: Top 5 risks (probability, impact, mitigation)
    • Top 3 issues requiring steering committee decision or awareness
    • Example: "Risk: Key resource Sarah may leave. Mitigation: We've cross-trained John and documented her knowledge."
  • Decisions Needed (30 min):
    • Slides 8-10: 2-3 major decisions requiring steering committee approval
    • Format per decision:
      • Context: What's the situation?
      • Options: 2-3 alternatives (with pros/cons)
      • Recommendation: PM's recommended option
      • Ask: Approve/reject/defer?
    • Example: "Decision: Approve vendor customization ($50K). Options: (1) Approve customization, (2) Descope requirements, (3) Switch vendors. Recommendation: Approve customization (maintains scope, lowest risk)."
  • Q&A & Next Steps (10 min):
    • Open floor for questions
    • Confirm decisions made
    • Next meeting date and topics
• Output: Meeting minutes (decisions, action items, attendees), updated decision log

Red Flags:

• Less than half steering committee attendance -> Low engagement; escalate to sponsor or CEO
• No decisions made (all deferred) → Decision paralysis; simplify choices or escalate to CEO
• Meeting extends >2.5 hours → Too detailed; elevate to strategic level
• Same issues on agenda for >2 months → Not resolving issues; change approach

2. Stakeholder Satisfaction Check (1-2 hours, quarterly)

• Timing: Every 3 months (Months 3, 6, 9, 12)
• Format: Anonymous feedback form (5-10 questions, 5 min to complete)
• Questions:
  • "On a scale of 1-10, how satisfied are you with project progress?"
  • "Are you receiving enough communication? Too much? Too little?"
  • "Do you understand your role and responsibilities?"
  • "What's going well? What should we improve?"
  • "Any concerns or feedback?"
• Distribution: Email feedback link to all stakeholders
• Analysis: Aggregate results; identify themes
• Action: Present findings to sponsor; implement top 2-3 improvements
• Output: Satisfaction memo (summary of results + action plan)

Red Flags:

• Average satisfaction <6/10 → Stakeholder discontent; investigate root causes
• More than 30 percent say "too little communication" -> Increase frequency or transparency
• Multiple stakeholders cite same issue → Systemic problem; address urgently

3. Relationship Mapping Update (1-2 hours, quarterly)

• Activity: Update stakeholder power/interest matrix and relationship map
• Questions:
  • Has anyone's power or interest changed? (promotions, departures, shifting priorities)
  • Have new stakeholders emerged? (new hires, new departments affected)
  • Are any relationships strained? (conflicts, misalignments)
• Action: Adjust engagement approach based on changes
  • Example: "CFO was Low Interest, now High Interest due to budget concerns → Increase communication frequency"
• Output: Updated stakeholder matrix

Difficult Conversations & Conflict Resolution (As Needed)

Objective: Address stakeholder conflicts, resistance, or concerns proactively before they derail the project.

Negotiation bridge: prepare before the conversation

Use the foundational negotiation logic in Chapter 7 before treating a difficult conversation as a bargaining session. Verify who can bind each organization; identify issues that are negotiable and non-negotiable; calculate the BATNA, reservation package, target, and possible ZOPA; and separate factual evidence from estimates about the other side. ^{[7] [8]}

For client work, translate a headline dispute into packages. A timeline package might combine scope, sequencing, staffing, acceptance criteria, governance, price, and service levels. Confirm that any package is operationally feasible and approved by the people who hold contractual, financial, legal, professional, security, or safety authority. Never promise an approval you do not control.

Applied multiparty role play — constructed service recovery

Scenario: A client wants an eight-week launch after a supplier delay. The consulting lead, client operations leader, procurement owner, security officer, and supplier each receive a private role brief with different priorities, authority, evidence, and alternatives. No role may invent facts or waive another role's required approval.

Deliverables:

1. A party-interest-authority map, including absent affected groups and representation gaps.
2. Each party's BATNA, reservation package, target, uncertainty, and evidence source.
3. Three multi-issue packages covering scope, timing, staffing, cost, security evidence, acceptance, and recovery.
4. A coalition and process plan that states the decision rule, caucus boundaries, disclosure rules, and escalation route.
5. A final term sheet or documented impasse, plus an ethics review: who gained or lost power, what could not be traded, what information was withheld and why, and whether the process allowed informed dissent.

Debrief: Compare outcome value with process legitimacy, implementation risk, distributional effects, relationship effects, and treatment of the least powerful party. A signed agreement is not automatically a good decision; walking away is not automatically failure.

Framework for Difficult Conversations

Safety and authority gate: Before any direct outreach, private meeting, empathy script, or escalation, check whether the issue involves safety, retaliation, discrimination, harassment, violence, investigation, legal hold, accommodation, union, protected reporting, professional misconduct, confidentiality, or another formal obligation. If so, pause the direct script and use the approved HR, legal, compliance, security, safety, labor, or professional route.

Preparation (1-2 hours before conversation):

1. Identify the Issue:
   • What is the specific concern or conflict?
   • Example: "CFO is blocking budget approval due to cost concerns"
2. Understand Their Perspective:
   • Why do they feel this way? (empathy)
   • What's at stake for them? (career, budget, reputation, workload)
   • Example: "CFO is under pressure to cut costs; sees this project as discretionary"
3. Prepare Your Position:
   • What are the facts? (data, not opinions)
   • What's the business case? (why this matters)
   • What are you willing to compromise on? (flexibility)
4. Plan the Conversation:
   • Where and when? (only after the safety/authority gate; choose a channel that supports safety, accessibility, privacy, records, and participation)
   • Who should attend? (1-on-1 vs. including sponsor)
   • What's the goal? (alignment, decision, understanding)

Conversation Structure (30-60 min):

1. Open with Empathy (5 min):

   • Acknowledge their perspective: "I understand you're concerned about the budget. I want to understand your concerns."
   • Build rapport; show you're listening

2. Understand Their Concerns (10-15 min):

   • Ask open-ended questions: "What specifically concerns you? What would make you more comfortable?"
   • Listen actively; don't interrupt or defend
   • Summarize: "So if I understand correctly, you're worried about X and Y. Is that right?"

3. Share Your Perspective (10-15 min):

   • Present facts and data: "Here's what the data shows..."
   • Explain business case: "If we don't do this project, the impact will be..."
   • Be transparent about risks: "I understand there are risks. Here's how we're mitigating them."

4. Explore Options (10-15 min):

   • Brainstorm together: "What if we... (alternative approach)?"
   • Find common ground: "We both want X. How can we get there?"
   • Offer compromises: "Would it help if we... (reduce scope, phase approach, add oversight)?"

5. Agree on Next Steps (5-10 min):

   • Summarize agreement: "So we're aligned that..."
   • Confirm actions: "You'll do X, I'll do Y, by when?"
   • Schedule follow-up: "Let's check in next week to see how this is going."

Follow-Up (Post-Conversation):

• Document conversation: Email summary of what was discussed and agreed
• Execute on commitments: Do what you said you'd do
• Monitor relationship: Check in proactively; don't wait for next conflict

Example Difficult Conversations:

Scenario 1: CFO Blocking Budget Approval

• Issue: CFO won't approve $50K additional budget for vendor customization
• Approach:
  • Understand: "What's driving your concern? Is it the amount, the vendor, or budget constraints?"
  • Present data: "Without customization, we can't meet 2 critical requirements (show impact: delayed go-live, user adoption risk)"
  • Explore options: "Could we phase the customization (do half now, half in 6 months)? Or find lower-cost alternative?"
  • Outcome: Agree to phase approach ($25K now, $25K later) or descope 1 requirement

Scenario 2: VP Operations Worried About Disruption

• Issue: VP Ops fears project will disrupt operations during peak season
• Approach:
  • Empathize: "I understand you can't afford downtime during Q4. That makes sense."
  • Understand: "What specifically worries you? Timing? Training? System downtime?"
  • Propose solutions: "What if we delay go-live until January (after peak)? Or do phased rollout (pilot team first, full rollout later)?"
  • Outcome: Agree to delay go-live or phased approach

Scenario 3: CTO Questions Vendor Selection

• Issue: CTO disagrees with vendor choice; prefers different vendor
• Approach:
  • Understand: "What makes you prefer Vendor B over Vendor A? What criteria matter most to you?"
  • Present decision rationale: "Here's how we scored vendors on 10 criteria. Vendor A won on cost, integration, and support."
  • Involve in solution: "Would it help if you attended vendor demo or reviewed technical architecture?"
  • Outcome: CTO sees rationale and approves, OR surfaces valid technical concern and recommends re-evaluation

Red Flags in Difficult Conversations:

• Stakeholder refuses to engage → Escalate to sponsor or their manager
• Conversation becomes personal or emotional → Pause, reschedule when cooler heads prevail
• No agreement after 2-3 attempts → Escalate to steering committee for decision
• Agreement made but stakeholder doesn't follow through → Escalate to sponsor

Measurement Dashboard (Weekly Tracking)

Track stakeholder health using these metrics:

Stakeholder Engagement Score (1-10 scale):

• For top 5-10 stakeholders, rate weekly:
  • 10: Highly engaged (attends all meetings, responds quickly, actively supportive)
  • 7-9: Engaged (participates, generally supportive)
  • 4-6: Neutral (attends but passive, slow to respond)
  • 1-3: Disengaged (skips meetings, doesn't respond, resistant)
• Target: Average score >7 for top stakeholders
• Red flag: Any stakeholder <5 for >2 weeks → Intervention needed

Decision Velocity (Days to Decide):

• Track time from "decision needed" to "decision made"
• Target: <3 days for tactical decisions, <7 days for strategic decisions
• Red flag: Decisions stalling >14 days → Escalate or simplify

Scope Change Requests:

• Count: # of change requests submitted, approved, rejected, deferred
• Target: <5 change requests per month (more indicates scope instability)
• Red flag: >10 change requests/month → Scope management broken

Risk Escalations:

• Count: # of risks escalated to sponsor or steering committee
• Target: <3 escalations/month (more indicates risk management gaps)
• Red flag: Same risk escalated >2 times → Mitigation not working

Client Satisfaction (Monthly Pulse):

• Quick 1-question pulse check: "How satisfied are you with project progress? (1-10)"
• Target: Average >8
• Red flag: Score <6 for any individual or average <7 → Investigate root cause

Communication Health:

• Email response rate: % of stakeholders responding to requests within 48 hours
• Target: above 80 percent
• Red flag: below 60 percent -> Communication fatigue or disengagement

Contingency Playbook

Scenario 1: Stakeholder Disengagement

• Trigger: Key stakeholder stops attending meetings, doesn't respond to emails for >1 week
• Response:
  • Day 1: Direct outreach (phone call or in-person): "I noticed you haven't been able to join meetings. Is everything okay? How can I support you?"
  • Day 2: Escalate to sponsor: "Stakeholder X is disengaged. Can you help re-engage them?"
  • Day 3: If no response, escalate to their manager or steering committee
  • If participation is unavailable, check rights, representation, authority, confidentiality, accessibility, harm, and decision continuity; use an authorized substitute or pause rather than treating absence as permission to proceed.

Scenario 2: Decision Stalemate (Multiple Stakeholders Can't Agree)

• Trigger: Decision has been discussed 3+ times with no resolution
• Response:
  • Facilitate decision workshop (2 hours):
    • Present data objectively
    • Use decision criteria framework (score options on agreed criteria)
    • Force rank options: "If you had to choose one, which would it be?"
  • If still no agreement: Escalate to sponsor or steering committee to make final call
  • Document decision rationale to prevent revisiting

Scenario 3: Scope Creep (Unapproved Requests)

• Trigger: Stakeholders requesting features or changes without formal change request
• Response:
  • Enforce change control: "That's a great idea. Please submit a formal change request so we can evaluate impact on scope, schedule, and budget."
  • Present trade-offs: "To add X, we'd need to descope Y or extend timeline by Z weeks. Which do you prefer?"
  • Say no when needed: "That's out of scope for this project. We can consider it for Phase 2."
  • Document all rejected requests (change log) to prevent future conflicts

Scenario 4: Relationship Breakdown (Conflict Between Stakeholders)

• Trigger: Two stakeholders in open conflict, affecting project decisions
• Response:
  • Facilitate mediation (1-2 hours):
    • Understand both perspectives separately (1-on-1 conversations)
    • Facilitate joint conversation (focus on data and shared goals, not personalities)
    • Find common ground: "You both want the project to succeed. How can we make that happen?"
  • If mediation fails: Escalate to sponsor to adjudicate
  • If a person must be recused or participation changed, document the authority, rights, representation, confidentiality, conflict, harm, and appeal/escalation basis; a project manager cannot remove a required decision-maker unilaterally.

Scenario 5: Sponsor Departure or Change

• Trigger: Sponsor leaves company, changes roles, or loses authority
• Response:
  • Immediate action: Identify new sponsor within 48 hours (escalate to CEO if needed)
  • Onboard new sponsor: 2-hour briefing (project context, status, decisions needed)
  • Reset expectations: New sponsor may have different priorities; align early
  • Document transition: Update RACI, communication plan with new sponsor

Summary: Client Management Operating Manual

Key Principles:

1. Early and continuing stakeholder analysis: Identify affected parties before material decisions and update the map as impact and coalitions change.
2. Clear coordination and authority: RACI can prompt role discussion but does not prevent conflict or create approval authority.
3. Decision-relevant communication: Set cadence and channel from governance, urgency, risk, accessibility, and audience need.
4. Evidence-aware conversations: Use quantitative and qualitative evidence, values, constraints, uncertainty, affected-party input, and the business case; distinguish unsupported opinion from legitimate normative or distributional concerns.
5. Safe conflict handling: Address concerns through the appropriate direct, mediated, HR, legal, compliance, or safety route.
6. Measurement & Adjustment: Track engagement score, decision velocity, satisfaction; adjust approach as needed

When to use selected components:

• Engagements where the component fits the decision, contract, professional obligations, and affected parties
• Projects with complex authority, impact, or stakeholder environments; no numeric stakeholder threshold applies
• High-risk projects requiring executive alignment
• Transformation programs affecting multiple functions

Adapt Based On:

• Project size and risk: Tailor using value, consequence, regulation, duration, interfaces, and uncertainty rather than fixed dollar/month cutoffs.
• Stakeholder complexity: Simple stakeholder landscape (3-5 people) requires less structure
• Client culture: Startup → informal communication; Enterprise → formal governance

This operating manual can structure engagement decisions; it does not ensure alignment, engagement, satisfaction, adoption, business value, or legal compliance.