
The Definitive Guide to Project Billing - jmduke
http://planscope.io/blog/the-definitive-guide-to-project-billing/
======
cairo140
I've enjoyed a, for lack of a better term, per-sprint billing cycle. It lies
somewhere between all of the techniques on the page and has worked the best
for my past client base (startups creating MVPs, companies that need
relatively stand-alone websites and services).

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.

------
tptacek
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. :)

~~~
penguin_gab
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?

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

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

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

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

~~~
jmduke
_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?

------
rietta
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...](http://www.freshbooks.com/blog/2013/06/12/breakingthetimebarrier/).

------
Paul_D_Santana
What do you do for services where you are needed once, maybe twice a month,
for 1-3 hours at a time?

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

