How to sell Scrum to clients

The danger for the client lies in knowing the price of everything and the value of nothing. Did they express any interest in how value would be delivered...and that they could potentially obtain 80% of the value in the first 20% of the contract?

They acknowledged themselves that their requirements likely would change during the project, new requirements would emerge and others would be removed etc. We pushed the fact that they were allowed to reprioritize during the project etc. and they had no proble identifying their must haves and nice to haves in their requirements and that it would be feasible to deliver something small but usable early in the project. Still, here we are. 

I am thinking that the inherenent uncertainty is something that makes people uncomfortable and therefore fight to avoid at all cost. Even if they logically can agree that it's best that we accept this uncertainty and find out how to best work in that context, it simply feels better they can get a fixed price for a fixed set of functionality. 

It is just the price, the competitor gave a lower price and with that they will have less problems getting budget. They will know that the price may raise, but customers always want to handle prices as fixed prices and they will try to only allow  a certain percentage and the rest of the risk will be carried by the supplier.

With that they will be less costly than your proposal with less risk.

I am thinking that the inherenent uncertainty is something that makes people uncomfortable and therefore fight to avoid at all cost. 

The market for providing fake certainty is enormous and highly lucrative. The question is, will you sell?

Your proposal expresses the expectation of risks that both parties will bear each other with development and change.

In most cases, customers are unwilling to pay but have to take the risk of change. Your competitors seize this customer psychology and win the contract.

Under normal circumstances, you can neither be too honest in negotiating contracts with customers, nor can you lie at all risks. The most important thing is to cleverly grasp the customer's psychology.

Have you tried offering more information regarding "how quality aspects will be taken care of" by adopting Scrum if that client wishes to partner with your organization?

By Quality, I do not mean only a product quality perspective. There are multiple factors in the quality (perspectives) and I am not going to diverge in them at this point. 

Following things you may consider:

1. How the organization will benefit from collaborating with you? Do you provide a seamless experience in development for them or will your teams also handle other clients at the same time?

2. What is the minimum product quality and experience quality (to the client) you can assure to your client? for example. How many times your PO will officially touch base with them during the sprint? or How long would it take for PO to discuss with them if they want to add a particular functionality? Could you make an agreement on this frequency and demonstrate the positive effects? 

3. When and how the risks will be raised? Could your Scrum team commit to not just the frequency but the transparency about the manner in which they raise the risks with the client? What are the benefits of this approach to the client compared to a purely hour-based  ( maybe waterfall too) pricing model? What does it mean for the customers/users of the client?

Remember there are many options in the same category in the market. In any given price range we naturally tend to veer towards the better quality product or overall quality experience within that range. Why should we not highlight that aspect?

Thanks

This is more of a business development question for your client executive. Maybe your CE was spot on and was underbid by an overseas / outsourcing competitor. Or maybe your CE doesn't know their market. Sometimes building too much buffer into your proposal can make you too expensive.

Be aware that sometimes RFI / RFPs are just a process and the client is going through the motions while having already shook hands with their "preferred vendor" behind closed doors. Relationships are everything!

In our company (more than 5000 staffs) transformation to Scrum was about 4 years ago. The reason was typical: we wanted to release different product features more than 4 times in a year. So, the management began to explore how we can develop and release more often new features for our products and decided to work in Scrum. 

@Aditya

Thanks for your thoughts and comments

1. Not sure I understand what you mean by "provide a seamless experience in development for them" but we were flexible on the delivery date which could mean team fully or part-time allocated to the project

2. The client would take the role of PO, no proxy with us.

3. The transparency that delivering a done increment every 2 weeks will give into progress.

The client would take the role of PO, no proxy with us.

I wouldn't be surprised if this was a problem. Not only are your bids higher than competitors, but on top of that, you're asking the client to dedicate someone full-time to the project. Your client is outsourcing their project because they do not have the resources - whether that's people, knowledge, time - to build their product internally.

Your organization should be providing the Product Owner. This person should be dedicated to understanding the domain of the products that you make and can work with the client to understand their problems and needs. This person can be available to the development team throughout the effort. They do have to have close collaboration with the client, preferably not only the customer but also users, but they can shield the paying client from near-daily interactions with the development team.

@Thomas We clearly expressed that their deep involvement and commitment to the project was requried for this project and that was not an issue for them. The client would not have a problem assigning a PO, but  they do not have software developers in house, which was why they reached out to us (and others). 

I totally disagree with your assessment that we should provide the PO for the client. Sure, we could do that as well but that is a (common) compromise in my opinion. "Business people and developers must work

together daily throughout the project" and this requires commitment from the client. Regardless of our effort we can never get the domain and org. knowledge that the client themselves have so the ideal is for the client to act as PO and be part of the team, just as XP mandates.

Estimates always refer to the past and as I understood it your client saw the estimate as a kind of promise. I explain to clients, using the Cynefin framework, why such estimates can never be realistic and that trying to make them realistic is a waste of resources. I would also make your estimation process transparent so that the customer understands how your estimation was made. The problem is that many customers see agile software development as a way to be lazy and therefore I agree with Thomas Owens that it may have failed because you didn't provide a proxy Po, the company was suddenly faced with a situation where they had to deal with the issue intensively. But whether this is a good decision to work with such a client remains to be seen.