Why IT projects fail before they even start

It is commonly believed that a project starts with the kickoff meeting. In practice, it starts much earlier — at the second or third meeting, when the parties first discuss scope, timelines, and budget. That is where most future problems are seeded, and they surface three months later: as missed deadlines, disputes over the interpretation of the technical specification, and the familiar phrase "that's not what we meant."

Between contract signing and the first sprint lies a gray zone that almost no one writes about. In it, the project transitions fr om those who negotiated to those who will execute — and it is exactly at this transition that context gets lost. Development is rarely the root cause of failure; it merely reveals what was hidden in the uncertainty of the negotiation phase.

Below is an analysis of what happens in this gray zone, a set of diagnostic questions for evaluating a vendor before signing, and separately — what to do if the project is already underway and already behind schedule.

In brief: five key takeaways

The project starts at the negotiation stage, because that is wh ere scope, deadlines, and assumptions are fixed — and no one ever revisits them.

The main cause of failure is not weak developers, but a mismatch in mental models: one side discussed outcomes, the other received a list of tasks.

An estimate without stated assumptions is not an estimate — it's a promise.

The contract model is not a legal formality but a way to distribute uncertainty. A fixed price with poorly defined scope ends up costing more than a time-and-materials model.

The client has its own responsibilities in the project. Without a product owner with decision-making authority, any vendor will fail.

What happens between "signed" and "started"

Let's examine a scenario that repeats in various forms dozens of times.

Five meetings held, the pain understood, the desired outcome discussed, an indicative budget and timeline named. The client has internal approval. The contract is signed. Then the project moves into delivery — and the divergence begins.

The discussion was about value: "you will get a system where the sales plan is calculated automatically, taking external factors into account." The team received a scope of work: integration with two sources, a calculation model, an interface, reporting. The gap between these two formulations is the future failure, because the first doesn't answer key questions. Whose data is this and in what state is it? Who approves the calculation methodology? What if historical data is incomplete? Who accepts the result and by what criteria?

Then the predictable chain reaction occurs. A result was promised. An estimate was made based on incomplete information. The contract fixed the timeline and price. Development revealed the true scope. The client says "we discussed this," the vendor replies "that wasn't in the specification." Deadlines slip, trust falls faster than the schedule.

Importantly, neither side acted maliciously. It's just that early on, no one dealt with the uncertainty — they silently jumped over it, hoping to figure things out along the way.

Five causes of failure seeded before the start

Scope is defined as a desired outcome rather than boundaries. "Automate planning" is a goal, not a scope. Scope is a list of processes, data sources, integrations, user roles, and — just as importantly — what is not included in the project. An "out of scope" section in a commercial proposal prevents more future disputes than any discount.

The estimate is given without assumptions. A timeline of "four months" is meaningless without a list of conditions under which it holds true: test environment access by an agreed date, existence of integration interface descriptions, one methodology approver, responses to questions within two business days. As soon as an assumption is violated, the timeline must be reassessed. But if there were no assumptions to begin with, the reassessment is perceived as an attempt to deceive — and the client is right, because they were given a figure without conditions.

No solution owner on the client side is named. A classic situation: IT runs the project, finance approves the methodology, the business unit performs acceptance, security provides data requirements. There is no single person who can say "we're doing it this way." The project stalls not because of development, but because of the absence of a decision-making mandate.

Acceptance criteria are not defined. If it's unclear what counts as "done" at the time of signing, acceptance will become a negotiation. Criteria should be formulated upfront and be measurable: a report is generated within a certain time on a given volume of records, the calculation matches the reference model on historical data. The phrase "the system works correctly" is not a criterion.

Data quality is not assessed. The most underestimated item in analytics, planning, and import-substitution projects. Data is almost always worse than the client assumes: gaps, inconsistent reference data, different versions of the same entity across systems. Bringing data into a usable state can take a significant portion of the project, and this should be estimated as a separate line item, not "as part of the scope."

Ten questions to ask a vendor before signing

The maturity of processes is visible faster fr om the nature of the answers than from a portfolio. The questions conveniently fall into three groups.

About estimation. What assumptions is it based on? What happens to the timeline and cost if an assumption fails? What is included in the scope and what is explicitly not? Who participated in the estimation — only salespeople or was the architect involved?

About the process. How is the project handed over to development and who is present at the handover? Who will be the ongoing point of contact and when do they get involved? How does the client learn about progress and in what format? What acceptance criteria are proposed for each stage?

About the client. How and when is data quality assessed? What is required from the client's team and by when?

To this, add one question outside the groups: what most often goes wrong in projects of this type. A specific answer means the vendor has both experience and the ability to analyze it. A vague one means either a lack of practice or a habit of not discussing problems until they occur.

And one separate marker that works almost infallibly: if the vendor doesn't ask uncomfortable questions — that's a bad sign. Quality work in the negotiation phase in the corporate segment looks like joint diagnostics, not a capabilities presentation. If no one asked about data quality, access to environments, the role of security, or the internal approval process in the first meetings, the chances of getting a realistic estimate are low.

Fixed price or time-and-materials

The contract model is a risk management tool, not a legal detail. The choice depends on one parameter: how precisely the scope is described.

Fixed price works with a detailed scope and stable requirements. The vendor bears the risk and factors it into the cost. There are two dangers: cutting corners on quality if the estimate was optimistic, and disputes over the interpretation of the specification with any clarification. Mandatory condition: a complete statement of work and measurable acceptance criteria.

Time-and-materials is appropriate when the scope is refined during the process. Risk shifts to the client, but they pay for the actual work delivered. The main danger is scope creep, so this model requires discipline: a backlog, short iterations, regular demonstrations of working results.

A hybrid scheme divides the project into phases: before each phase, scope is fixed; within the phase, work proceeds under clear rules. It requires more mature management from both sides and is most often optimal for large projects.

