What is a good way to handle correction loops and clients which delay or deny project acceptance in fixed-price projects?

Question

As I have been into business for a long time now I know that this is one of a real freelance nightmare (maybe also for companies, but especially for freelancers).

It can be even worse in case that you made the mistake to agree on getting your money after the project is finished as your client literally has your balls in his hands (luckily I do not make any of those mistakes any more, but when I was starting I sometimes was silly enough to accept a lot of stupid conditions).

So as I was looking how other companies handle it I have seen the following strategies:

1) The project is done when the project is done

That means you work until the customer accepts the result of the project.

Problem: Really nice. For your client. But in my personal experience definitely the worst way to go for a freelancer. You might work extremely long for a project which you have calculated to require much less effort.

2) The project is done when the project is done, but efforts (in time) which exceed the original plan are charged afterwards

Sure this is great as long as you do not need the time for other projects.

Problem: Clients are very unlikely to accept higher expenses in a fixed-time project. They might get angry or even refuse to pay or threat to sue you.

3) Limit the number of correction loops to two (or three) in your terms of service

You finish the project and present it, the customer makes a list of required changes, you implement the changes, you present again, there is a last list of changes and after that there is no more right of the client to complain

Problem: The project might be unfinished and the customer will complain heavily

4) After your first project presentation you listen for change requests and document and implement them, but the clients' chance for new change requests is gone after that

In the second presentation only change requests for the last change requests are allowed. The number of correction loops is shrinking with any presentation as the list is significantly decreasing every time.

Problem: Clients usually complain afterwards about things they "forgot" or that the project is not exactly what they wanted now (still I think this is quite a good way to go).

Does anybody know even better ways to handle client denial or change requests in fixed price projects? If not for which reason would you recommend which of those method?

Answer 1

1

Deliverables and scope of work are set forth in a contract and the goal is to complete said deliverables to the client's satisfaction.

If the client is abusing this stance with continual, repetitive, possibly unwarranted, alterations, have a conversation with them. That's typically all that is required.

Quite honestly I have many of my clients often because I don't limit their ability to ask for corrections. By implementing something like "three rounds of alterations only" that leave the client feeling like if there's an error, you hold them hostage. never a good impression for a client.

I tell my clients....

Although I don't limit the number of revisions or changes you can request, I do ask that you be aware and conscious that every change requires additional time. My goal is to provide a solid product you can be proud to show off and not to invoice for every possible second of work possible. I do not want you feeling restrained or hesitant to voice a change concern merely because there may be some apprehension of additional costs incurred.

In some cases what may seem like a small change to you, may actually necessitate far deeper, more time-consuming, changes on my end.

If I feel, at some point, change requests are going above and beyond normal expectations, I will open a dialog with you regarding possible additional costs. However, I strive to avoid this.

Answer 2

So I do a combination of strategies 2 and 3. I outline the scope and everything included, set the number of revisions (usually 3), and then have a separate section that outlines what may incur additional fees on top of the set price for the project. In addition, I note that the revisions must be decreasing in complexity (as in, they can't just change everything on revision #3), and that requests outside of the project scope are billed hourly. This has worked well in my favor, and was only included in my contracts after suffering the dreaded scope creep and endless revision cycle a few times over the years. I bill for an hour of work for each subsequent revision, which encourages my clients to be more efficient with their change requests.

Having a fixed-price project doesn't mean you should have to work for free because your clients can't make up their minds. Time is money, even for flat-rate projects. As long as it's clearly explained in the contract and discussed upfront, nobody is going to have an issue with this. I've never had a client complain about the "additional fees" section of the contract, and I have something to point to if they start asking for more and more changes.

Answer 3

Some general Ruels:

1. Make sure you don´t fail late. Best case you can follow some kind of agile scheme where you have weekly meetings with the shareholder. You should be able to detect most of the obstacles early on.

2. Avoid scope creep: You always listen to change-requests, but you ´ll also have to adjust your offer. Ask the Client if he want to pay extra for that, omit some other feature or save it for a later date. Again, agile methodologies make it easier to react flexible to such requests.

3. Beware of hidden complexity. You should have a very clear understanding of the existing code base, the technology and the requested functionality. Outline clearly what you intend to do/change as annex of the contract. Also have provisions in the contract for the case the workload exceeds the estimated amount by a certain threshold (20% for example). You should be paid by the hour for this prep work, regardless if the take the resulting offer or not - maybe offer a discount if the take the offer in the end.

4. Add headroom. Fixed-price offers should always be made with your normal hourly rate + some headroom for unforeseen obstacles. Humans tend to estimate optimistically.

(And of course what should have been number 1. Don´t do fixed-price!)

Answer 4

Insist on a contract clause which makes sure that the client is not allowed to make use of your work before they paid you in full. How that clause would look depends on the kind of work. If you create something which is going to be sold or displayed in public, then transfer of copyright can be a good blocker.

That way a not-quite-finished product is a problem for both sides. When you don't deliver a satisfactory product, you don't get paid. When they refuse to call the product satisfactory, they keep wasting time without getting anything useful.

The worst case in this situation is if the client decides they don't need your work after all. To avoid not getting any compensation at all for your work, insist on a kill-fee in the contract. When the client fires you after you reached certain milestones but before the completion of the project, they need to pay at least a part of the negotiated payment.