Hacker News Reader

> It feels like I am missing something obvious

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.

Ah, yes, the "hurry up and wait!" projects. If it makes you feel better, my 9-5 for the man is full of them too. Working all weekend to come in on Monday and find out it was all in vein is no fun.

You can somewhat combat that hurry up and wait attitude by making yourself feel more scarce. I typically say something along the lines of getting booked often and quickly so I can’t make any promises on being available after one week. This puts some pressure on them to respond within a week. In most cases if I haven’t heard back in 2-3 days they are gone for good.

The way I've seen a large and successful agency handle fixed bid projects was to write very detailed waterfall requirements and attach a price to that. Any scope creep meant new work with new requirements and a new price tag. The key was to break the project into smaller phases and price each phase. The detailed requirements are a contract between the two parties. They have dedicated product managers help the client determine what they want and come up with requirements.

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.

I freelanced for a couple years, and that was how I always did it. The contract spelled out exactly what functionality was included, and that was priced on its own. I often did projects where it was assumed that the completion of one contract would immediately start a new one, but that new one was also similarly defined and priced. This enabled iterative building out of a system while giving the client the ability to judge value of each piece. I usually focused on systems that I could define a good ROI for (replacements for existing systems with high maintenance costs or requiring lots of man-hours to operate, etc) because it's pretty easy to sell almost anything to a business if you can show them that within 2 years it will have paid for itself.

When I added 30-50% to the prices, I didn't win the jobs.

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.

Have you tried doing a monthly retainer rate?

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.

The reason I did weekly vs monthly pricing is simply because it breaks down to a "smaller" amount, visually ;) But yeah.. in essence you are just asking for a monthly retainer. Also, with weekly you don't need to worry about collecting as much in case of nonpayment, at most you'll lose a week's worth of pay.

What is your change request process?

> What is your change request process?

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.

Are you not maybe specifying too much too early on?

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.

> Are you not maybe specifying too much too early on?

> 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.

Ya, fair enough. It sounds like you've exhausted the paths that every waterfall developer exhausts before moving on to some kind of agile framework (ex. Scrum).

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.

> 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.