When projects stop going to plan | Client-Side Project Leadership
I've spent the last few weeks getting a capital project moving again for a new client after it had been stalled for several months. I'm deliberately not going to go into the detail of the project itself because there are still some sensitive issues being worked through, but the experience has been a reminder of what I've seen repeatedly throughout my career: when a project gets into difficulty, the original plan is often no longer the thing that needs managing.
In this case, the problem was layered, the client felt stuck, communication between stakeholders had become difficult, and the original delivery arrangements weren't really suited to the circumstances that had developed. Once contractors had downed tools and left site, it became difficult even to get people to properly engage with the problem, let alone come up with a practical way forward.
It wasn't simply a case of the project being delayed, the arrangements that were supposed to deliver the outcome had completely stopped working, and there wasn't really anyone taking ownership of finding a way through it. Since taking on this engagement over the last few weeks the client has made a few comments that have stuck with me:
“How have you managed that?”
“I'm so glad things are moving forward again now.”
And my favourite:
“You don't give in, do you?”
I took that as a compliment, although I don't think what I've been doing is particularly complicated, there are a few things behind it that I think are worth explaining.
The first job is to understand what is actually stopping the project
When I get involved in a project that has stalled, my instinct isn't to immediately start adding more process or asking everyone for more reporting. I want to understand what is actually happening:
What has changed?
What is stopping the original plan from working?
Which problems are stopping progress and which are symptoms of any wider issue?
Who needs to make a decision?
Who needs to do something?
And most importantly, what can we do from here now?
That last question is important because it is very easy for a difficult project to become dominated by its history. People want to understand how the situation developed, who made which decision and what should have happened differently. And those questions have their place, but they don't necessarily get the project moving again. At some point you have to deal with the situation you have in front of you.
Experience helps, but it doesn't mean you always have the answer
In this case, having worked across a lot of different projects and situations meant I could get to grips with the problem relatively quickly and identify a potential workaround. It wasn't a guaranteed solution but an option that looked like it was worth testing. As it turned out, the first attempt didn't resolve the issue. It could have worked... I arrived, spot the answer and everything started working again... but that's not how all projects go.
Sometimes the first solution doesn't work. When that happens, I think there is an important distinction between persistence and stubbornness. Stubbornness is continuing with an approach because you've already committed to it. Persistence is remaining committed to the outcome while being prepared to change the approach. In this case, we looked at what had happened, adapted the approach and kept working towards the same outcome.
That is something I have found very useful throughout my life. I'm quite happy to keep pushing at a difficult problem, but I'm equally happy to accept that something hasn't worked and look at what needs to change.
A project can have responsibilities without anyone really owning the outcome
This is another thing that stood out to me, a project can have contracts, scopes, responsibilities, meetings and reporting structures, but that doesn't necessarily mean someone is actually thinking about the overall outcome and working out what needs to happen to achieve it. When everything is straightforward, that distinction isn't always obvious. Everyone does their part and the project progresses, it's when something unexpected happens, the gaps start to appear...
Who is connecting all the pieces?
Who is looking beyond their own particular responsibility?
Who is talking to the people who need to be involved?
Who is prepared to pick up a problem that doesn't fit neatly into an existing box and work out what to do with it?
That's where I think experienced client-side project leadership can make a real difference.
Sometimes the client needs someone between them and the problem - client-side project leadership
There is another aspect to this which I think can be overlooked, the client has a significant emotional and financial interest in the outcome. That's completely understandable, but it can make difficult situations harder to navigate, particularly when relationships have already become strained. As the client's representative, I'm in a slightly different position.
I have a responsibility to protect the client's interests and get the project moving, but I'm not the owner of the asset and I don't have the same history with the other parties involved. That gives me some useful distance, I can have difficult conversations without taking things personally. I can focus on what needs to happen rather than getting caught up in who was responsible for what history. I can keep talking to people when relationships have become difficult, while still being direct about what needs to change.
I'm not suggesting that an external person automatically solves these problems. They don't, but having someone whose job is to stay focused on the outcome, rather than becoming part of the history and politics of the situation, can be very useful.
Moving forward is often about a series of small decisions
The other thing I've been reminded of is that getting a stalled project moving doesn't necessarily involve one big breakthrough. It is usually a series of decisions and actions that gradually change the position. You understand the problem a little better, someone agrees to investigate something, a potential solution is developed, that solution doesn't quite work, you adapt it, another conversation happens, someone is prepared to re-engage, a practical route forward starts to emerge.
Individually, none of these things is particularly remarkable. Collectively, they change the position of the project. That is why I was particularly pleased when the client said:
“I'm so glad things are moving forward again now.”
That is ultimately what I'm trying to achieve when I get involved in something like this. Not more activity for the sake of activity, but a situation where the people involved can see a credible route forward and start making progress again.
Not every project needs the same kind of leadership
I've worked on enough different projects now to know that there isn't a single approach that works everywhere. A well-established project with a good team, clear responsibilities and few major uncertainties probably doesn't need someone coming in and changing everything. A project where the circumstances have changed, relationships have become difficult and the original delivery approach no longer works is different.
It needs someone who can understand the situation quickly, work with the people involved, make sensible decisions with imperfect information, find practical options and adapt when those options don't work. That doesn't necessarily mean having the answer to every problem, it means being prepared to engage with the problem and keep working towards the outcome. That's probably what the client meant when they said, “you don't give in, do you?”
I don't think the useful characteristic is simply persistence, it's being able to combine persistence with enough experience and pragmatism to recognise when you need to change direction. For me, that's a big part of good project leadership. The plan matters, but when circumstances change, the outcome matters more.
