logo

Dilemma of fixed v/s variable project cost

By Nitin Bhide

Dec 18, 2023

For 25 years, I have seen many customers asking for fixed-cost project bids. However, I have not seen a single ‘successful’ fixed-cost project. When I say ‘successful,’ I mean a project where both the customer and developer company are proud and happy about that project. I have not seen such a project. The main reason is that ‘the concept of fixed cost’ results in perverse incentives to both customer and developer; invariably, instead of a ‘win-win,’ the situation ends up ‘lose-lose’ with no possibility of recovery.

This is how a typical fixed-cost project evolves from start to end. (If your experience has a consistently different outcome, I certainly like to know about it)

The customer wants to get new software developed. He does not have an idea about what the total cost will be. Obviously, he wants to reduce/control his risk. He thinks a ‘fixed cost’ project will control his financial risk. He invites ‘fixed cost bids’ to his project. Outsourcing companies know that something other than fixed-cost projects is needed. However, they want to gain a foothold. And they bid for it.

The customer selects an outsourcing company, and then the real ‘horror show’ starts. There are a lot of meetings to freeze the scope and finalize the specs.

During the first few months of the ‘honeymoon’ period, everything is going nicely, and the customer is happy/outsourcing company is happy. After 3 to 6 months, the first alpha release goes into the customer’s hand. Once a customer starts using it, he realizes that ‘this not what he wanted.’ So, he asks for a ‘few small changes.’ Initially, the outsourcing company accepts these changes and makes another release. The customer has more minor changes, and the outsourcing company realizes that the project’s margins and profitability are now seriously impacted. Outsourcing companies started pointing out that they have developed ‘exactly as per spec,’ customers are saying, ‘This is not what we wanted.’ So the customer is changing his mind. Outsourcing companies have started arguing that ‘it is a change request.’ The customer argues that ‘it is not, and it is a basic expectation.’ In a short time, customer representatives and project managers spend more time and money negotiating a change request and how much it will be charged. A short 2-hour feature requires 20 hours of negotiations. Customers will be charged for these 20 hours (directly or indirectly) and 2 hours of implementation time.

It is in the customer’s interest to avoid paying for change requests and to squeeze as much work out of the contract as possible. Obviously, that is not in the interest of an outsourcing company. The outsourcing company wants ‘as many chargeable change requests’ as possible. Hence, outsourcing companies may need to identify any initial specifications mistakes. Outsourcing companies will make more margin by forcing more paid change requests. Their interests are not aligned. They are ‘incentivized’ to ‘indirectly sabotage’ the project. Now, everyone is thinking about ‘costs’ rather than ‘value.’

The honeymoon is over, and now the customer representative and project manager have started thinking of each other as a ‘kind of enemy.’ Both think, ‘I am reasonable, and the other guy is not.’ Every review meeting is now a battle of wits and negotiations. The project team is fed up with constant bickering. They are not enjoying their work. They are now coming to the office to ‘complete the time sheet’ rather than to make customers happy and add value. Their productivity starts decreasing. Both the Customer and Project Manager notice this and start threatening the team. The productivity decreases even further. Now resignations and project change requests start happening, and productivity slides even further. Quality issues increase. Releases start bombing.

As a result, all stakeholders (customer representatives, project managers, development team) are now constantly stressed over price/schedule and effort negotiations.

It’s just a matter of time before your project joins a long list of failed (or nearly failed) projects.

If you have experienced this scenario, please leave a comment.