Bug fun – An SLA model for contracted development, specifically about getting “cash back” for project delays and development quality (bugs). Spreadsheet link at the end.
Startups with little capital or that are bootstrapped often contract some of their development to lower cost companies worldwide. This model is gaining traction, whether it is in the initial stages of a prototype development or a full blown application development. An almost inevitable part of development is project delays and bugs in excess of what one expects for a project.
In this article I am trying to come up with a model to get credit or actual “cash back” from the vendor for delays and bugs (based on project parameters). Other standard measures of code quality can be incorporated in this model too.
The concept is simple – the vendor should give a credit equal to the percentage of the delay or the percentage of bugs above what was agreed upon. Example: if my project is delayed by 1 day (say 2%), I should get 2% of cost back. Simple. But what makes the ‘delay’ formula complex is provisions to prevent ‘gaming’ the model. By simply putting fewer resources on the project, and dragging out the calendar days, the vendor gains and the entrepreneur loses. So the model incorporates resources, calendar days, grace days, with independent scaling factors for each.
The bugs model is much simpler, just a percentage of allowed bugs. The bug count is normalized into ‘bug units’ based on an agreed upon conversion, such as 1 critical bug equals 2 major bugs equals 5 minor bugs. You get the idea. Then you allow some bug-units (say 15) per certain person-days of development (say 20). Thus, for a 100 person-days project you allow 75 bug-units (which could be 75 minor bugs, 15 critical or 30 major, or a mix thereof). Hence the “bug-equivalence” should be well thought out for your project beforehand. Then if you have 15 excess bugs, you should get a credit of 20% of the project cost, or some part thereof.
Yes, agreeing on the severity of a bug is part art, part science. One person’s bug is another person’s feature! But take the 80/20 rule here: even if you agree on 80% of the bugs, it is better than nothing. Example: not being able to login or register on a website is a critical bug, not being able to edit your profile is major and a spelling mistake is minor. And yes, this may increase the cost of doing business across the board, but think of it as insurance.
In the end of both models, there is a simple scale factor that you can use for tweaking the credit to make it palatable to both parties. Whether its cash back or credit for future projects, that’s a bi-lateral decision too.
A bit about me: I have worked extensively with the outsourced model (on both sides of the oceans), with over 17 years of IT experience, since way back when Netscape had not IPO’ed and outsourcing was just catching on. I worked for Infosys (India), Keene (USA), and more recently, I have worked with multiple small software development companies in India for my own startup Coloci.com.
I would appreciate your thoughts about this model, its acceptance among vendors, tweaks, etc based on your experience in this space. Thanks in advance! The spreadsheet is here: https://spreadsheets.google.com/ccc?key=0AjbcRctmfiWQdFBjS3lGTF9iZV9QeU00aC0xdlVIYUE&hl=en.
Anurag
Founder & CEO, Coloci.com
