Among the projects we have taken over from other teams, almost none died because "the technology was too hard". They died for very ordinary reasons, over and over. Here are the seven most common, with the early warning signs.
1. Scope described in adjectives
The contract says "a complete, friendly, easily extensible sales management system". Nobody knows how far "complete" reaches, so at sign-off the two sides understand it differently and argue about exactly that word.
How to avoid it: scope must be a list of things the system does, phrased the way a user would: "the cashier can create an order with several items, apply a discount by percentage or amount, and print a receipt to a thermal printer." Any line you cannot verify by clicking through gets rewritten.
2. No single decision-maker
When five departments all comment and nobody can settle it, the project circles: accounting wants this, the warehouse wants that, and the developers wait. Every circle is another week.
How to avoid it: name one owner on the client side with authority to decide and real time to spend — typically 3–5 hours a week throughout. That is a genuine cost; budget it from the start.
3. Digitising a broken process as-is
If the current process has four approval steps only because nobody used to trust the numbers, putting all four into the software carries the problem to a new home and adds a bill.
Digitising a bad process just produces a bad process that runs faster and is harder to change.
How to avoid it: for each approval step, ask "what risk is this guarding against, and does the software already prevent it?" A great many approval steps disappear after that question.
4. Dirty data loaded into the new system
The product catalogue has three rows for the same item, units flip between "case" and "box", customers repeat under different codes. Load that as-is and every report is wrong, and users conclude "this software is inaccurate".
How to avoid it: make "data cleaning" its own line item in the plan, with an owner and acceptance criteria — no duplicate codes, every product with exactly one base unit.
5. Training treated as an afterthought
A 60-minute all-hands video call and a PDF handout is not training. Warehouse staff, cashiers and accountants use three different parts of the system at three different depths.
How to avoid it: train by job role, at the actual workplace, on their own real data. And always retrain after two or three weeks, once people have hit the awkward cases.
6. No parallel run
Switching the old system off on Monday and forcing everyone onto the new one that day is a gamble. One small fault in the first week is enough to lose confidence, and it is very hard to win back.
How to avoid it: run in parallel for 2–4 weeks with an explicit stopping rule, for example "three consecutive weeks where both sides agree and no blocking faults".
7. Nobody holds the keys after handover
The project ends, the team leaves, and the business has no source code, no documentation, no server access. A year later, changing one form means going back to that same team at whatever price they name.
How to avoid it: make handover of source code, operations documentation and admin accounts a condition of the final payment. More detail in Source code handover: why to insist.
A quick check before signing
- Is the scope written as a list of verifiable behaviours?
- Who decides on the client side, and how many hours a week do they have?
- Are data cleaning and migration inside the quoted price?
- Is the training plan split by job role?
- How many weeks of parallel running, and what is the stopping rule?
- Where in the contract is the source code handover clause?
Answer all six and most of the risk is already gone — whichever partner you choose.
Want to talk specifics?
SealCore surveys at your premises and sends a fixed quote after the first session — including when the conclusion is that you do not need custom software.
