Friday, January 04, 2008

Conundrum of fixed price contracts for software development service?

I get this from our prospective clients a lot-


I need to know how much it is going to cost me to build my software.

The conundrum. I understand where they are coming from. After all budget is always finite. We do not feel comfortable committing to buying something without knowing the total costs upfront. While it is possible for fixing the price of many goods or services, it is very difficult, if not impossible, to do so with software development service. The simple reason is that the estimates are as accurate as the requirements. It is not possible to define everything one wants in his software with all the details. That is why buyers try to put many clauses in the contract to move the risk over to the service providers. On the other hand, the service providers try to push the risk back to the buyers by requiring the spec to be detailed and complete. We all know words are imprecise. Hence both parties end up with a contract that helps none. So what is the remedy?


Agile philosophy is in rescue. The concept is simple. The cost driver of software service is time. Since the budget is fixed, the total development time is automatically fixed for a specific rate. The only thing that we can play with is the scope of the work. Yes, I know who wouldn't like to have everything, but the reality is we need to restrain our wants. How do we do it?

Enter the world of no long-term commitment. The client creates and manages a prioritized list of things/features that he wants in the software. In Scrum, we call it product backlog. The developer works his way from the top of this product backlog, and delivers working software every 1-4 weeks (iterative incremental software development). That way the client is sure that he is getting the most value for their bucks. Yes, we can still give our clients a high level costs estimate in terms of number of sprints it might take to complete the project with an understanding that it would change as the project progresses. As the developer makes no commitment to any effort estimate, so does the client make no commitment to any budget amount. Both work collaboratively to manage the scope (the product backlog) to meet the goal and the budget. Every two weeks (assuming the development cycle is 2 weeks), the client can change the course of the project based on the current state of the working software in progress as well as the business conditions.

What should you do? I know this could be unsettling for many who are used to the old ways of managing vendors and projects. Believe me, if you try it out on your next project, you would not want to do it any other way. It is truly liberating when the client and the service provider work collaboratively to achieve a common goal without worrying about legal documents.

No comments:

Post a Comment