Hacker News Reader

Comment by msrpotus | Hacker News Reader

How do other people who bill on a project basis deal with changing requirements? I generally do just a flat fee (unless the scope is really unclear) but then if a client changes their mind about a feature, it leaves me in an uncomfortable situation. If it's a small change, I'm generally willing to do it for free but those small changes can add up pretty quickly.

View on HN

I'm trying bill by feature - that way the client can adjust what they have next, very much like agile stories, but with two advantages - I am not promising to work a 40 hour week but to deliver a feature. Takes me 4 hours I'm quids in, takes me 40 hours my estimate was perfect, more than that - c'est la vie.

Secondly I get to focus on a business metric. Delivering software is boring. Delivering a report showing how much their kPI went up is fun.

This has the advantage of shifting clients from asking the question "how much will this person cost me?" to "how much will this person make me?", too.

Yes, but you have to keep banging on about measurable KPIs - the obvious ones (visits, revenue) cannot be shoehorned into everything. Time to create new campaign, speed of data entry, lead generation, speed of response, all things you can measure. But the client has to be excited about them.

Time to create new campaign

Do you mind expanding on this a little? What sort of orgs are you working with for which this is a KPI?

Well, you want to be flexible and accommodating, but you want to cover yourself from scope creep and you don't want to set the precedent that they can change anything whenever they want. I would probably do small changes for free, but call them out as exceptions, like "Sure, I think we can slip this change in under the radar, without affecting the project timeline!"

tptacek posted a great line the other day which I stole for my personal use: "I am happy to do whatever you'd like and make whatever changes you'd like but I need to remind you that we have a fixed schedule for this project". This line concerns scheduling, but I think it could easily be adapted to deal with scope and changes.

Can you elaborate more on using that line? The purpose of using that as I read it is to say "Yes, I can attempt to implement that new/extra feature, but if I am unable to do so within the original project schedule, there will be an extra fee for my time." Is that the intent?

Here is the original context: https://news.ycombinator.com/item?id=3710748

The original meaning was, "You call the shots, but if you add a bunch of changes, we're going to slip on the schedule."

What I meant was that you could probably use a similar line, to the effect of, "I'm happy to change this to do X instead of Y, but since that's a rather major change, I may need to send you a revised quote for the feature. Would you like me to do that, or maybe do Y', which should meet most of your needs for now?"

I take the per project cost, divide it by the amount of time it was supposed to take before all the new requirements.. that gives an estimated-agreed-on hourly rate. I then use that hourly rate to discuss new features.

Reply on news.ycombinator.com