Ask HN: How do you sell sprints to clients? | Hacker News Reader

Ask HN: How do you sell sprints to clients?

5 pointsporker2 comments

I'm freelance and have a lot of clients who want a fixed quote before embarking on a project. It's not a happy position for anyone - what they want always changes/isn't specified tightly enough; I need more money and they feel hard done by.

From my perspective, a fixed length of time and a prioritised wishlist from the client is the best outcome; it allows me to iterate over features until the client gets what they want, and it ensures I get paid for my time.

But it isn't great for the client because they don't know how much will get done, and (in spite of testimonials, reviews etc) are left feeling I should've finished the wishlist (no matter what expectations I set at the start - "Nice wishlist but only the first 3 are likely to get done, assuming minor changes").

Others can't even start this approach because to get budget approval they have to have a fixed price up-front which is signed-off.

How do you handle this? Is there a "Third Way" that works for all parties?

The answer is twofold:

1. There must be a reason that the clients expect that a fixed quote must be possible. If you are developing something that is already existing, it is very very difficult to convince that you really can't know how much budget is needed and it is a project with extreme unknowns. For example if you are building a pretty standard CRUD application, the client will insist that you will offer a fixed budget within a range or margin.

This can mean that you haven't standardised your product or service enough to be able to offer it in a standardised way. The client intuitively does demand a standard product because they feel this is already existing and don't want you to reinvent the wheel on their costs.

2. The development is really custom and complex, it can't be standardised in to a product or service. But the client just doesn't want to pay for it because it is expensive. Then you must really check whether the investment is worth it. (The Product Owner is actually responsible for this part.) Often the client has just a lousy business plan and the only way that their business will workout is if they get the software almost for free. This is not a situation that you want to be involved. Sometimes the business plan seems realistic and you can point out easily that the return on investment is worth it. Sometimes the client just doesn't have the money and require indirectly that you invest in it. (Then you can just make that explicit and give an answer that you are interested in or not. But never let assumptions or vagueness get in the way.)

Trying to do sprints without a strong product owner will cause a lot of trouble. I would advise that you don't take that responsibility by just trying to fill the vacuum.

So, there is a question that you should ask before the sprint versus fixed price negotiations. If it is clear that it is a innovation driven project and predictive methods will not work, you can work something out for the pricing like a pre-determined sprint price.

Thanks, that is a really good answer.

Regarding point 1), it's difficult to spend enough time up-front working through requirements to estimate, reviewing with client etc - for 2-3 days work can take 4+ hours. Heck, I won't know all unknowns until I program it, and often feel I might as well have built a prototype in this time (and saved the client half a day's money). Plus, if the work doesn't come off, that's a lot of time wasted.

The project that triggered this post is making a 7-screen online copy of a 6-page paper form. It should be straightforward, and as with many of these projects the client expects it to be cheap because it's "simple" - so we have a bad expectation to start with. I made a couple of judgement errors when quoting (mostly on conditional logic, which the paper form didn't include: dynamic add/remove of form rows), and now when viewing the first draft the client's decided that additional show/hide regions and conditional validation are required, and some fields to be modified from the paper form because "They'll be better like that". We'd had a face to face meeting before the project began so I thought I knew what the client wanted and the client was happy with what I proposed...

I do think the fault is mine. I'm sick of my projects ending up with bad feeling on both sides. You are spot on that some clients just don't want to pay for the work involved; I have one that quibbles over every 20 minute period on the invoice, saying it could be done quicker. But then when the quote is squeezed to give a good fixed-price, a lot of modifications/changes get left out, and the client isn't happy then.

Reply on news.ycombinator.com