Comment by porker | Hacker News Reader

Comment by porker | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com