I'm not sure if you're missing something obvious ..this is HARD, I totally know what you're feeling like.

I was talking with a buddy other day ago (also a consultant); I was grumbling about how clients have "urgent" projects and then proceed to sit on the project proposal for a few weeks...

His response went something like this: "look, there are reason's why consultants are called in to work projects - and those reasons are not that they are well organized, well equipped, well funded ..etc etc". Oddly, that made me feel a bit better.

You might also just have the wrong clients. I've found moving upmarket reduces stinginess.

It may also be you just have trouble saying no to your clients and need to work on setting boundaries with them. You may not need them as much as you think.

That smells like a market segmentation effect where you're working in a market segment where normal is "part of how consultants make us money is by reducing their consulting fees." That's common, but not universal. The solution usually better clients. Some you will have to find (and finding good clients is harder than finding bad clients). But some existing "bad clients" will upgrade because of the relationship with you...good clients value the relationship more than price. Clients who prioritize price assume that consultants are fungible to a large degree.

You come up with the SOW and say: "This will take X months provided there are no surprises or delays, at a rate of $Y per month."

> My clients want fixed price so the risk is stacked on me...

The risk should be spread evenly. If you're bearing all the risk then it's not a good relationship.

I have done everything from formal documentation of changes, requiring pricing and sign-off for every variation, to vaguer schemes.

The change request system sucks; it loses sight of why we're building the software and turns into a war of attrition.

The issue is always they say the spec is open to interpretation and they meant this, or they expect it to work this way (which is slightly different now they see it, but in scope because every single interaction can't be specified in advance). And either way they see no reason to pay.

So it ends in arguing and bad feeling; the client has an expectation that's not met without paying more and feels it's my fault, that they're paying when they shouldn't. I've lost time and much emotional energy.

I have gone as far as to have a "What's not included" section in every contract which helps, and that if it's not mentioned specifically then to assume it's not included; but it's a non-ideal situation.

Back when I did some freelancing gigs, the general advice I got was to spec a high level, general proposal which included all the client's requirements. Broadly. Then decide on iterables, with the spec (and timeline and effort and payment) for each iterable being done prior to commencing work on it. The key being to have a working system after each update. Sound familar ;D

The client's risk investment in you not completing the project (and them being left with some obscure code and no system) is minimised. Your risk is minimized as the client actually gets to update requirements at each iteration and you get to charge depending on implementation details for those changes. And if they feel you are taking them for a ride, they have a conpleted system up to that point in time, so have the option of looking at other developers. Which also allows you to bail as well without dropping the client with an incomplete project if its not worth it continuing.

My experiences like that went well - frequent communication kept the client informed of progress, they were able to manage adjustments (cost and time to implement), and at the end of each iterable they were left with a working system (even if rudimentary in the early versions) which they could build off of things went south.

I usually got paid more out of those, and ended up doing more work for them because of the relationship built.

> Back when I did some freelancing gigs, the general advice I got was to spec a high level, general proposal which included all the client's requirements. Broadly. Then decide on iterables, with the spec (and timeline and effort and payment) for each iterable being done prior to commencing work on it. The key being to have a working system after each update. Sound familar ;D

This is exactly how I want to work! The pushback I get is that the company's board of directors won't sign off on a project where the total cost isn't known.

I have explained all in your third paragraph, and even when the manager/CTO/CEO 'gets' this, the board don't. Because it's beyond their understanding as non-technical, and sounds like being taken for a ride (and I get it; if my garage did this, I would expect I was being fleeced).

This is what I need to break-through.

Clients don't like it as much of course, but the we can do is convince them that it fits the way that everyone works better -- nobody knows exactly what they want up front, and if they do, then they're wrong because as soon as they get to use the thing the never existed before, they'll discover things that don't feel right and they'll want to change them.

But working (and billing) in weekly Sprints seems to work very well once you've convinced your client that the framework is the right way to do it. Client want a quote, but we tell them we can't really give them any sort of estimate until we see how they work (with us). So, a two week trial period is often a good way to get that going.

I like the idea of a trial period. Get them on-board with low risk to them. As this pattern of working is exactly what I want but can't get clients to do (see my reply to your sibling commenter).

A difficulty is they invariably say the last agency/project did fixed price, so do any others they're talking to, so even if your results are good why aren't you.

They don't feel safe, and it's that safety I need to give back to them.