Let’s imagine a trusted, skilled supplier is hired for a development project by an existing customer. The supplier has delivered great projects in the past. The customer is confident that the supplier will deliver a great product.
There are several possible approaches here. In theory, the best is pure time and material until the customer is happy. This is development team for hire, and could work a lot like an internal team. The problem with this approach, can be that the customer has (or would like to have) a budget. Perhaps they even have a deadline for delivery. “We need predictability!” they scream, while our shoulders slump..
Some may be surprised to find that here I’d be willing to accept both fixed budget and fixed schedule. Yet, not on any terms. First of all, the supplier should still charge for T&M, but with a limited budget. As long as we have a limit on our spending level, it’s somewhat easier to accept a fixed schedule as well. If we know our team size, we can know roughly when we will be out of money. We’ll know when we will be “done”. The downside is that the customer won’t know exactly what we leave them with when the money runs out. Given our proven track record, this may be acceptable. A middle ground can be to agree on a minimum set of features delivered, without detailing these too much. We’d like to be able to negotiate the scope of each individual feature as well.
I surrendered to a fixed (or limited) budget and a fixed scope. I need something in return. I choose a flexible scope and a product owner that is available on short notice (or even part of the team). Why? We will discuss what to build during the project — and not by consulting detailed plans — but by consulting her. We’ll have a rough idea of what to build, but the details will come as we need them. As time goes by, we’ll become better equipped to decide what are the most important problems to solve.
So do we need estimates in this scenario? Sort of. The customer will likely ask us to suggest a budget. We need technical competence and domain knowledge to do that. We also need some high level estimation effort. After the development has started, we can take an agile approach. We can report progress and prioritize based on the value we deliver. Another option could be some kind of drop funding approach. Start small and get more funding after we’ve proven delivery capability.
This model is somewhat unpredictable for both parties. The customer doesn’t get to know (or get the illusion of knowing) exactly what he will get. The supplier doesn’t know how long the assignment will last. The customer can decide “good enough” at any time and stop the project. This leaves the supplier hanging, and they may end up with periods without work. My experience so far, is that customers who set a budget usually spend it even if they’re allowed to stop half way. By allowing the scope to be flexible, they just spend it better.