top of page

How Invalidating a Customer’s Technical Requirement Won Me a $20M+ Deal


“To secure ourselves against defeat lies in our own hands, but the opportunity of defeating the enemy is provided by the enemy himself.”

Sun Tsu, The Art of War

One day I was called into an account where the customer had pulled an exit clause of a 10-year outsourcing contract after 2 years. The who-is-who of the outsourcing industry was eager to take the customer away from us and pursued the opportunity with aggressive pricing.

The account team members were former employees of the customer we had taken over together with the data center with all its assets. Now their former colleagues wanted to get rid of us to regain control over the IT in an attempt to fight business consolidation efforts from the group’s headquarters.

After the cancellation of the contract our opponents released a new Request for Proposal (RfP) asking for exactly the same services we already provided under the old contract. When we analyzed the situation we found providing an offer at the same conditions to be meaningless assuming the competition was determined to buy the deal at almost any price, while going in with a lower price would have been held against us as proof for the fact that we overcharged the customer over the last two years.

So, we decided to deploy a containment strategy (see my review of Power Base Selling) by refusing to provide a new offer and notified the customer of a clause obliging them to buy back all the assets we had taken over at residual book value assuming they had overlooked this and not factored it into the business case yet. We were right. The RfP got canceled.

All of a sudden the customer found himself in an unbearable position: The contract with us was canceled and they ran the risk that by the end of it we would stop providing any services including their central SAP R/2 system they relied on for material management and production while at the same time they had no alternative offers from our competitors at acceptable financial conditions.

Other than before, now all the doors opened to discuss the situation with us allowing me to explore the power bases at work. There was an enterprise power base dominated by executives at group level focused on consolidating operations to sell the entire organization to one of the large global players in the industry. And there was a situational power base consisting of the division heads and their IT managers fighting this consolidation efforts to maintain their position.

After a while the customer issued a new RfP, this time asking for an R/2 - R/3 migration. When analyzing the technical requirements we came across an odd one: The RfP asked for multiple divisional R/3 systems rather than a central one with instances for each division. When we scrutinized the requirement the customer claimed their divisions to have special requirements that couldn’t be met in a central SAP R/3 system and even highlighting the fact that both the migration as well operations of multiple R/3 systems would significantly increase costs didn’t change their mind.

Here was the opportunity to defeat our competitors provided by the divisions themselves: If we could prove that all divisions could manage their business on just one R/3 system we had a significantly better offer than all providers following the RfP. So we embarked on an indirect strategy and decided to position our proposal based on a central R/3 system directly with the group’s CFO openly attacking the divisions’ requirement for multiple ones.

We arranged a meeting with the CFO bringing with us a project manager that had just implemented R/3 at another company in the same industry. He took the requirement for multiple R/3 systems apart demonstrating how they could be met in one central system. At the end of the presentation the CFO asked me for a guarantee which I provided: Our offer was a fixed-price one taking away the risk of implementing and operating multiple systems in case our plan didn’t work.

The CFO looked around the table for a moment, then stated that for him the decision was made. And left the room. And so did we. We were awarded the new contract just a few weeks later.

The example demonstrates how technical requirements can be in fact driven by the agenda of competing power bases, in this case the situational one trying to fight the enterprise power base’s push for consolidating operations.

To dismantle these fake requirements requires Account and Technology Managers to work closely together. Account Managers must know the technical basics of their offering while Technology Managers must have a sense for the political dynamics of power bases. In other words: It is a multi-disciplinary effort to correctly analyze technical requirements for their political motivation.

Fake technical requirements are self-defeating the moment we can unmask them. Once we invalidate them we have the power to secure a buying decision in our favor applying an indirect strategy at a higher level power base.

For more detail on this example please refer to the related Anecdotal Evidence.

Comentarios


bottom of page