The human side of project leadership #005

The longer the project, the more personal it gets

Featuring Nick Cobb, Digital PM Summit 2026 Speaker

I once worked on a project that lasted five years. I realize that sounds ridiculous, because it was.

Over those five years, people came and went on the client side. New stakeholders showed up with new ideas and new expectations. Decisions we had made months or even years earlier suddenly had to be explained again. Sometimes we had to revisit them entirely because the new person wanted to put their stamp on the project.

Eventually, we started keeping a history document that tracked major decisions, why we made them, and what they affected. We even changed the language in our contracts so that if a major stakeholder changed, we could pause the project and account for the time it took to onboard them.

That project taught me a lot. Some lessons I probably could have done without. But one of the biggest was that the longer you work with a client, the less your job is simply about managing their project. You're managing a relationship.

That came rushing back to me when I talked with Nick Cobb for this installment of The Human Side of Project Leadership. Nick leads client and project success at Blend Interactive, where projects can easily run for a year or longer. His Digital PM Summit session, The Long Haul: How to Manage Delivery and the Relationship on Enterprise Web Projects, is about what happens to the PM role when you're in it with a client for that long.

What I like about this topic is that it's something a lot of us learn by doing. We're taught how to manage scope, how to build a plan, track a budget, document a risk, and run a status meeting. We're not necessarily taught what to do when you've been working with the same client for nine months, and everyone is tired. Because month nine is very different from month one.

At the beginning of a project, everyone is paying attention. There's energy around the work. People show up to meetings. The possibilities still feel exciting. Then real life happens.

Someone leaves the client team. Another person gets pulled into something more important. Your main stakeholder misses three meetings. The project team changes. Development takes longer than expected. Launch starts looming. A request that seemed small three months ago suddenly matters quite a bit.

Nick used the term "relationship drift" to describe what can happen along the way, and I really like it because drift usually isn't dramatic. Nobody announces that the relationship is starting to fall apart. You just slowly get a little further away from one another.

He told me about a project where the primary client stakeholder left only a few months into the engagement. The client's team changed, and Blend went through several PM changes of its own. Looking back, Nick could see the signals. At the time, they were just trying to keep the project moving. Eventually, the relationship fractured, and the client left after launch.

I've been there. Maybe not with exactly the same circumstances, but I know what it feels like to be so focused on getting the work done that you don't immediately recognize what's happening around the work. That's where the PM role gets complicated.

At some point you're wearing two hats. You're responsible for delivering the project, but you're also one of the people responsible for the client's experience of the project. Sometimes those responsibilities work beautifully together. Sometimes they absolutely do not.

Scope is probably the easiest example. If you're working on a fixed-cost project and the client asks for something that isn't included, your responsibility to the project tells you to protect the scope. Your relationship brain might be telling you that you don't want to make every conversation about money or say no to someone you're trying to build trust with.

And this is where I think PMs can get themselves into trouble.

Being a good client partner doesn't mean keeping the client happy all the time. I've coached enough PMs to know how difficult that can be to accept, particularly if you're someone who genuinely cares about the people you're working with.

Sometimes being a good partner means saying the thing they don't particularly want to hear. It means explaining the impact of a decision, reminding someone of an agreement, saying that something can't happen without moving something else. It means being patient and empathetic while also standing your ground, which can ve really, really challenging!

Nick brought up my "lovable hardass" principle during our conversation, which made me laugh, but it fits here. You need both sides of it. If you're all hardass, you're probably miserable to work with. If you're all lovable, you might end up agreeing to everything and making your team miserable instead. Neither is particularly human-centered.

The other thing Nick said that stuck with me was much simpler: Don't do it alone.

When I asked what he'd tell someone heading into their first big, long enterprise project, he talked about having someone there who understands what you're going through. It doesn't necessarily have to be your boss or even another PM. Early in his career, Nick found that person in a lead developer he worked with. I immediately knew what he meant.

The hardest projects I've worked on have also created some of the strongest working relationships I've had. There's something about being in the shit together that does that. You need people who can help you solve the problem, but you also occasionally need someone who can listen while you say, "What the hell is happening here?"

Every long project will test you. It will test your process and your communication skills, obviously. But it will also test your patience, judgment, confidence, and ability to recover when things don't go as planned.

And you will make mistakes. Nick has. I definitely have.nIn fact, a pretty significant portion of my project management career could probably be described as doing something, realizing there was a better way to do it, and then making sure I never did it that way again.

That's why I'm looking forward to Nick's session at the Digital PM Summit. There are plenty of places to learn how to manage a project. I'm much more interested in talking about what it actually feels like to manage one, especially when you've been doing it with the same group of people for a very long time.

T L ; D R - The longer a project runs, the more the PM ends up managing more than scope, timelines, and budgets. My conversation with Nick Cobb got into what happens when you’re also responsible for trust, client relationships, and all of the messy human stuff that comes with working together for a very long time.