Why Sales and Project Managers Keep Clashing in IT Projects

"Delivery is too slow and too expensive for us to close anything."

"Sales has oversold the project again, and now we have to deal with the mess."

Anyone who has worked in an IT company, whether in software development, system integration, infrastructure, or technology consulting, has probably heard both statements, sometimes within the same week.

It is easy for this situation to become a blame game. Project managers may feel that sales promises too much and reduces the budget simply to win the contract. Sales managers may feel that delivery teams are too cautious and add so much contingency that proposals become uncompetitive.

In most cases, neither side is completely wrong. They are looking at the same project from different positions. They have different responsibilities, targets, and pressures.

The sales manager's job is to bring business into the company. This means understanding the customer, competing with other suppliers, preparing an attractive proposal, and closing the deal. Customers often compare several vendors and push hard for lower prices. A proposal that is priced too high may lose, even when it offers the strongest technical solution.

Sales managers also work under revenue targets and pressure from senior management. Without signed contracts, there is no work for the rest of the company to deliver.

The project manager's job is to make sure the company delivers what it has promised. Once the contract is signed, the project manager must manage the agreed scope, timeline, budget, people, customer expectations, technical issues, vendors, risks, change requests, testing, documentation, and final acceptance.

When a project is sold with an unrealistic budget or timeline, the delivery team must deal with the consequences long after the sales target has been achieved. This often leads to cost overruns, stressed employees, delays, customer complaints, and a project that produces little or no profit.

Many people assume that the estimate prepared by the delivery team is the same amount presented to the customer. In practice, this is often not the case.

In many companies, the process begins correctly. Sales asks the project management and delivery teams to estimate the implementation cost. The problem starts later, when sales returns and asks them to reduce the estimate because the proposal will not be competitive at the original price.

This is rarely presented as a simple request. Delivery may be told that the company has little chance of winning unless the estimate is reduced. At that point, the delivery team is placed in a difficult position. It must either reduce the number or accept that the company may lose the opportunity.

This is often the main source of tension. Sales may not be ignoring the original estimate. Instead, the estimate is being reduced under commercial pressure. Once this happens, the original cost calculation may no longer have much value.

The other side of the issue is also important.

A project manager who is allowed to set the final price alone may include too much safety, contingency, or additional effort. This can make a reasonable opportunity too expensive and allow a competitor to win with a tighter price.

That is also a real loss to the company. However, it is less visible because it appears as a contract that was never won, rather than a project that exceeded its budget. As a result, it is not always discussed with the same level of concern.

Neither team is the main problem. The real problem is an organisational process that allows an estimate to move between teams, be adjusted several times, and reach the customer without a shared understanding of what the final number represents.

A few practical changes can prevent many of these problems.

The first is to separate the actual implementation cost from the customer selling price. Both figures should remain visible and clearly recorded.

The implementation cost is the amount genuinely required to complete the work. It should include staff effort, project management, technical work, testing, documentation, training, travel, third-party costs, support, and a reasonable allowance for risk.

The selling price is a commercial decision based on the implementation cost, expected profit, competition, and the importance of the customer.

A company may decide to offer a discount to win a strategic account, enter a new market, build a customer relationship, or secure future business. These may all be valid commercial decisions.

However, the discount should not be hidden by quietly reducing the implementation budget. Otherwise, the delivery team is expected to complete the same scope with fewer resources and less money, without properly agreeing to the change.

For example, assume the delivery team estimates that a project will cost Rs. 10 million to complete. The normal selling price, including the expected margin, may be Rs. 13 million. Sales may believe that the customer will only accept a price of Rs. 11 million.

The company can still decide to submit a price of Rs. 11 million. However, the records should clearly show that the estimated delivery cost remains Rs. 10 million and that management has accepted a lower margin.

The company should not quietly reduce the implementation budget to Rs. 8 million and expect the delivery team to complete the same work.

The second improvement is to conduct a short pre-sales review before submitting any major proposal.

Sales, project management, technical leads, and finance should review the scope, timeline, cost, resources, assumptions, risks, and customer dependencies before the final price is approved.

This does not need to become a long or complicated process. A short meeting supported by a simple approval form may be enough. The purpose is to identify any difference between what was originally estimated and what the company is preparing to promise.

The third improvement is to decide who has the authority to accept a low-margin or high-risk project.

There may be good business reasons to accept a project under tighter conditions than usual. However, this should be a deliberate management decision. The commercial benefits and delivery risks should both be explained clearly before approval is given.

This is far better than allowing sales and delivery teams to argue about the decision after the contract has already been signed.

Companies should also review completed projects regularly. They should compare the estimated effort with the actual effort, the planned cost with the final cost, and the expected margin with the actual margin.

The review should identify the true reasons behind any difference. These may include an unrealistic estimate, missing requirements, customer delays, weak change control, technical issues, poor resource management, or mistakes during implementation.

Not every project shortfall is caused by sales. Delivery teams must also accept responsibility when resources are not managed properly, risks are not tracked, or additional scope is accepted without formal approval.

Sales and project management should not work against each other. Sales brings business into the company. Delivery turns that business into a result that the customer is willing to accept and pay for.

Both teams are necessary, and neither can succeed without the other.

When the implementation cost, selling price, risks, assumptions, and approvals are clearly recorded, discussions become less personal. Instead of arguing about blame, both teams can focus on making informed decisions and delivering profitable projects successfully.