A project only exists in the story about it. Make it a good story.

— #ProjectManagementTweet, Himanshu Jhamb & Guy Ralfe (2010)

“You look like a nice person. But no one can tell that you carry a knife behind your back.”

That was how my counterpart greeted me when I walked into his office. No handshake, no coffee — just that. I’d flown across the country to visit a client whose project was falling apart, and I remember standing there thinking: this is going to be harder than I thought.

The Setup

It was 2005, and we had a staff augmentation arrangement with a client — our engineers working onsite, embedded in their team, sharing their office and their daily routines. On paper it seemed straightforward. In practice, it had quietly become a mess.

Over several weeks, I’d noticed that no matter how hard my team worked, they kept missing milestones. I knew these people — I knew what they were capable of — and the numbers didn’t add up. So I spoke with them directly, and what came back was telling: the requirements kept changing. Client team members were having informal conversations in hallways and by the water cooler, agreeing on adjustments to scope, and their Project Manager — I’ll call him JD — was faithfully updating the plan each time. Every individual change seemed reasonable on its own. Collectively, they made it impossible for my team to hit any target, because the targets were always moving. From where the client’s stakeholders sat, though, it just looked like a vendor team that couldn’t deliver.

The Mistake

I could see exactly what was happening, and I decided to address it — directly, in a virtual meeting, in front of JD’s bosses.

I was right about the problem. I was wrong about almost everything else. Calling it out that way didn’t solve the requirements issue. What it did was humiliate JD in front of the people whose opinion mattered most to him, and in doing so, handed him a story about me that was simple, clear, and very hard to dislodge: I was the enemy. He stopped cooperating, threatened to cancel the project and end our engagement entirely, and what had been a frustrating operational problem became something genuinely precarious.

The Intervention

I asked my manager if I could visit the client in person. When I arrived, JD received me with a cold civility that was almost harder to take than outright hostility — and opened with that knife line. He wasn’t wrong. I’d earned it.

I made a decision not to walk into the team meeting we’d scheduled. No agenda item was going to matter while he’d already decided we were on opposite sides. Instead, I asked if we could talk privately — just the two of us.

We sat together for two hours. I didn’t defend my team’s record or relitigate the requirements issue or show up with a recovery plan designed to demonstrate I had things under control. I asked him one question:

“What is it that I can do to help you succeed in this project — and beyond?”

The project that had been days from cancellation was delivered, six to nine months later, as a genuine joint effort. That question was the turning point.

What I Took Away

Looking back, this story left me with two things I’ve never forgotten.

The first is specific to staff augmentation engagements, and it’s a trap I’ve watched teams fall into many times since. When your people are embedded with a client — sharing the same physical space, the same daily rhythms — they naturally become agreeable. They want to be liked, they’re surrounded by client staff all day, and the social cost of pushing back on an informal request feels much higher than just saying yes. That instinct is understandable, but it’s dangerous. In a staff-aug arrangement, scope discipline actually needs more attention, not less, because the informal pressure to accommodate is constant and almost invisible to anyone reviewing the project from a distance.

The second lesson is more universal. Every professional — regardless of how senior, how experienced, how outwardly confident — cares about how they appear in front of their bosses. It’s not vanity; it’s a deeply human thing. When I called JD out in that meeting, I threatened the thing he valued most. When I asked what I could do to help him succeed, I was offering to protect it instead. That’s what shifted the dynamic — not a better plan, not a governance framework, not an escalation process. A single question that put his success at the centre rather than mine.

Technical problems are almost always fixable. Story problems are the ones that kill projects.

If your technology programme is stuck and you suspect the issue isn’t purely technical, I’m happy to have that conversation. Sometimes an outside perspective is the fastest way to see which story needs changing — and how.