Allan & Steve are the chubby founders of LessEverything. This is their blog, hear them rant, praise, give advice and talk about Just Stuff, Less Accounting, Lovd by Less, More Honey, Events, Less Memories, Code, Business, Design, Marketing
Be Wary of Time and Materials
written by Steven Bristol on May 7th, 2009
Be cautious when hiring a firm that charges by the hour (time and materials) rather than a fixed price. It is too easy to lose track of the budget and wind up paying A LOT more than the original estimate. Even the best firms, with the best intentions, can run into situations where things take longer than anticipated. There is no way around that risk if you are paying hourly. We have seen many projects come to us where the previous developers have used more money than they originally estimated to produce less functionality. Often, hourly goes so far over budget because it is too easy for the developer to say “we’re almost done” and be in that almost done phase for a long time. A good, trusting client will believe that for a long time, in for a penny in for a pound.
At Less we only charge hourly when we are taking over a project that someone else has started. For all new development we charge a fixed price. We have never gone over budget when the scope of the project has remained the same. Never. Not once. One way we achieve this is by breaking down large projects into two week iterations and having a fixed price on each iteration. Sometimes we’ll plan several iterations and price each one, changing the scope of each as needed when we get there. This way the client always knows where they are at and can plan their budget. After any iteration, the client can reassess our performance and decide to stick with us or walk away. By lowering project risk in this way, we build strong, trusting relationships with clients and have a much higher likelihood of project success.
I agree with the way you guys price out projects. If you’ve got to do time and materials for some reason however I’m a fan of including SLA’s with penalties if deliverables are not met on time with the severity depending on how far off schedule or off scope the deliverables are at the due date. Unfortunately writing in this protection and still providing for any type of flexibility to reassess deliverables is going to leave you with a complex contract.
Good advice overall. I do it both ways depending on the situation. Sometimes hourly is best, sometimes fixed is best. Each has their problems.
As you said the problem with hourly is that it can easily go out of budget. Providing detailed billing helps protect against that. Every little moment I spend on a project I document to the client. This provides them the evidence to hold me accountable for every moment I charge them which helps prevent things from going out of budget.
In some ways fixed can be more dangerous to the client (depending on the contractor). With a fixed price the client often doesn’t care about getting line items for every moment spent on their project. It is fixed so why should they care as long as you get it done right? The problem is that when a contractor is running up against their own internal time limit (because ultimately all projects are hourly internally) then a contractor may start taking short cuts to fit the project into the amount of time they have alloted to the project. The short cuts are often not visible to the client (at least initially) meaning the client isn’t really getting what they paid for but doesn’t know it. I’ve seen this happen countless times where I have had to come in an “fix up” a fixed bid project because contractor took short cuts that didn’t become apparent until after the contractor had all their money. The contractor insists that everything was done and doing something other than the short cuts would be out of scope. So the client is left with a product that doesn’t do everything they intended which means they have to either pay more to the dishonest contractor or go elsewhere and try their luck there.
The other problem with fixed bid projects is that it can be difficult to change the scope once the project has started. Changing scope means going back to the contract and pricing to adjust for the new scope.
My only point to all of this is to say that one or the another is not evil. They can both be used for good or evil. For me the keys are:
I agree with many of your points. But isn’t the real problem in the time and materials example you mention above the lack of an agile and iterative process?
It seems to me that time and materials billing should work very well if you capture and track progress as user stories and commit to short iterations (2 weeks or even just one week), after each of which you deliver a full vertical slice of the application (along with TDD and other best practices).
If you are using an agile process like that along with time and materials, there should not be any nasty surprises at the end. Each iteration, the customer knows exactly what they’re getting, while reserving maximum flexibility for scope changes along the way. All the other advantages you mention above still hold true, i.e. the customer can still reassess the situation after each iteration and either continue the working relationship or walk away.
But I’m curious to find out more about the exact process you are using. When you say that you are pricing out two-week iterations, what exactly do you mean? Are you estimating how much work you can accomplish during that period and charging the customer for two weeks worth of work, even if an iteration ends up taking longer (since your scope is fixed, the duration must be flexible)? What happens in the opposite case, if you overestimated a feature and you’re done after one instead of two weeks?
Intuitively, using time and materials billing + agile process (with fixed length rather than fixed scope for each iteration) still seems like a better solution for both parties, although I am intrigued by your approach.