Failed IT projects almost never fail because the technology was not sophisticated enough. They fail because of an unclear agreement, mismatched expectations, and nobody accountable on the company side.
The seven mistakes below recur at every scale, from family businesses to corporations. The good news is that all of them are preventable before signature — the stage at which fixing anything is cheapest.
Choosing the cheapest quote
The lowest price almost always means one of three things: the scope is narrower than you assume, quality has been traded away, or the vendor deliberately underpriced the start and plans to recover margin through change requests later.
The antidote: require every quote to be broken down by component — analysis, design, development, testing, data migration, training and warranty. A quote that cannot be broken down usually has not been thought through, and what has not been thought through becomes an invoice later.
Never writing a definition of done
This is the number one source of disputes. The company considers the project finished when the whole team is using the system smoothly. The vendor considers it finished when the listed features were delivered. Those two definitions can sit months apart.
Put this sentence in the contract: “The work is complete when the system successfully runs processes X, Y and Z using real company data for fourteen consecutive days without an error that halts operations.” A sentence like that eliminates ninety percent of potential disputes.
Not settling ownership of source code and data
Many companies discover this only when they want to change vendors, at which point their negotiating position is zero. Two questions must be answered before signing: who owns the code written specifically for you, and how do you retrieve all of your data if the relationship ends.
Not appointing an internal project owner
No vendor can fill this role. One person in your company must have authority to decide, must understand the process, and must have time actually allocated to the project. Leave it empty and decisions stall for weeks while the vendor bills for waiting.
The antidote: name that person in the contract, state how many hours per week are allocated, and define a deputy for absences. It looks excessive, yet smoothly running projects almost always have someone exactly like this.
Buying features instead of solving problems
Feature lists are the easiest way to compare proposals, which is precisely why they mislead. The features that impress in a demo are frequently not the ones your team touches daily.
The antidote: convert the feature list into a scenario list. Instead of “we need a reporting module”, write “every Monday morning a branch manager must be able to see weekly sales by category without asking anyone for help.” Scenarios can be tested; features can only be promised.
Skipping a trial with real data
Demos always run smoothly because the data is tidy and the scenario was chosen. Problems only appear when the system meets your actual data: inconsistent product names, strange legacy transactions, different units across branches, and exceptions that have always been handled manually.
Ask for this before signing: A limited trial using a slice of your own real data, operated by the staff who will actually use it. If a vendor declines with a convoluted explanation, that is extremely valuable information.
Not budgeting for life after go-live
A system is not a building that stands on its own once constructed. There are servers to pay for, security updates to apply, adjustments when third-party services change, and a stream of small fixes that never truly stops.
The antidote: agree annual maintenance cost upfront, with its scope spelled out in detail — what is included, what counts as new work, and the response time when something breaks.
A short checklist before you sign
| What must exist | Why it matters |
|---|---|
| Quote broken down by component | Stops hidden costs appearing mid-project |
| A measurable definition of done | Removes arguments about when the project ends |
| Code and data ownership clauses | Protects your future negotiating position |
| A named internal project owner | Ensures decisions do not hang |
| Usage scenarios instead of feature lists | Testable rather than merely promised |
| A trial with real data | Surfaces problems before the money leaves |
| An annual maintenance budget | Prevents the system being abandoned after handover |
Frequently Asked Questions
MDH is regularly asked to review scopes and technical proposals before a company commits. We will point out the parts likely to become extra costs later.
Request a Review
