When a supply chain transformation project fails or stalls halfway, the first thing that usually gets blamed is the chosen technology — 'the system wasn't the right fit,' 'the implementation wasn't done properly.' In our experience, though, in the overwhelming majority of cases, the real cause has nothing to do with technology. It usually lies in three non-technical prerequisites that got skipped before the project even started.
The first prerequisite is clarity in problem definition. Many transformation projects kick off with a broad statement like 'we need to digitize our supply chain' or 'we need to become more agile,' without pinning down exactly which decision or which process is supposed to get better. Without a precise problem definition — say, 'reduce our response time to a demand shift from 3 weeks to 3 days' — there's no way to measure success, and the implementation team can justify almost any technical choice along the way.
The second prerequisite is data readiness, not technology readiness. Most organizations starting a digital transformation project assume their existing data is clean and structured enough to load into a new system. The reality is usually the opposite: duplicate item codes, inconsistent units of measure, outdated BOMs that were never maintained. If these issues aren't identified and fixed before the project, the new system just repeats the old disorder, faster.
The third — and perhaps most important — prerequisite is organizational readiness to change how decisions actually get made. New technologies (an advanced planning engine, an analytics dashboard) typically require people to decide differently than before: less on gut feel and tenure, more on system output. If the organizational culture hasn't been prepared for that shift, even the best system gets quietly ignored, and users revert to their old method — usually a parallel spreadsheet.
The common symptom of all three problems is a pattern we've seen repeatedly: the project launches with plenty of budget and enthusiasm, the technical implementation phase goes roughly to plan, but six months after go-live it turns out real users are running the new system alongside their old methods, not instead of them. Technically, the project was 'delivered.' From a business standpoint, it hasn't actually happened yet.
The approach we use when designing transformation projects checks these three prerequisites during the diagnostic phase, before any technology is selected. That means interviewing the actual decision-makers to pin down the problem precisely, auditing data quality before any technical investment is made, and designing a gradual path for changing decision behavior instead of expecting it to shift overnight.
A related mistake is letting vendor-selection pressure compress the diagnostic phase. Once a shortlist of vendors is engaged, internal momentum builds quickly, and skipping the problem-definition and data-readiness work starts to feel like the pragmatic choice under deadline pressure. In practice, this is exactly when skipping those steps becomes most expensive, because contract terms and implementation scope get locked in before the real requirements are even clear.
Before signing any transformation contract, it's worth running a short internal check: can every stakeholder state, in one sentence, which decision will improve and by how much? Has someone outside the IT team actually opened and reviewed a sample of the real production data? And has at least one small pilot been run with actual end users, not just a demo environment? If the answer to any of these is no, the project isn't ready for a vendor contract yet.
In the end, picking the right platform or software still matters — but only once these three prerequisites are in place. Organizations that invest the time in this 'before the technology' stage typically end up with a faster, cheaper project and a genuinely higher adoption rate — not because they picked better technology, but because they prepared the ground properly first.