Problems & fixes · Software procurement
Why software implementations fail or run late and how to prevent it
Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes
Short answer
Implementations falter less from technology than from unclear scope, poor data, weak ownership and underestimated change effort. Prevent trouble by defining outcomes and boundaries up front, cleaning data before migration, naming a business owner with decision authority, and planning training and adoption as seriously as configuration. When a project slips, reset scope and sequence rather than adding pressure.
Who this is for: A project sponsor or manager preparing to roll out a business system, or rescuing one that is stalling.
What to evaluate
Clear scope and outcomes
Vague goals invite continual additions and disagreement about what done means.
How to check: Write measurable success criteria and a list of what is explicitly out of scope.
Executive and business ownership
Decisions stall when nobody in the business can resolve trade-offs.
How to check: Name a sponsor and a day-to-day owner with authority and protected time.
Data quality and migration
Messy source data produces a messy system that users then distrust.
How to check: Profile data early, agree cleaning responsibility and rehearse migrations with realistic volumes.
Integration dependencies
Connections to other systems often hold hidden complexity.
How to check: Inventory integrations, owners and test environments in the first weeks.
Change management and training
A technically complete system still fails if people keep using old methods.
How to check: Plan role-based training, super-users and a support route for launch period.
Implementation partner fit
Experience in your industry and size reduces avoidable mistakes.
How to check: Speak with reference customers about slippage, staffing continuity and handling of change requests.
Comparison
| Pattern | Warning sign | Remedy |
|---|---|---|
| Scope creep | Constant extra requests with no trade-offs | Change control with explicit effects on time and effort |
| Dirty data | Repeated migration reruns and reconciliation errors | Cleanse at source and set data owners |
| Absent sponsor | Decisions waiting for weeks | Regular steering meetings with authority to decide |
| Poor adoption | Users keeping parallel spreadsheets | Training, champions and retiring the old process |
| Partner turnover | Changing consultants mid-project | Contract for key-person continuity |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 6 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Clear scope and outcomes | |||
| Executive and business ownership | |||
| Data quality and migration | |||
| Integration dependencies | |||
| Change management and training | |||
| Implementation partner fit | |||
| Total (max 18) | 0 | 0 | 0 |
Questions to ask before you commit
- What are the three outcomes that define success for this project?
- Who in the business can make final decisions on process questions?
- How will data be cleaned and who signs off migrated data?
- What are the dependencies on other systems and teams, and when are they available?
- Which tasks will our staff perform, and how much of their time is needed?
- How are change requests priced and approved?
- What does support look like for the first weeks after launch?
- What is the rollback plan if cutover fails?
Typical trade-offs
Phased rollout versus single cutover
- Upside
- Limits blast radius and lets you learn between phases.
- Downside
- Runs two systems for longer and prolongs the transition.
Configuring to existing process versus changing process to fit the product
- Upside
- Reduces disruption for staff.
- Downside
- Can import old inefficiencies and increase customisation.
Fixed scope contract versus time-and-materials
- Upside
- Cost predictability.
- Downside
- Rigid scope encourages disputes over changes.
Common mistakes
- Treating training as a final-week task; schedule it alongside testing so users help shape the system.
- Moving all data indiscriminately; migrate only what is needed and archive the rest.
- Skipping user acceptance testing with real scenarios; involve frontline staff early.
- Declaring victory at go-live; track adoption and issues for weeks afterward.
Related questions
What is the most common reason projects run late?
Delays usually trace back to decisions made slowly and data that is not ready. Technical configuration tends to proceed predictably, but waiting for approvals, resolving process disagreements, or fixing records in the legacy system consume schedule. Naming a decisive owner and starting data cleanup on day one address those causes more effectively than adding consultants.
Should we delay go-live if testing finds problems?
Compare the severity of open defects against the cost of delay. Issues that block core transactions, corrupt data or create compliance exposure justify postponing, while cosmetic or low-frequency items can be scheduled as follow-ups. Agree go-live criteria in advance with the sponsor so the decision rests on evidence instead of deadline pressure. Whatever you decide, write the reasoning down, name who is accountable for the follow-up, and revisit the choice after a realistic trial period so that early assumptions are tested against what actually happens in practice.
How can I tell if a project is in trouble early?
Watch for slipping milestones that are rebaselined repeatedly, growing lists of unresolved decisions, missing business participants in meetings, and testing that keeps moving later. Ask for a short, honest status from the people doing the work, not only the project manager summary, and be prepared to reduce scope or resequence work rather than hope for recovery.
Do we need an external implementation partner?
Not always. Partners help when your team lacks experience with the product or capacity for the work, but they cannot replace internal ownership of process decisions and data. If you hire one, define roles clearly, require named senior staff, and keep knowledge transfer in the plan so you are not dependent on them for routine changes after launch.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- Supply chain security guidance — National Cyber Security Centre, retrieved 27 October 2026
- Cybersecurity Framework — NIST, retrieved 27 October 2026
Related guides
How to choose · Software procurement
How to run a security review of a SaaS vendor
Scale the review to the data and access the vendor will have. Collect independent assurance reports, a completed security questionnaire and documentation on encryption, access control, incident response and subprocessors, then verify claims rather than accepting them. Focus on what the vendor does with your data, how it detects and reports incidents, and how you can exit with your data intact.
Requirements · Software procurement
SaaS contract terms to review and negotiate
Beyond price, the clauses that most affect outcomes are renewal and termination mechanics, data ownership and return, service levels and remedies, liability caps, security and breach commitments, and rules on price changes. Contract law varies by jurisdiction, so treat this as a checklist for conversation with counsel, not legal advice. Negotiate before signature, because leverage drops once data is in the system.
Comparison · Software procurement
Buy off-the-shelf software or build a custom tool
Buy when the process is common across companies, a mature product covers most of it, and speed matters. Build when the process is a source of competitive difference, existing products force awkward workarounds, and you can sustain engineering ownership over years. Hidden costs on both sides, integration and customisation for bought tools, maintenance and security for built ones, usually decide the outcome.
Cost factors · ERP
What drives ERP implementation cost and overruns
ERP cost is dominated by effort rather than licenses: scoping, data cleanup and migration, configuration, integration, customization, testing, training and change management. Overruns usually come from unclear scope, poor data, late requirement changes, and underestimated internal staff time. Budget by workload, hold contingency for discovery, and make scope decisions explicitly rather than letting them accrete.
Comparison · Business operations
Cloud POS versus on-premise POS
Cloud POS offers remote access, automatic updates and quicker setup but relies on connectivity and a subscription. On-premise systems run locally with fast response and independence from the internet but need servers, backups and technical support. Many modern hybrids cache locally. Choose according to connectivity reliability, technical capacity, number of sites and tolerance for vendor dependence.
Problems & fixes · Business operations
POS contract lock-in and the problems of switching systems
POS lock-in usually comes from bundled payment processing, long contract terms, leased or proprietary hardware, and data that is hard to export. Before leaving, inventory every dependency: payment agreement, hardware ownership, integrations, loyalty and gift card balances. Plan parallel running and a cutover during a quiet period. Negotiating these terms upfront prevents most of the pain.
How to choose · Business operations
How to choose expense management software
Pick expense software by how it handles receipt capture, policy enforcement, approval routing, accounting integration, reimbursement, tax and audit needs, and employee experience. Adoption determines the value, so test with real users. Compare how each tool treats multiple entities, currencies, card feeds and exports, and what happens to your data if you leave.