Writing software on a consulting basis can often be a losing proposition for developers or clients or both. There are too many things that can go wrong, and that ultimately translates into loss of time and money. The “15% rule” we’ve come up with is intended to create a win-win situation for both parties (or at least make it fair for everyone). Clients generally get what they want, and development shops make a fair profit. It’s not a perfect solution, but so far it seems to be working for us.
This may come as a surprise to some, but we make very little money selling software licenses. The vast majority of our revenue comes through consulting services–writing code for hire. Having now done this for several years, we’ve learned some hard lessons. On a few projects the lessons were so hard we actually lost money.
A few months ago I put together somewhat of a manifesto-type document intended to address the difficulties we’ve faced in developing software for clients. I’m pleased to say that it’s made a noticeable difference so far for us. My hope is that this blog entry will be read by others who develop software on a consulting basis, so that they can learn these lessons the easy way rather than the way we learned them.
What follows in this article is a summary of one of the main principles we now follow in developing software–the 15% rule. If you’d like, you’re welcome to read the full “Our Approach to Software Development” document.
For the impatient, the 15% rule goes like this…
Before undertaking a development project we create a statement of work (which acts as a contract and a specification) that outlines what we’ll do, how many hours it will require, and how much it will cost the client. As part of the contract we commit to invest up to the amount of time outlined in the document plus 15%. That is, if the statement of work says that the project will take us 100 hours to complete, we’ll spend up to 115 hours (but no more). As to where-fores and why-tos on how this works, read on.
Those that have developed software for hire know that the end product almost never ends up exactly as the client had pictured. There are invariably tweaks that will need to be made (that may or may not have been discussed up front) in order to get the thing to at least resemble what the client has in mind. And, yes, this can happen even if you spend hours upon hours fine tuning the specification to reflect the client’s wishes. Additionally, technical issues can crop up that weren’t anticipated by the programming team. In theory, the better the programming team the less likely this should be, but it doesn’t always end up that way (Microsoft’s Vista operating system is a sterling example). These two factors, among others, equate to the risk that is inherent in the project. Something isn’t going to go right, and that will almost always mean someone pays or loses more money than originally anticipated. The question is, who should be responsible to account for those extra dollars?
Up until relatively recently, we would shoulder almost all of the risk in our projects. If the app didn’t do what the client had in mind, or if unforeseen technical issues cropped up, it generally came out of our pockets. For the most part it wasn’t a huge problem, but always seemed to have at least some effect (the extreme cases obviously being when we lost money on a project).
This seems kind of unfair, doesn’t it? The risk inherent to the project isn’t necessarily the fault of either party. It’s just there. We didn’t put it there, and neither did the client. As such, it shouldn’t be the case that one party shoulders it all. That’s where the 15% rule comes in.
The 15% rule allows both parties to share the risk. By following this rule, we’re acknowledging that something probably won’t go as either party intended, so we need a buffer to handle the stuff that spills over. By capping it at a specific amount, though, we’re also ensuring that the buffer isn’t so big that it devours the profits of the developers.
For the most part, the clients with whom we’ve used the 15% rule are just fine with it. It is a pretty reasonable arrangement, after all. We have had the occasional party that squirms and wiggles about it, but, in the end, they’ve gone along with it and I think everyone has benefited as a result.
In response to a question as to whether or not we charge clients for the work we do within the 15% buffer…
Not if it’s within the 15% buffer, no. In fact, the customer can opt to have us do bug fixes or even add little features within that 15%, at no cost to them. Our experience has been that most clients simply want the job done, we get it done in time, so we don’t even touch the buffer. In cases where unforeseen issues arise or the customer pushes to get a bit more than was originally bargained for, we go up to 15% of the original estimate. Anything beyond that the customer has contractually agreed to pay for.
Thanks! I was wondering about that… and it makes pretty great sense actually. You want to deliver a great solution, so giving yourself the space to do that without feeling you are short-changing yourself is perfect. If you HAD been expecting the customer to pay I would have been dubious; every customer I know would expect the project to always take at least 115% 🙂
but then again, software is a Gas or something:
http://www.codinghorror.com/blog/archives/000677.html
Simple but great concept. I am assuming the 115% rule is used as a marketing concept as well as a practical operating metric. The fact that you understand that there are always curve balls is great but do your customers question if the billing rate is padded to account for the 15%?
How have you handled these types of objections?
-RJB
http://gotitsolutions.org
So in general the 15% is a way to legally ‘step out’ of the contract if the project time goes beyond what you had estimated + 15%. I would think if you find your contracts consistently taking 15% over estimations, you would rethink your estimation process. Naturally you add your own ‘buffer’ of time into the original work estimation, correct?
So what is the difference between this and adding 15% to your original estimation and stating work will not go past the estimation? Other than it not sitting well with the customer.
I run a development company and your scenerio sounds almost identical to mine – in fact I had come up with the “10% revision time” clause in our contracts. The idea, I had thought, was to set some expectations on how much we can go over budget doing tweaks and such.
The problem I found is that clients began to feel that, because we were offering the 10%, that we had burried it in into the costs. Therefore they felt very much the need to use up all of that 10% which they felt they had paid for. And the inevitable, uncomfortable conversations about scope and additional charges would come of *after* we had already gone 10% over time.
It did give us a tangible stopping point and in some cases make the client realize that there needs to be an end to the tweaking stage. But it didn’t always make the situation easier for us. I continue to struggle with it on every project – it’s probably the most difficult part of running software business, I think anyway.
Thanks for your insight into the issue!
Todd;
You’ve read my mind about the problems we can encounter on development projects. I will work on a legal binding contact with my attorney with elements of your document for all my future work.
Victor
I had (note the had) a similar rule: if the project took more hours, I would give a discount of 10% over the additional hours made, if the extra hours stayed below a certain number.
However, I do mostly small projects, and have noticed that in a good relation with trust, honesty *does* work. Meaning that if I estimate something to be x hours and it takes me extra hours, that several of my customers didn’t have a problem with paying those extra hours.
A common mistake is to think that one has to “pay” for the mistake. If my work takes longer, it’s because my work just takes more time. Not because I want to rip off the customer. It just means that the product can’t be made cheaper by me. Why should I pay for that?
So now I dropped those discount rules, and I probably wouldn’t use something like this 15% rule for the same reason. I mean, when one buys a computer, and discovers after one week that one needs 1 GB more memory, is the shop going to give a discount because they should have informed you better? Don’t think so.
I hope you realize that this is the software development equivalent of setting your watch 15 minutes fast.
Thanks to all who have commented. We were apparently indirectly digged (thanks Rob), so this post generated more comments than we typically get. I thought I’d take a minute to respond to some.
First, though, I’d just like to qualify this whole idea by stating that it isn’t meant to work for everyone in every software development situation. We don’t even use this rule with all of our clients. For example, we have a number of clients with whom we have long-term relationships where we don’t use this rule. We instead mitigate risk by breaking up development into small cycles (typically two weeks or so). That way course corrections can be made frequently. For those that have done a lot of software development, though, you may find some truth in the ideas I’m proposing. If so, hopefully they’re helpful. If not, that’s okay too. Ultimately the proof is in the pudding. If it works for you, you may want to stick with it. If it doesn’t, ditch it and try something else.
Simple but great concept. I am assuming the 115% rule is used as a marketing concept as well as a practical operating metric. The fact that you understand that there are always curve balls is great but do your customers question if the billing rate is padded to account for the 15%?
How have you handled these types of objections?
I wouldn’t say that we pad the billing rate to account for the 15%. The rate remains as is, and we simply spill over into the 15% if necessary. We have had a few clients object to this approach. Each time their objection was to having a ceiling, though–they didn’t want to be constrained to 115% of what we estimated. This essentially amounts to a blank check for the client, so it doesn’t make any sense for us to allow for it. In each of the cases, though, the client eventually agreed to our methodology (and I think everyone’s been better for it). We’re also in the fortunate position of being able to be selective about whom we work with. If a client doesn’t agree to the terms, I’m not at all bothered by passing the contract along to a different group.
So in general the 15% is a way to legally ’step out’ of the contract if the project time goes beyond what you had estimated + 15%. I would think if you find your contracts consistently taking 15% over estimations, you would rethink your estimation process. Naturally you add your own ‘buffer’ of time into the original work estimation, correct?
So what is the difference between this and adding 15% to your original estimation and stating work will not go past the estimation? Other than it not sitting well with the customer.
This is a very sound point. Like any other group of software developers, we pad our estimates. And, like just about any other group of software developers, we’re not always on the mark. The difficulty is that factors will frequently arise that no one anticipated, and that you can’t easily account for by simply padding estimates. In some ways the 15% rule can be thought of as a type of insurance policy–if something goes haywire, we’re protected from assuming responsibility for all of the damages. I think my earlier point also stands–even the most experienced software developers can be way off in their estimates (thus the Windows Vista example). Say what you want about Microsoft being an evil empire, but there are few groups that have more experience developing software than they do. The fact that the release date for Vista continues to be pushed out is at least partially due to the fact that they miscalculated the amount of time it would take to build it.
The problem I found is that clients began to feel that, because we were offering the 10%, that we had burried it in into the costs. Therefore they felt very much the need to use up all of that 10% which they felt they had paid for. And the inevitable, uncomfortable conversations about scope and additional charges would come of *after* we had already gone 10% over time.
This is a very good point. I think one of the keys here is in setting expectations up front. It needs to be made very clear to the client that there is a ceiling to the project. Some clients will complain regardless of how much you convey the idea from the outset, but our experience has been that most are quite reasonable about it once they see the reasoning that underlies it. That’s part of the reason that I tried to write the “Our Approach to Software Development” in plain English. It’s just an attempt to explain why we take the approach we do in a way that’s hopefully intelligible to most anyone.
However, I do mostly small projects, and have noticed that in a good relation with trust, honesty *does* work. Meaning that if I estimate something to be x hours and it takes me extra hours, that several of my customers didn’t have a problem with paying those extra hours.
I don’t see it as an issue of trust. The risk inherent to the project originates from factors that may be outside of the control of either party. Software development is a complex process, and there are occasionally unforeseen factors that can impact the time required to complete a project. I agree, though, that for small projects the risk is typically low enough that you really don’t need to rely on a rule like this. It’s nice to have as an insurance policy, though, just in case.
I hope you realize that this is the software development equivalent of setting your watch 15 minutes fast.
I like the analogy, but I’m not sure it’s very accurate 🙂 In most of our projects we never touch the 15% buffer. It’s there just in case. There are also some clients who will try to squeeze every penny out of you they possibly can. The 15% buffer gives them the satisfaction that they were able to “get more than they paid for” without damaging your profitability as a developer.
Congrats on being Dugg!! (even if it was indirectly)
“It’s nice to have as an insurance policy, though, just in case.”
I either misread the article, or don’t get how giving a 15% discount is an insurance policy. I don’t want to get less money if a project took longer, if this was unforseen. I do my job right, and if it takes me more hours, its because it needs those hours. So I want to get paid for it.
Hi,
I have just completed my analysis on this blog, and we don’t always follow this 15% buffer rule. As specially in web based application development it is very difficult to analyze the clients requirement in its entirety, till the time the actual wire frame or prototype of the application is completed.
We normally, have this 15% buffer flexible depending upon the client’s relationship with us. If the client is elite client of ours we may get the change request handled without even charing them additional cost. But yes i totally agree to what has been mentioned above, that the risk and impact analysis before accepting any change request is very important. This helps you to understand the further changes that client might want to depending upon the change made now.