Let's start with some uncomfortable numbers.
McKinsey, in collaboration with Oxford University, found that large-scale IT implementations exceed their planned budgets by 45% on average. And 17% of those projects go so sideways they pose a real existential threat to the company. Not "we went a bit over budget." Existential. (Source)
Panorama Consulting Group found that roughly half of all ERP implementations require either a fundamental redesign of their original assumptions or abandonment of key functionalities - sometime after the project was already declared "done."
Boston Consulting Group puts it bluntly: 70% of digital transformations fail to achieve their goals. (Source1, Source2)
These aren't edge cases. This is the norm.
And the symptoms are always the same. Surprise invoices for "additional work" nobody mentioned upfront. Systems that technically work but don't solve any real problem. Employees who refuse to use the software - or worse, actively work around it. Data chaos that makes the old Excel spreadsheets look like a reliable single source of truth.
If you've ever been involved in rolling out software to a company, you know exactly what I'm talking about.
So what actually determines success or failure?
In 22 years in IT - working as a software architect for 11 of them, working on over 90 projects across industries from pharma to fashion to manufacturing, with clients from China to Switzerland - I've seen the same failure patterns repeat themselves over and over.
They fall into four buckets:
- vendor selection
- pre-implementation analysis
- infrastructure decisions
- collaboration
Today I want to focus on the one that poisons everything else before the project even starts: picking the wrong vendor.
The vendor mistakes that will cost you
They come in with a solution before understanding your problem
This one is a classic. The vendor walks in, does a 30-minute intro call, and immediately starts pitching their platform. They've already decided what you need. The actual problems your team faces daily? Not their concern.
A good vendor asks uncomfortable questions before they propose anything. A doctor doesn't schedule surgery without a diagnosis. A software architect shouldn't either.
You're pushing them for a fast quote - and they're happy to give you one
This goes both ways. Clients often pressure vendors for quick estimates based on minimal information. And some vendors are happy to oblige - which tells you everything you need to know.
A quick quote without proper analysis means one of three things: they're desperate for client, they lack experience, or they simply don't care about your actual challenges and just want to start coding. None of those are good.
Their team is either all seniors or all juniors
An all-senior team makes simple tasks absurdly expensive. An all-junior team makes complex tasks risky. A healthy vendor has a mixed structure - seniors architecting and leading, juniors executing the straightforward stuff. If the composition seems off, ask about it directly.
They ignore industry standards
Automated tests, proper coupling and cohesion, KISS, SOLID principles - these aren't optional extras, they're the baseline. There are benchmarks for all of this. If a vendor can't articulate their standards or gets defensive when you ask, that's a red flag.
You didn't check references - real ones
Not the curated case studies on their website. Talk to actual clients. Ask what went wrong, not just what went right. Every project has friction. A vendor who can't point you to clients willing to have an honest conversation about the experience is a vendor hiding something.
You're over-indexing on industry experience
Industry knowledge genuinely helps. A vendor who understands your domain communicates faster, asks better questions, and can shortcut certain design decisions because they've seen similar problems before. That's real value and it shouldn't be dismissed.
But here's the trap: industry familiarity alone is not a proxy for technical quality. And sometimes too much of it leads to lazy thinking: "well, at Company X we did it this way." You end up with a system that replicates what everyone else in your sector already has, instead of one built around your specific challenges.
Industry experience is a nice bonus. It should never be the primary reason you choose a vendor - and it should never compensate for weak technical fundamentals.
You chose them because they were cheapest
Public procurement is a perfect case study in this failure mode. Price wins the tender. Quality and long-term maintainability pay the price later. Cheap upfront almost always means expensive over time - either in fixes, rewrites, or the opportunity cost of a system that never quite does what you needed.
They claim to be good at everything
This one deserves its own section.
Some vendors - particularly (but not exclusively) firms from certain outsourcing hubs - will tell you they specialize in everything. Every technology, every domain, every stack. Ask them what they're best at and the answer is "all of it."
That's not a specialty. That's a sales pitch.
Real technical depth takes years to build. It requires communities of practice, accumulated patterns, internal standards, lessons learned from failures. A firm that claims universal expertise has none of that. They'll staff your project with whoever is available, not whoever is right for the job.
When evaluating vendors, always ask: what are you genuinely strongest in? If the answer is "everything," walk away.
You're looking for a vendor instead of a partner
This is the most important point on this list, so I saved it for last.
Digitalization is not a project with a finish line. It's a continuous process - and in a world where AI capabilities are evolving faster than most companies can absorb, that process is accelerating, not slowing down. You're not looking for a firm that will deliver a set of features and disappear. You're looking for someone who will understand your business deeply enough to help you grow it.
A real partner genuinely sees value in your success. Your growth is their growth. When your business scales, they scale with you. When you succeed, they get something more valuable than any case study on their website - they get a reference that opens doors.
That kind of relationship only works on one foundation: trust. And trust can't be faked, rushed, or written into a contract.
So before you evaluate technical skills, portfolios, or pricing - ask yourself whether you can actually trust these people. Because without that, nothing else on this list matters.
One underrated shortcut: Developer communities
Here's something most people outside tech don't know: the software industry has an unusually strong culture of knowledge sharing. Open source is everywhere - even at Microsoft (or so they claim, with a straight face). And in most cities, there are regular meetups where developers from different companies get together, share what they're working on, and network.
These communities are a goldmine for due diligence. Before you sign a contract, go to a meetup in your tech stack of choice and ask around. You'll get honest, unfiltered opinions about vendors faster than any RFP process will give you.
And don't be afraid of audits. Good vendors welcome external code reviews - their developers are proud of the work and happy to explain their decisions. Vendors who resist audits are usually the ones with something to hide.
The Bottom Line
Picking a vendor isn't a procurement exercise. It's the beginning of a relationship that will shape your company's technical capabilities for years - possibly decades. Get it wrong here and no amount of good intentions downstream will save you.
The checklist, before you sign anything:
- Do they have a real technical specialization - or do they claim to be good at everything?
- Did they push back on a quick quote, or were they suspiciously eager to give you one?
- Can they point you to clients willing to have an honest conversation?
- Is their team structure sensible - mixed seniority, not all one or the other?
- Do they have a presence in the developer community?
- Are they open to an external audit?
- And most importantly: can you trust them?
If the answers aren't satisfying, keep looking. The cost of switching vendors before you start is nothing compared to the cost of switching halfway through. And the cost of a bad partner is something you'll be paying long after the invoices stop coming.
Adam Piotrowski has 22 years in IT and has worked on 90+ projects across industries and continents as a programmer, team lead, and software architect. He also organizes Programistok - the largest developer conference in the Podlaskie region - and is one of the main organizers of Wroclove.rb.