Practical takeaway: fixed price with poorly defined scope is the most expensive option for the client. The vendor will build a contingency into the price, and the client will pay for a risk that may never materialize — while any change will require a contract amendment.

A working model for complex projects: first, a separate analytical phase with a fixed cost, producing architecture, detailed scope, and a justified estimate; then, core development under the model chosen based on real data. Such a phase is significantly cheaper than reworking architecture in the middle of a project and often shows that the original idea should be adjusted.

Changes and transparency: two mechanisms that remove half the tension

A client on a large project fears two things: that every clarification will turn into a change order with budget growth, and that they will learn about a missed deadline on the day it happens.

An adequate change procedure addresses the first fear. It includes a working buffer for clarifications within a phase, a threshold above which a change is elevated to a separate decision, a single entry point for requests, and a clear assessment of each change's impact on timeline and cost before work begins. The key here is not to prohibit changes, but to make them predictable: the client should see the price of a decision at the moment of making it, not at acceptance.

Transparency of progress addresses the second fear. A working practice is short, regular reporting on actual progress against plan, demonstrations of working functionality rather than descriptions of what was done, and an open list of risks and open issues with indication of whose decision is blocking work. If the status shows only a percentage of completion without a demonstration, the client knows nothing about the project's real state.

The client's role: without which any vendor will fail

A significant portion of troubled projects hits a wall not with the implementer. This should be discussed before the start, not at the moment of failure.

A product owner with the authority to make decisions on requirements and priorities is needed — not a coordinator who escalates questions upward, but a person with a mandate. Subject matter experts need to be available: if the specialist who knows the process responds once every two weeks, no methodology can compensate for that. Access to systems and data must be provided by agreed dates — waiting for the test environment remains the most common cause of team idle time. Security and legal need to be involved early, because requirements for data processing, vendor access control, and intellectual property transfer must be known before architecture design begins.

Separately, readiness for organizational changes deserves mention. A new system changes processes, and if old manual operations are not retired, users will get double the workload and reject the implementation, no matter how technically sound it is.

A mature vendor discusses these responsibilities before signing and records them in the contract as mutual obligations. An immature one will stay silent to avoid complicating the deal — and will get a conflict by month three.

What to do if the project is already underway and already behind

Everything above applies to the period before signing. But more often, decisions have to be made in a situation wh ere the project is in flight, deadlines have slipped, and both sides are occupied with mutual grievances. Such a project should be saved not by acceleration, but by restoring certainty. Three steps work.

First — document the actual state. Not according to plan, but as it is: what has been accepted and is working, what has been done but not accepted, what hasn't been started. This list almost always differs fr om the reporting, and the very exercise of reconciling the difference removes some of the conflict.

Second — re-estimate the remainder with assumptions. Not "how much is left according to the old plan," but a new estimate of the remaining scope with a direct list of conditions under which it holds true and risks that could shift it. If the old plan had no estimate with conditions, now is the time to finally get one.

Third — agree on acceptance criteria retroactively. This is an uncomfortable conversation, but without it, the project will never close: acceptance will be endless because the subject of acceptance has not been defined. It should be formulated by the same principle — measurably and by stages.

Additionally, prioritize: almost always, part of the stated scope is not critical for launch. Splitting into "needed for launch" and "can come later" restores a realistic timeline faster than any team expansion.

How this phase should be structured

Below is not a list of services, but a description of a process that can be used as a benchmark when choosing any vendor.

The estimate is not formed by salespeople alone: the architect and technical lead are involved. This means the timeline is given by those who will be responsible for meeting it, and the same people who will staff the project are present at the estimate presentation to the client.

Every commercial proposal contains a section on assumptions, limitations, and a clear list of what is not included in the scope. The client sees under which conditions the timeline and cost are valid — and understands in advance what could change them.

The handover to production is conducted as a separate procedure with the participation of those who conducted negotiations, the project manager, and the architect. The context is transferred by people, not by correspondence: the team knows not only what needs to be done, but why the client cares about it.

When the scope is opaque, the analytical phase is separated out. The client receives architecture, detailed scope, and a justified estimate before major investments, and can make a decision to proceed based on a document, not a promise.

The team works on staff and is not assembled from the market for a specific deal — the composition the client sees at the estimation stage is the same that will work on the project. Corporate development, 1C-based solutions, and web direction are covered by one company, so there are no seams between vendors wh ere responsibility blurs. Accreditation and a full set of documentation remove the risk of getting stuck on procedural approvals within the client's company.

Pre-signing checklist

Scope and estimate. Scope is described as a list of processes, integrations, and roles, not as a goal. An "out of scope" section is present. The estimate is accompanied by a list of assumptions. Data quality and completeness have been assessed.

Governance. A product owner on the client side with decision-making authority has been identified. Client obligations and deadlines are documented. The process for changing scope, timeline, and cost is defined. The format and frequency of reporting and demonstrations are agreed.

Outcome. Measurable acceptance criteria have been formulated for each stage. Security requirements have been obtained and incorporated into the architecture. Rights to results and source code are settled. Support and knowledge transfer terms after delivery are defined.

If more than three items are not covered, what is being signed is not a project, but an intention.

Summary

The project starts at the negotiation stage, and most future failures are seeded there. An estimate without assumptions is a promise, not an estimate — so conditions must be demanded alongside the number. The contract model distributes uncertainty: fixed price requires described scope, otherwise the client pays for risk that may never materialize. Changes should not be prohibited but made predictable, and progress should be shown by working results, not a percentage complete. The client has its own responsibilities, and the first is a product owner with real authority. Finally, a vendor's maturity is tested not by its portfolio, but by the quality of its questions and the existence of a well-established project handover procedure.