The Unwritten Playbook: Consulting Advice They Don’t Teach You in Training

The Client Whisperer: Building Relationships That Survive Project Storms

"We’re going to need you to step up into the leadership role in your current team as the other two engineers have fallen out with the product owner." my firm’s unit manager told me over the phone. My surprise was almost palpable.

For the sake of anonymity let’s call the product owner Ted. Ted was the PO who ran the project and was a vital stakeholder in achieving success in the organisation. The previous consultants had apparently created such a mess that he’d vowed never to work with "overpriced advisors" again.

Six months later, Ted was personally requesting me for his next project and telling his colleagues I was "different from other consultants."

What changed? Not my technical skills—those remained constant. What changed was my approach to the relationship.

Welcome to the second instalment of "The Unwritten Playbook," where I’m sharing the hard-earned wisdom that most consultants learn through painful experience. Today, we’re diving into the most crucial and least taught aspect of consulting: building client relationships that weather the inevitable storms of complex projects.

Reading the Unwritten Org Chart: Finding the Real Decision-Makers

Every organisation has two org charts: the official one they show you during onboarding, and the real one that determines how decisions actually get made. Learning to read the latter is perhaps the most valuable skill in consulting.

I once spent three weeks carefully building support for a solution with a client’s "leadership team," only to have everything dismantled in five minutes by an unassuming IT manager who wasn’t even in most of our meetings. As it turned out, the executive sponsor deferred to this manager on all technical decisions because they’d worked together for 15 years.

Look for these telltale signs of the real power brokers:

Who gets consulted before decisions are finalised
Whose objections immediately halt progress
Who speaks least but is most attentively listened to
Whose calendar dictates when key meetings happen
Who can bend or ignore the organisation’s standard processes

But beware—power isn’t always where you expect it. I’ve seen executive assistants with more practical influence than directors, and junior developers who could sink projects because they were the only ones who understood legacy systems.

Unwritten Rule 1️⃣: Invest early in identifying both the formal and informal influence networks. The project kickoff document tells you who should matter; the first few weeks show you who actually does.

The Expectation Gap: Why Clients Are Often Disappointed Even with Good Delivery

Here’s a painful truth: You can deliver exactly what’s in the statement of work and still have an unhappy client.

The expectation gap exists because clients aren’t buying your deliverables—they’re buying the outcomes they believe those deliverables will create. And they often have unstated expectations about how those outcomes will materialise.

I learned this lesson the hard way after delivering a complex data architecture that met every specified requirement. The client’s feedback? "This isn’t what we wanted." After some digging, I discovered they expected the architecture to solve data quality problems that weren’t mentioned anywhere in our scope but were their primary motivation for the project.

To bridge the expectation gap:

Ask about hoped-for outcomes, not just requirements: “When this project is successful, what will be different for your organisation?”
Uncover the project’s origin story: “What prompted this initiative in the first place?”
Identify the unspoken fears: “What concerns do you have about this approach?”
Surface assumptions regularly: “Let me check my understanding of what success looks like…”
Distinguish between “must-haves” and “nice-to-haves”: “If we had to focus on just three capabilities, which would deliver the most value?”

A technique I’ve found invaluable is to check-in regularly with key project stakeholders to validate if you’re moving in the right direction. This ensures the business outcomes, emotional wins, and political necessities that truly define success in the client’s eyes are being met.

Unwritten Rule 2️⃣: The client’s unstated expectations will sink your project faster than any technical challenge. Make the implicit explicit as early as possible.

Delivering Bad News: The Art of Transparency Without Panic

In almost a decade of consulting, I’ve never seen a complex project go exactly to plan. The differentiator between consultants who build trust and those who lose it isn’t whether things go wrong—it’s how they handle it when they inevitably do.

I remember the dread I felt discovering a critical integration wouldn’t work as planned three weeks before launch. My instinct was to scramble for a solution before saying anything. A mentor gave me advice I’ve followed ever since: "Bring problems to clients while they’re still problems, not after they’ve become disasters."

The framework I now use for delivering bad news:

Early warning, no surprises: Flag issues as soon as you see them, not when they’re unavoidable
Context before content: Start with the broader project context (“Overall, we’re on track with 7 of 8 workstreams…”)
Clear, direct statement of the issue: No technical jargon or sugar-coating
Impact assessment: What this means for the project objectives
Options with recommendations: Never bring problems without potential solutions
Clear next steps: Who does what by when

The most counterintuitive lesson I’ve learned is that properly delivered bad news often strengthens client relationships. It demonstrates integrity, transparency, and confidence—all traits clients value more than an unblemished record.

I once had a client tell me: "I don’t trust consultants who say everything’s going perfectly. I trust consultants who tell me about problems while there’s still time to fix them."

Unwritten Rule 3️⃣: How you deliver bad news defines your relationship more than how you deliver good news. Practice the difficult conversations before you have them.

The Insurance Policy: Documenting Conversations Without Being Paranoid

Documentation in consulting serves two purposes: creating deliverables and covering yourself. The latter is rarely discussed in training but is essential to survival.

I don’t mean this in a cynical way. Clear documentation prevents honest misunderstandings, helps clients defend decisions to their stakeholders, and ensures continuity when team members change—which they inevitably will during long projects.

A former colleague lost a client relationship because he couldn’t prove the client had approved a critical design decision that later proved problematic. The client genuinely didn’t remember giving that approval in a rushed hallway conversation.

