Developing Software by the 15% Rule

I just found this great manifesto written by eKiwi, the developers of screen-scraper.

It’s a cross between a statement of their approach and a client bill of rights. It includes something they call the 15% rule, which, in their blog, they define as:

“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.”

Some other highlights:

  • “In any software development project there is an element of risk. Based on our experience, the primary risk we deal with is simply that we won’t create quite what you, as our client, had in mind.”
  • “…the more time we spend on analysis, the more precise the statement of work is…This is a bit of a catch-22 , however, as you may have already surmised. We could spend weeks detailing exactly what the client wants to have built.”
  • “We’re going to be nice to you…Our intent isn’t to nickel-and-dime you, or squeeze every penny out of you that we can. We want you to like us. We’re going to be nice to you. At the same time, we need to do what we can to ensure that our business prospers. That may mean that we need to be a bit hard-nosed about things on occasion.”
Start Small, Get Big
Growth Secrets for Self-Funded Startups. It'll Change Your Life.
What you get for signing up:
  • A 170-page ebook collecting my best startup articles from the past 5 years
  • Previously unpublished startup-related screencasts
  • Exclusive revenue-growing techniques I don't publish on this blog
"The ideas and information Rob provides should be required reading for anyone that wants to create a successful business on the web." ~ Jeff Lewis
Startups for the Rest of Us...
If you're trying to grow your startup you've come to the right place. I'm a serial web entrepreneur here to share what I've learned in my 11 years as a self-funded startup founder. Luckily several thousand people have decided to stick around and join the conversation.

For more on why you should read this blog, go here.


#1 Daniel on 09.09.06 at 3:04 pm

Thought this article was great. It’s featured on at the moment. I am a web designer/programmer but haven’t really thought of the 15% rule in it’s extactness. I follow the other steps as a programmer but have no defined rule for how long I’ll continue helping them on something. I think the 15% rule is good though.

#2 http:// on 09.09.06 at 3:23 pm

I just read “Agile Estimating and Planning” by Mike Cohn which takes an in depth look at software. What you have mentioned is probably a good “safety net”. I have used this same method in projects. One, we were going to overrun and actually got the client to agree to a time and materials basis at 99%. Phew. However, 15% can be a low margin of error depending on how good your estimating is. So that may be different for various teams, of course it would probably shrink over time.

#3 Anthony Towry on 09.09.06 at 6:09 pm

This seems like a fairly reasonable thing for an organization to adopt. If it’s used in an up-front/professional way, this could be a great tool for reducing time tied up in project politics.

#4 rwalling on 09.09.06 at 6:41 pm

