The Definitive Guide to Project Billing(planscope.io)
planscope.io
The Definitive Guide to Project Billing
http://planscope.io/blog/the-definitive-guide-to-project-billing/
5 comments
This is the most lucrative thing that's been posted to HN in the last several weeks, which of course means it's going to languish. :)
Hey tptacek, I read some of your previous posts regarding consulting and I must say they were very useful. Do you have any tips for myself who is running a 18-month old consulting firm that does mobile development work for businesses, and used to charge per project (and got burnt badly), and now is moving towards charging weekly/ per feature?
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.
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.
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?
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.
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?"
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.
An excellent article!
This is a process that I've been thinking through increasingly after having evaluated years of custom development work, the last two in custom Ruby on Rails development work.
One would think hourly pricing would help manage scope, but every single project has a project budget. Every project starts out with a thousand "how long will ____ take?", "How long will this other ____ take?", "It's easy to do _____, right?", etc.
Getting clients to see the value of the discovery/requirements gathering/story carding phase of the work is paramount. Too many times, people expect that to be part of the "free" pre-sales consulting that goes into the proposal writing process rather than as a key part of the software development activities.
For someone who is looking for a more narrative (parable) form of these ideas, Mike McDerment (of Freshbooks) has published a free e-book on value-based vs hourly pricing - http://www.freshbooks.com/blog/2013/06/12/breakingthetimebar....
This is a process that I've been thinking through increasingly after having evaluated years of custom development work, the last two in custom Ruby on Rails development work.
One would think hourly pricing would help manage scope, but every single project has a project budget. Every project starts out with a thousand "how long will ____ take?", "How long will this other ____ take?", "It's easy to do _____, right?", etc.
Getting clients to see the value of the discovery/requirements gathering/story carding phase of the work is paramount. Too many times, people expect that to be part of the "free" pre-sales consulting that goes into the proposal writing process rather than as a key part of the software development activities.
For someone who is looking for a more narrative (parable) form of these ideas, Mike McDerment (of Freshbooks) has published a free e-book on value-based vs hourly pricing - http://www.freshbooks.com/blog/2013/06/12/breakingthetimebar....
What do you do for services where you are needed once, maybe twice a month, for 1-3 hours at a time?
Retainer:)
I contract out to a few hedge funds for writing trading systems. I have my main product and roll updates out every few months.
if a fund wants a couple of hours a month they pay a flat fee per month to me. If the time needed is less than 5 hours then no problem. If its more then I bill on a daily basis.
Rate depends on who gets final ownership of the code, ie can I resell it to another fund or is it theirs.
I contract out to a few hedge funds for writing trading systems. I have my main product and roll updates out every few months.
if a fund wants a couple of hours a month they pay a flat fee per month to me. If the time needed is less than 5 hours then no problem. If its more then I bill on a daily basis.
Rate depends on who gets final ownership of the code, ie can I resell it to another fund or is it theirs.
Sell the value of your service, not the amount of time. "Making sure the server is secure, up-to-date and always online" > "1 hour a month".
I get in that situation, but it can be very irregular. e.g., 20 minutes once off then nothing. Or 10 hours, then nothing for four months, then two hours.
Further, it's hard to break from this with existing clients to a retainer model when they know that most months they won't be asking for help.
Further, it's hard to break from this with existing clients to a retainer model when they know that most months they won't be asking for help.
A monthly retainer, though try not to sell it based on the amount of time they reserve of yours each month.
You bill by sprint (2 weeks; expectation of full-time), planning for a set of deliverables with approximate story weight among them. This gives the client something concrete that you're building towards and gives me incentive to actually produce value and not get mired in non-value-producing things like tweaking styles or excessively mulling over long-term architecture and deployment. Also, it has sufficient room for the inevitable adjustment to scope mid-sprint (although I found this was rare; perhaps 1/4 of my sprints experienced this). We'd just estimate the new work that gets introduced and pick off an equally weighted task, no fuss.
My clients found the level of certainty reassuring, and the bug flow of deliverables at the sprint pace was very satisfying, especially to clients who are used to project-scale deliverables. I also found it was conducive to producing better overall software. The sprints made us work together to constrain our thinking to the most valuable things to do in that time horizon. For my specific client base, it left us flexibility to adjust to acquisitions, major project-level scope changes, and financial circumstances, which typically only happened at a biweekly sprint pace.