Our New Year's Resolution: Time and Material
(This post was originally published in the Ombu Labs Blog)
As of 2016, we will no longer work with clients on fixed bid projects. They are not a good fit for us and we are not a good fit for them.
All of our clients are startups. Fixed bids are counterproductive for startups. They give the client a false sense of security and they punish changing requirements.
Fixed bids make clients think that their project will be finished in a fixed period of time if their requirements don’t change while developing the project. That is a big if!
Problem
The problem is that requirements change constantly, especially when you are working with startups. Startups usually are trying to create something new, something that has never been done before.
In this situation, it is normal that requirements change. As a software development team, you should welcome change. It means that you are building something that is up to date with the real world.
However, when you have submitted a fixed bid and started working on a project, the last thing you want is a change in the specification.
Because of this, you are forced to define the requirements down to the detail.
You need to define what web pages you will build, what interactions they will have, what background jobs the system will run, what business expectations it will fulfill, performance requirements, browser requirements and many other requirements.
In a startup, this will be based on a lot of wrong assumptions. When you face reality (your users or the market) the assumptions will change. Therefore, the requirements will change.
Changes
A change means that:
- You will need to throw away all the code that you wrote that was related to the changed feature
- You will need to estimate the new effort for the changed feature
- You will need to re-schedule the delivery date
- You will need to get this new estimate approved by the client
- There will be back and forth with the client
For a 3 months project, this might be OK. But consider what would happen for a 12 months project. If you don’t have the right process, it will be hell.
What’s most important, the relationship with the client will suffer. That is something that you must avoid.
We have experienced all of these problems with fixed bid projects.
Time and Material
We decided to work with clients that agree to a simple Time and Material contract.
Basically, we work on projects for X hours per week (with a minimum of 20 hours per week) until our clients reach their business goals. If they have new goals and we are both happy with our work, we continue working with them.
We will work with one or two week sprints and we can show results by the end of the first sprint. If you don’t like what we are doing, you only lost one sprint.
I have been working with clients since 2008 and I found that the best relationships I’ve had have been with this model. It’s the best way to maintain a healthy relationship with our client and it’s less risky for both our clients and us.
This model works very well for clients that want to work with an agile team in a lean project. And we love to apply Lean Startup not only to our own products but also to our clients’ projects!
We rigorously track all the time that we spend on projects. Every invoice we send includes a list of tasks and the total amount for the work we completed.
We have a great team of developers, designers and product managers ready to work on your project. If you are interested in working with us, get in touch!
[This article was originally published in November 2015 on the Ombu Labs blog: https://www.ombulabs.com/blog/software-development/time-and-material.html]