Have you ever had that hard to please customer on a project where every deliverable review is painful? I’m not referring to someone who combs through your functional design document for every missed period. I mean details must be discussed over and over again and as hard as you try, it’s very difficult to get a final signoff on a deliverable. And without that signoff, there is no payment.

Maybe they don’t want to pay… maybe they’re having a cash flow issue and they’re looking for an excuse to delay payment. That happens. But usually it’s something else. Either they’re just hard to please. Or they’re upset with something on the project and this is their place where they can exert some control over you. Maybe they’re just trying to make you twist in the wind.

I’ve taken over my share of projects in mid-stream where that seemed to be the case. Usually the scenario went like this: we had performed poorly, the project manager was replaced – by me, unfortunately – and the headache became mine. The sour taste in their mouth left them very skeptical of our ability to deliver and every deliverable, every bug fix, every milestone, was unbelievable painful. We had to prove ourselves over and over again through the rest of each engagement. I’m not saying it wasn’t justified, but getting signoff and payment was next to impossible. Have any of you experienced this type of situation before? If so, what did you do? How do you get the customer to come around? How do you get them to loosen their purse strings? Do they ever?

As for me and my team and my organization on those projects from my own experience and from similar issues that I’ve witnessed on colleagues’ projects, I’ve found that these four actions – when taken carefully, may prove beneficial. And when you’re pegged by your senior management to go in and ‘fix things’ and ‘get paid’, believe me, you’re looking for any possible resolution to the mess.

Cut the price

You may not have the authority to do this on your own, but cutting the price of an expensive deliverable for the project customer may get you over the hump. On one of my projects we had delivered a critical project document with mistakes in it three times. Bad oversight on my part… I can’t argue with that… and I made sure we peer reviewed everything from that point on, but cutting the price from $20,000 to $15,000 for that deliverable got me the signoff we needed. Better to lose $5,000 then to drag it out further and lose more.

Give away freebies

This is similar to cutting the price, but somewhat different. Maybe you’re sending your developers to the customer’s site to help get them through some difficult testing activities. Don’t charge the customer for the travel – or possibly don’t charge them for the work or the trip at all. If you’re trying to regain customer goodwill and compliance, then giving away some work for free may mean the difference between an easier-to-work-with customer and one that will make your life miserable for the rest of the engagement.

Have executive management go to the customer’s site to discuss

One project that I took over was in the middle of some endless break/fix testing as we were 95% on our way to deployment but we just couldn’t get over the hump with some final issue resolution. The issues that remained would not affect system functionality, but it was still painfully embarrassing and left the customer concerned that agreeing to signoff now would mean they would be left to resolve everything on their own. Our CEO went on site, and yes… cut the price (see above), and guaranteed that we would keep the team together and continue the fixes and testing post-deployment if they would agree to signoff and implementation. It worked…

Reach out for the best resources in the organization

This may help – but it will definitely break the project budget if that hasn’t already happened. If the project is visible enough and if the customer is important enough and if the dollars the customer is refusing to pay are high enough, reach out to your senior leadership and ask for whatever you need. Tell the customer you’re going to apply the best resources within the organization to get past the current issues. I did this on a project I had inherited. Once I had the resources pulled from other projects and secured on mine, the customer then came on site for two weeks of intensive – and expensive – work to get to the point of finally being able to signoff on the system. With the help of the top resources for two weeks, we resolved the system performance issues that remained to the point where the customer was ready to approve the system for implementation.