One of the comments on Digg ( mentions that the 15% rule is nothing more than a “contingency.” Here is the response I posted: “In general there are two types of project quotes: fixed price and hourly. With fixed price the developer quotes a hard dolalr amount and if he exceeds that number without prior approval (a “change order”), then he eats it. Hourly contracts are typically an estimate of how many hours it will take to do the work, but if you’re doing things right there’s always a clause at the end saying “If we exceed this amount we can work additional hours at $X per hour.” You are referring to hard estimates, which do tend to have contingency built in. This document is referring to hourly contracts which typically have a smaller margin since they have “give” on the top end. With that in mind, the 15% is not a contingency fee, it’s work that will be done for free if the estimate is exceeded. The idea is that the client does not have to pay for the first 15% of hours over the original estimate, thereby sharing the risk between the developer and the client. Finally, the rest of the manifesto, and the real reason it caught my eye, is that it’s written in plain, casual English. I have bullet points at the end of my contracts that say a lot of the same things, but they’re cold, hard, and contractual. This document is much more of a relationship-builder and it’s a style I’m going to use in the future with my clients. Most people would never think to put a “We’re Going to Be Nice to You” section in a client document. This is a great use of transparency.”

#5 JohnnyCakes on 09.09.06 at 8:32 pm

I think that 15% might be a decent rule of thumb, but not much more than that. Also, while it might be a sweet sentiment, I don’t think statements like ‘we’re going to be nice to you’ or ‘we want you to like us’ are professional, nor will many clients relate to that. Frankly, some will laugh in your face if you try that approach. I mean, who wants to do business with freaking Google-like developers here with their corporate ‘do no evil’ bull crap? There are other ways of saying that you will respect the customer, do the best work possible etc. and still sound professional. Again, I think the sentiment is a very kind one and it seems that the folks at eKiwi have their hearts in the right place, but if this is a business contract then it needs to sound a bit less naive/hippy-dippy.

#6 http:// on 09.10.06 at 3:00 am

I think this is an excellent idea for helping calibrate expectations between clients and consultants.

#7 http:// on 09.10.06 at 4:14 am

This reminds me of some contractors I worked with who billed out at $100 per hour because they wanted to be known as a high-end boutique development firm. In reality, they might have been working at $25 / hour just to get the project finished.

#8 http:// on 09.10.06 at 9:12 pm

Estimating is challenging in the best of circumstances. The 15% rule is better than no rule, but I’ve found adjusting around risk to be more helpful. A higher risk project with more unknowns might have a 50% rule where as a well known entity might have 5%. The bigger challenge is how not to lose your shirt on short term work with estimating, analysis and especially communication (for something less than 2 weeks).

#9 RogerV on 09.10.06 at 11:44 pm

I design, scope out, and estimate a project then hand that documentation off to the prospective contractor. Then we go back and forth over that until we reach consensus. I strive to do these initial framework estimates to where is a realistic starting point. Once a project commences, I strive to be diligent to see that the contractor is kept on task and facilitated to where is not unnecessarily blocked. I monitor their progress fairly closely to be on the look out that they’re meeting estimations. They usually have someone that is supervising and doing the same from their side. I have multiple rationale in this: 1) I earnestly want to see the contractor succeed and not get into hot water (it’s not pleasant to get in those situations for either party so why let it even get there?) 2) If a situation does start to go south the I will indeed have a certain amount of shared responsibility because I framed up the initial scope of work. I won’t be able to entirely cast the situation as somehow the fault of the contractor. So what this means is I want the contractor to succeed because I want to keep myself looking good to my superiors. 3) I want to have a mutual good experience. Ever so often we need to bring on extra resources. That goes better if can revisit a firm where there is mutual satisfaction of prior experiences. 4) I’ve done software long enough to know it’s not easy to estimate complex software undertakings. In my personal stuff and things I line out for contractors, I try to work with my management to set appropriate customer expectations. I reflexively push back as much as possible and tend to ask for much as possible in timelines. (My particular customer clientele tend to ask for things much quicker than they’re actually able to absorb them into their production operations – it’s the nature of their business more than anything as they have things such as union negotiations that have to be addressed too. QA is particularly difficult because of the nature of the hardware devices that are interacted with – the software is soft real-time, event-driven, and distributed.) So far the contractor situations I’ve had a hand in have gone well.

#10 http:// on 09.16.06 at 6:37 pm

(These comments are directed mainly towards the self-employed programmer and/or the owner of a development company. Hope it helps.) My 15% rule isn’t time, it’s money! I ALWAYS figure that the client is going to want 15% more time invested into a project then I’ve calculated. Due to their last minute changes or due to the natural progression of developmental changes that the client “sees” differently. Therefore, I add an additional 15% to the price from the beginning. This allows for development until the client is completely satisfied with the project. Obviously, this method would not be appropriate if you’re bidding against other companies on a project. Also, my contract states: ” Completion of services is determined by functionality of completed work and not based upon subjective criteria. ” Although I am flexible with my clients, I review this line of the contract with every client prior to development. … I won’t “nickel-and-dime” you, please don’t “nickel-and-dime” me. (…of course, I say this with a pleasant salesman’s phrasing.) But the word “functionality” in this statement will allow you to painlessly let the client know that the project is functional and therefore, your contractual obligations are completed. Meaning… time to pay the balance.