A lot of people in the Agile community these days are talking about estimation being wasteful and suggesting not estimating projects at all.
One radical view amongst all of this is to tell clients that as a vendor of a project
This view of stopping estimation is built upon the belief that "if we release software frequently, we do not need to worry about estimates". And this belief can be incorrect many a times.
For instance a new client who has never worked with you would want to compare bids from other similar vendors before choosing one. The issue becomes bigger in an outsourcing scenario where the main reason for choosing a vendor is cost. High level estimates on cost and time would definitely help the client make that assessment.
While releasing software frequently builds trust with the product owner(s), it might not build the same levels of trust with say the CXO group within the organisation. Maybe the CIO who is funding your project does not have enough time to attend your showcases or UAT sessions.
Asking a client to fund one month and fund the next month based on the product delivered might again sound good on paper but the reality is for a lot of big clients this means a lot of administrative overhead to manage. Choosing a vendor is a hard ask in itself and now being ready to switch vendors almost every month is compounding the problem.
Taking a hard stance by saying no to estimation will be highly immature in the above scenarios.But this does not mean all this is entirely impossible. It is possible, but only after a period of time of working with the client. When a new project starts you have to bite the bullet and estimate. The important thing is to start moving towards a place where estimates become more and more irrelevant as you do more projects or more releases with the same client.
And this is where delivering value continuously will build trust with the client. Fostering people relationships at all levels with the client on top solid delivery will slowly nudge the client to start thinking about the product they are building rather than managing the vendor. This will then allow you as a vendor to focus way less on estimation and much more on building a great product.
Most "products" in the enterprise software world start as "projects" unfortunately. Projects are funded based on budget and the estimates are required. However changing this scenario is in the hands of the project team. It is the responsibility of the project team to slowly help the client focus on product building than project tracking. And that is only possible when there is enough trust built between a client and vendor, not always from day one !
One radical view amongst all of this is to tell clients that as a vendor of a project
"I will try and deliver the best possible outcome based on resources I have at my disposal. I will give you frequent production quality software almost every other day for you to track how I am progressing. I will charge you per day or even per hour. Don't sign a huge contract with me but sign me up for a shorter span , say a month, review my software regularly to see what I have built and renew the funding for another month if you are happy. If you are not happy you can please kick me out. "That might sound like the best thing to do or probably the most absurd depending on how your relationship is with your client. What people fail to articulate while suggesting this is that the entire premise is built on trust. And a whole lot of TRUST ! You tell a new client your are not giving an estimate and suggest the above dialogue you are bound to be frowned upon.
This view of stopping estimation is built upon the belief that "if we release software frequently, we do not need to worry about estimates". And this belief can be incorrect many a times.
For instance a new client who has never worked with you would want to compare bids from other similar vendors before choosing one. The issue becomes bigger in an outsourcing scenario where the main reason for choosing a vendor is cost. High level estimates on cost and time would definitely help the client make that assessment.
While releasing software frequently builds trust with the product owner(s), it might not build the same levels of trust with say the CXO group within the organisation. Maybe the CIO who is funding your project does not have enough time to attend your showcases or UAT sessions.
Asking a client to fund one month and fund the next month based on the product delivered might again sound good on paper but the reality is for a lot of big clients this means a lot of administrative overhead to manage. Choosing a vendor is a hard ask in itself and now being ready to switch vendors almost every month is compounding the problem.
Taking a hard stance by saying no to estimation will be highly immature in the above scenarios.But this does not mean all this is entirely impossible. It is possible, but only after a period of time of working with the client. When a new project starts you have to bite the bullet and estimate. The important thing is to start moving towards a place where estimates become more and more irrelevant as you do more projects or more releases with the same client.
And this is where delivering value continuously will build trust with the client. Fostering people relationships at all levels with the client on top solid delivery will slowly nudge the client to start thinking about the product they are building rather than managing the vendor. This will then allow you as a vendor to focus way less on estimation and much more on building a great product.
Most "products" in the enterprise software world start as "projects" unfortunately. Projects are funded based on budget and the estimates are required. However changing this scenario is in the hands of the project team. It is the responsibility of the project team to slowly help the client focus on product building than project tracking. And that is only possible when there is enough trust built between a client and vendor, not always from day one !