“Our client just gave us notice that they will be rolling off more than 50 people immediately. Also, they believe we’ve mishandled the engagement so badly that we should pay them $700k.”

This update from one of my client partners is the kind you feel in your stomach. It is pretty much the worst possible news you can hear when you’re running a services firm.

At the time, Nexient had around 250 employees on billable work. For 50+ of them to roll off was catastrophic. They’d most likely move to our bench which typically ran at around 5-7% of our revenue. This development would increase it to 15-20% and finding new billable work for them all could take months. Our model was built to have 5-7% invested to support our bench and a large increase would mean the firm would start to lose money. Also, this was our second largest client at that time and it was showing all the signs of going away for good. We had a huge problem.

Uncovering the causes of the project failure

When these rare but major failures happened we would dig in and undertake a detailed retrospective of the project and what had gone wrong. In this case, our client was a large manufacturing company with a structure where the business people were in one group and the IT people were in another. They even operated under a different name to the main company. Project management was handled by the IT group, but ultimately success or failure was determined by the business group. We worked for and took direction from the IT group, but if the business group was unhappy, we’d failed.

During the retrospective, I learned that we had been given warning signs, but hadn't taken sufficient action to resolve them as they came up. Our team was well aware of the project’s weaknesses internally:

• The business leaders and the IT leaders weren’t fully aligned. The business leaders weren’t happy with the overall project direction and timeline. The IT leaders didn’t agree.
• There were fundamental technical issues that we had raised with the IT team. The IT team didn’t raise these issues with the business team, nor make our suggested changes as these would’ve caused schedule and budget overruns.
• The overall testing approach didn’t eliminate the largest architectural and integration risks early in the project. We suspected there were issues with the approach (and told them as much), but our suspicions weren’t validated until we got to the last stages of the project and did end-to-end integration testing.

The importance of escalating issues

Every step of the way, one thing was consistent. We didn’t push the issues hard enough to the right people (the business leaders). This is really hard to do. It takes careful handling to ensure you don’t bother your client to the point they don’t want to work with you anymore. But by not sending our concerns up the line, or stopping work to make a point, we slowly became responsible for the issues, and found ourselves in a much worse situation down the road.

As often happens, the client did a reorganization late in the project and a new IT leader took the program’s helm. It’s common for new clients to try and stand out to their leadership by making a statement. This can be by finding budget savings in the middle of a project, or firing a supplier in favor of one they may already have a trusted relationship with. Being new to the project and not responsible for the issues so far, and having no prior ties to us, meant they were able to broadcast the weaknesses and find someone to pin the issues on. They also needed to find some funds to add to the budget to help address the problem. We had put ourselves in a vulnerable position and were the obvious target. Despite having raised the issues, but not making a big enough deal of them, we were now seen as the source of the problem.

The difficult path to resolution

I got involved at this point to see how we could find a way forward. I always start with ascertaining how we can make things right for our client. I would typically offer work at a discount, or even for free, to bring the program back on track, but at this point the client wasn’t interested in either. And they still wanted us to pay them $700k, so we had to bring out the statement of work and contract. If you ever have to resort to looking at the contract, the project and client relationship have definitely failed. This contract made it clear that we worked at the direction of the client (the IT group). This gave us some leverage, but they still had an expectation that the project would be delivered successfully, so we had to find a middle ground.

I offered to settle with them for half of the amount they requested - hardly the $700k they were demanding but I suspected they were not interested in litigation and $700k was probably a settlement opener anyway. I also countered on the condition they’d set up a meeting for me with their CIO. This was a way to try to make lemonade out of the lemons we currently had. It was a long shot that the meeting would lead to any kind of further work but it was worth a try. We were likely going to pay that amount either way. The meeting with the CIO was convivial (all things considered) and I left feeling like there might be a chance we’d be able to keep them as a client. Over time however, it became clear that this meeting was simply to fulfill a condition of settlement. We had lost them.

Key takeaways from the experience

In professional services, losing a client can be a real kick in the guts. What I learned from this experience:

1. In consulting with large organizations, always build a relationship with the most senior client when the project is going well. You can then work with them directly if or when things become challenging.
2. Simply raising a potentially catastrophic issue isn’t enough. You need to ensure things actually change. Take action if the client won’t address the issue. You can tell the client that you’ll have your team stop work on a certain date if you can’t reach a path forward. This is an extreme tactic, but sometimes the only option to avoid catastrophe. I’ve seen many projects fail as a result of a team not getting leadership to change directions, despite all the warning signs.
3. Bring in fresh eyes to every project. Have your client leaders help each other by doing a quality assurance check on each other’s large projects. If they’re experienced enough, they will be able to spot these critical issues in a project quickly. When you are involved in the day-to-day of a project, it’s easy to think you’ll get the client to resolve an issue in time, but timelines have a way of slipping. Outside eyes can help you see the big picture quickly.

A few final thoughts

After this experience I also ensured that I became more involved in all of our client projects. Client partners started to report to me directly so I could understand their projects and make sure they were on track. I also appointed a Chief Delivery Officer who also ensured our projects went well. Ultimately, his involvement allowed us to scale the company with quality for a number of years.