My documentation practice now includes:

Decision logs: Tracking what was decided, by whom, and based on what information
Assumption registers: Explicitly noting what we’re taking as given
RAID logs: Risks, Assumptions, Issues, Dependencies
Meeting notes: Sent within 24 hours with clear action items
Requirements traceability: Connecting delivered features to original requirements

The key is doing this without seeming defensive or bureaucratic. I position it as a service: "To make sure we’re aligned, I’ll send a quick summary of what we discussed and the decisions made."

Unwritten Rule 4️⃣: Document diligently but diplomatically. The goal isn’t to prove the client wrong but to ensure shared understanding.

Building Champions: Turning Clients into Advocates Who Request You by Name

The ultimate achievement in consulting isn’t completing a successful project—it’s creating client champions who specifically request you for future work.

Early in my career, I focused solely on technical delivery. Now I realise that champion-building is an intentional practice that runs parallel to delivery. Some of my most valuable client relationships began with difficult projects that we navigated together.

The client champion blueprint:

Find their personal win: Understand what success means for them individually, not just their department
Make them look good: Create materials they can share upward that showcase the value of the work
Transfer genuine expertise: Teach them things that enhance their standing in the organisation
Show vulnerability: Asking for their input creates investment in your success
Remember the human element: Acknowledge their pressures, celebrate their wins, respect their challenges

I had a client who went from sceptic to champion after I helped him prepare for a board presentation about our project. He later told me: "You’re the first consultant who seemed to care about my success, not just the project’s success."

The most powerful form of relationship building happens in the small moments: staying late to help with a deadline that isn’t technically your responsibility, sending an article relevant to their professional interests, or simply remembering details about their priorities.

Unwritten Rule 5️⃣: A client who likes you personally will forgive technical imperfections. A client who only respects your technical work will not forgive relationship missteps.

The Stakeholder Spectrum: Different Approaches for Different Roles

Not all client relationships require the same approach. I categorise stakeholders into five types, each needing a different relationship strategy:

The SponsorCares about: Business outcomes, ROI, reputation
Relationship approach: Strategic alignment, executive updates, big-picture focus
Communication style: Brief, business-focused, forward-looking
The GatekeeperCares about: Process adherence, risk management, governance
Relationship approach: Transparent compliance, early consultation, respect for protocols
Communication style: Formal, documented, comprehensive
The SMECares about: Technical accuracy, professional respect, being heard
Relationship approach: Genuine consultation, acknowledgment of expertise, peer-level discussion
Communication style: Technical depth, evidence-based, collaborative
The End UserCares about: Usability, practical benefits, minimal disruption
Relationship approach: Empathy, demonstration of benefits, responsiveness to feedback
Communication style: Concrete, benefit-focused, jargon-free
The ScepticCares about: Proof, precision, not being oversold
Relationship approach: Under-promise/over-deliver, factual evidence, respectful persistence
Communication style: Direct, substantive, honest about limitations

The most common mistake I see consultants make is using a one-size-fits-all approach to stakeholder management. The executive sponsor doesn’t need the same relationship as the technical lead, and treating them identically will undermine your effectiveness with both.

Unwritten Rule 6️⃣: Tailor your relationship approach to each stakeholder’s role, priorities, and communication style. What builds trust with one may erode it with another.

Navigating Client Politics Without Getting Burned

Client organisations are political environments, and as a consultant, you’ll inevitably be drawn into those politics. The challenge is navigating them without becoming a casualty of conflicts that predated your arrival.

I once joined a project where two client departments were engaged in a years-long turf war. Each tried to use our team to outmanoeuvre the other, placing us in an impossible position. We survived by establishing some crucial guidelines:

Maintain equidistance: Avoid being seen as aligned with any faction
Focus on organisational goals: Consistently reference the broader objectives that transcend departmental interests
Create neutral forums: Establish working sessions with clear, objective decision criteria
Document competing requirements: Acknowledge differing needs without judging their validity
Escalate thoughtfully: Know when and how to involve senior sponsors in resolving conflicts

The political savvy that matters most isn’t about manipulating situations, but about recognising the human dynamics at play and creating spaces where productive work can happen despite them.

Unwritten Rule 7️⃣: You can’t solve long-standing organisational politics, but you can create temporary truces around your project by focusing on shared goals.

Conclusion: Relationships Are Your Real Deliverable

Technical deliverables have a short shelf life. Systems get replaced, code gets rewritten, and designs get updated. But relationships endure.

The longer I consult, the more I recognise that my technical work is ultimately judged through the lens of the relationships I build. A flawlessly executed project with damaged relationships is a failure. A project that faces challenges but strengthens relationships often leads to more work and better outcomes in the long run.

Your technical reputation is built project by project, but your consulting reputation is built relationship by relationship. The former might get you assigned to projects; the latter will get you requested by name.

In the next post in this series, I’ll explore "Agile in the Real World: Beyond the Textbook"—the unwritten rules of making Agile methodologies work in environments that don’t match the ideal conditions described in training.

Until then, remember that in consulting, as in life, people rarely remember exactly what you did, but they always remember how you made them feel.

What relationship lessons have you learned the hard way in your consulting career? Share your experiences in the comments below!

Photo by Chris Liverani on Unsplash

The Unwritten Playbook: The Client Whisperer