Want smoother IT projects? Start by improving how you sell. The so-called sales to delivery gap arises when what’s promised to the client diverges from what the delivery team can realistically execute. In this expert conversation with Marcin Dąbrowski, we explore how early-stage assumptions shape project outcomes, and what organizations can do to close this critical gap.

Marcin, let’s begin with a question that sounds simple but isn’t. When, in your opinion, does a project really start?

Many people would say that a project begins when the contract is signed or during the official kick-off meeting. But that’s a misconception. In reality, a project starts much earlier – at the moment of the first sales conversation.
That’s when expectations are formed, assumptions made, and promises given. Even if they’re not yet written down. From that point, both the client and the vendor begin to build a shared vision of what’s going to happen.
If that vision is based on unclear scope or unrealistic estimates, you’ve already created a problem before the delivery team even opens Jira for the first time. That’s where most IT delivery gaps are born – not in execution, but in the way the project was sold.
So that’s what we usually call a sales to delivery gap?

Exactly. The sales to delivery gap is the disconnect between what was promised during the sales phase and what actually needs to be delivered once the project begins.
It’s one of the most persistent challenges in IT consulting and software delivery. You can spot it easily. When Sales says, “The delivery team doesn’t understand the client’s expectations,” and Delivery responds, “Sales sold something impossible.”
In reality, both sides are right. Sales teams are under pressure to win deals. Delivery teams are under pressure to deliver results. Without strong alignment and a proper sales to delivery handover, these two worlds often collide.

What causes this gap to appear in the first place?

There are several structural reasons. One of them is misaligned incentives. Sales team is usually rewarded for closing deals, not for their long-term profitability or deliverability. Delivery, on the other hand, is evaluated on project success, which means scope control, timelines, budgets etc.
Another issue would be the lack of communication. Too often the handover between Sales and Delivery is treated as a formality – short meeting with slides instead of a real knowledge transfer. Important details are missed: what was promised, what was excluded, what assumptions were made. That’s how the delivery team walks into a project with half the picture.
Unrealistic commitments made under client pressure is also a problem. When the client pushes for lower prices and faster delivery, suppliers often agree. Not because they believe it’s possible, but because they’re afraid of losing the deal.

Can you give some examples of what this looks like in practice?

Sure. Let’s think of a vendor that, during the sales process, agrees to a very general description of scope to stay competitive. The client accepts it, the contract is signed, and everyone is happy. Until new stakeholders appear on the client’s side.
Suddenly the same vague scope is interpreted much more broadly. Features that were never planned become “obvious expectations.” The delivery team can’t push back effectively because there’s no clear boundary set during sales. I think you can guess the outcome of this situation: escalations, change requests, missed deadlines. In a word, frustration on both sides.
Another common scenario is when estimates are prepared without input from technical experts. Sales teams rely on rough assumptions or reuse previous templates. Then, when the project starts, the delivery team realizes that the effort was underestimated by 30 or 40%. At that point the only options left are to delay, renegotiate, or absorb the loss.

It sounds like the sales process is actually the most critical stage of delivery.

That’s absolutely right. The sales phase is exactly the first phase of delivery processes and treating it as a separate world is one of the biggest mistakes companies make.
The truth is that a project’s success is largely determined before the delivery team writes a single line of code. If the deal was sold on wrong assumptions, no amount of heroism during execution will save it.
That’s why I always tell leaders: focus on the quality of your sales to delivery handover. Make it a structured process, not a ceremonial one. Everyone involved – from account managers to project managers and solution architects – should understand what was sold and where the known risks are. When this alignment happens, the IT delivery gap shrinks dramatically.

What practical steps can organizations take to minimize the gap?

You need to involve the delivery teams early in the sales process. Don’t finalize a proposal without consulting technical or domain experts. They’ll help identify risks and realistic timeframes.
Moreover, make sure every offer includes not only deliverables but also explicit assumptions and exclusions. The phrase “what’s not included” is as important as “what is.”
You must also establish a formal sales to delivery handover procedure. It should include documentation review, risk validation, client expectations, and an alignment session where the entire delivery team can ask questions.
And finally, educate the client. Sometimes we’re afraid to challenge unrealistic expectations because we don’t want to sound “difficult.” But the most professional thing you can do is be honest. Clients value partners who speak the truth, even when it’s inconvenient.

And what advice would you give to project managers who inherit projects with a sales to delivery gap already baked in?

Oh, well… I think the most important thing in such scenario is to face the reality head-on. Don’t pretend everything is fine. Review the contract and identify discrepancies between the sold scope and what’s actually required. The next piece of advice would be: don’t forget about project documentation. Basically, document everything. Every new request, every deviation from the initial scope – they all matter. Transparency protects both sides.
And finally, build trust with the client by being proactive and factual. Instead of saying “we can’t do this,” say, “we can, but it requires a scope adjustment or additional budget.” It’s not about conflict, it’s only about clarity.
One more word for leaders: align incentives. Don’t reward Sales for closing deals that Delivery can’t execute. Make sure success metrics are shared across both teams. When both sides win or lose together, the collaboration changes completely.

So, to wrap up, when does the project really start?

Long before the kick-off. It starts with the first conversation with the client. Every assumption, every promise, every compromise made during the sales phase shapes the project’s future.
If you sell the project right, with realistic estimates, honest communication, and shared accountability, delivery becomes a controlled process, not a rescue mission. If you sell it wrong – you’re just delaying the inevitable problems. That’s why closing the sales to delivery gap should be treated as the foundation of long-term client trust and business success.

Thanks for the conversation!
You’ve just read a conversation with Marcin Dąbrowski. Need support with your project management? Our team of experts have broad IT competencies and can help you in all kinds of projects! Whether you’re facing legacy challenges or preparing for digital transformation – we’ll help you start right, and finish stronger. For more insights on delivering high-stakes projects, check out Marcin Dąbrowski’s books:
- 10 Rules for Impossible Projects. Surprising – But True – Advice on How to Successfully Deliver Difficult and Complex Projects
- Managing IT Projects: How to Pragmatically Deliver Projects for External Customers.

Tomasz Michalik



