How do I count my days when quoting a customer?
1 comments
I think the point of billing by day (or week) is because the project is unclear. They can change the spec as much as they want, but they're paying you for all your time changing it.
The time estimation is for fixed bid contracts, so you can figure out what your effective rate is and how much time you can't devote to other clients. It's not for them to put a cap, e.g. $1000 a day up to 30 days, so we're capping at $30k. If you completed in 25 days, they would pay $5k less. If you complete in 35 days, you only get paid for 30. There's no upside in that for you, only for them.
A friend of mine handled this by giving a rough estimate of how many days he thought it was going to take and then giving them the option of a fixed price contract, e.g. "I think it's going to be X hours at $Y/hour, though it could run longer. If you want this for a fixed price, it's going to be 2.5 times X times Y, no more, no less". It's then up to the client to make the risk assessment of high fixed cost, or open ended cost.
But really it just comes down to your estimation, and if it's not clear what to estimate it by, then you should probably be billing for unit of time rather than fixed.
The time estimation is for fixed bid contracts, so you can figure out what your effective rate is and how much time you can't devote to other clients. It's not for them to put a cap, e.g. $1000 a day up to 30 days, so we're capping at $30k. If you completed in 25 days, they would pay $5k less. If you complete in 35 days, you only get paid for 30. There's no upside in that for you, only for them.
A friend of mine handled this by giving a rough estimate of how many days he thought it was going to take and then giving them the option of a fixed price contract, e.g. "I think it's going to be X hours at $Y/hour, though it could run longer. If you want this for a fixed price, it's going to be 2.5 times X times Y, no more, no less". It's then up to the client to make the risk assessment of high fixed cost, or open ended cost.
But really it just comes down to your estimation, and if it's not clear what to estimate it by, then you should probably be billing for unit of time rather than fixed.
I am a developer in the the company but work a lot with our sales guy. So while the area is interesting to me I am incredibly ignorant of it.
Your suggestion crystallizes an approach I was considering.
My lurking on HN is part of my education in such matters. Thanks Caw for taking the time to answer my first question.
Your suggestion crystallizes an approach I was considering.
My lurking on HN is part of my education in such matters. Thanks Caw for taking the time to answer my first question.
How do other software companies with complex offerings initially bill out projects when the day count is unclear?
E.g. can’t really do a fixed price contact as the day is count unknown but the client wants some form of fixed price contract so they are not writing a blank cheque.
How do large IT projects with indeterminable day counts get signed off/across the line?