When I am asked to look at an IT project that is running late, the first conversation is almost always about delivery: the plan, the team, the pace of work. Those questions matter, but they rarely explain the delay. So I ask for different documents first: the offer, the signed contract and whatever was handed over from sales to the delivery team.
More often than not, the reason for the delay is already written there. A deadline nobody estimated. A scope described as a goal rather than a list of functions. An acceptance clause that lets the approval drag on for months. The project was late before the first person on the delivery team opened the backlog.
Why IT projects fail in sales
Understanding why IT projects fail in sales requires looking past the moment the work actually begins. The project manager discovers that the schedule is unrealistic, the deliverables do not exist, and the scope of work is much wider than initially set out.
This happens because, during the initial phase of the sales process, suppliers often ignore the realistic schedule to win over competitors and meet the client’s expectations. After signing the contract, the project team usually inherits the delay. My Delay Starts in Sales method traces these delivery problems backward. We examine the handover to delivery, the contract, and the original sale to identify commitments that need correcting before work begins. As an independent advisor, I look closely at the scope, the estimates, and the payment schedule to assess whether the operational reality matches the commercial promise.
What my projects reveal
The telecom commitment I would revisit
In my first international German telecom project, the early sales brief targeted a 50% acceleration in network-planning processes, a halving of business processes, and an IT platform replacing 25 systems. The client intended the contract to define only KPIs for the new processes, while pressing the supplier to propose the IT platform’s scope based on industry expertise.
Experienced implementation-department managers declined to lead it because they concluded it could not be delivered and did not want to assume the risk or destabilize their functioning business and potential annual bonuses. A CEO or delivery head reviewing such a proposal should ask how the delivery team can commit to an undefined technical scope.
What the banking project exposed
In one of my projects for a large institution, broadly worded acceptance terms with no specific quality levels led the approval process to take months, while the stated standard was two or three weeks. The contract merely stated that each stage would be approved upon successful completion of acceptance tests, leaving the vendor vulnerable to endless cosmetic revisions.
I would not accept a delivery timeline if the conditions for completing the work remained subjective. A delivery head should demand specific, numerically quantified parameters for defect classification to help the approval process run efficiently.
What I learned from international rollouts
In a multi-country rollout I worked on for a telecom conglomerate, the vendor delivered the software exactly per the contract specifications. However, the client quietly cancelled the entire initiative because a third party’s migration failure left the system empty and unusable.
The assumption that another party would successfully migrate the data was never properly challenged during the sales phase. A delivery head should ask what happens to the project if a critical customer dependency fails. We should establish whether the promised deadline still holds and who bears the cost when an external obligation blocks our progress.
What to check before signing
Can delivery defend the scope and estimate?
Sales and negotiation contain far too many unknowns to define details, so contracts usually contain declarative goals. When management negotiates but users receive the outcome, delivery-phase problems surface. To defend the scope, a detailed functional description appended to the contract should document the product’s functionalities, feature use cases, defined business actions, operating method, and excluded scope. This ensures the supplier can refer to it in a dispute over a client’s interpretation of a requirement.
The foundation of a realistic schedule is low-level estimates from the specialists who will perform the tasks, including programmers, architects, analysts, testers and developers. The people responsible for the work should review these estimates against explicit assumptions and technical uncertainty. Department heads must also confirm resource availability against existing obligations and work in progress. We should ask what needs to change if an assumption proves false and who can approve that change.
Do payment and acceptance terms fit the plan?
Payment terms should align supplier revenue with incurred costs. When larger amounts are invoiced only after completion, the project is run cautiously and delivered much later than under funding proportionate to costs. We should compare payment triggers with achievable delivery milestones, distinguishing between work completed, customer acceptance, and payment becoming due.
In another project, well-defined contractual acceptance criteria enabled the client and business-department representatives to evaluate and classify defects, and the approval process was carried out efficiently. We should ask who confirms acceptance, what evidence is required, and how objections are handled. Delay-penalty clauses should limit penalties to delays for which the vendor is solely responsible, rather than any delay or any delay partly caused by the vendor.
What must the handover make explicit?
A planned handover should explain why the sale was agreed on these specific terms, rather than merely transferring the signed documents. Vendors may deliberately hide some facts and agree to unrealistic terms to get the deal, while clients may prefer to define the scope vaguely and refrain from the initial requirement analysis.
In the described project sold at a very competitive price, a general scope and the supplier’s lack of adequate domain expertise enabled the client to demand its own interpretation of the system; supplier costs then rose significantly above the original estimate. To prevent this, the handover must carry forward the agreed scope, exclusions, estimate assumptions, customer dependencies, acceptance conditions, and payment milestones. We should distinguish a firm contractual commitment from an informal expectation. Delivery should raise inconsistencies before work begins, assigning a clear owner to resolve them.
Sales is not the only cause
What if the problem arose after kickoff?
Delays generated during project execution are distinct from delays originating in decisions made during the sales process. New requirements, execution mistakes, and changed customer circumstances can certainly create delivery problems long after work begins. My method requires concrete evidence linking the observed problem directly to an earlier commercial commitment. Where that link is absent, we do not force the explanation back to sales.
Who approved the commitment?
Pre-sales and sales units should not make trade-offs related to the costs, scope or schedule on their own. Executives must make the final decision with visibility of the risks and which departments accept or reject the proposed commitment. Documenting a customer obligation does not establish that the customer can actually meet it.
Correct the commitment before kickoff
A delivery plan alone cannot make an unsupported commercial commitment achievable without changing the conditions behind it.
When we analyze why IT projects fail in sales, we see that the scope, estimates, payment terms, and the handover are all interconnected parts of the same commercial commitment. We should not ask the delivery team to absorb the contradictions of a poorly structured contract.
In practice, correcting the commitment means a short, honest review before kickoff. Before the team starts work, I would want clear answers to five questions:
- Who estimated the schedule, and were the people who will do the work part of that estimate?
- Is the scope described as functions and exclusions, or only as business goals?
- Do the payment milestones follow the real cost of the work?
- Are the acceptance criteria measurable, and who signs them off?
- Which customer dependencies can stop the project, and who carries the cost if they do?
If any of these answers is unclear, kickoff is the cheapest moment to fix it. After that, every week of delay costs both sides more and makes the conversation harder.
If your project is late before it has even started, or you suspect it will be, request a strategy session through the contact form. We will go through the sale, the contract and the handover together and decide what needs to change before delivery begins.