A project that falls behind schedule always starts the same way. The first few weeks go well. The service provider is motivated, the team is engaged, and the timeline is on track. Then, at some point—often after the first follow-up meeting—things start to grind to a halt. Approvals drag on. The scope creeps imperceptibly. And four months later, you’re looking at a project that was supposed to take two months and still isn't delivered. This isn't bad luck: it’s a scenario that repeats itself in almost every IT project that fails in an SME.
In most cases, the reason an IT project fails has nothing to do with the technology chosen. It’s not a fundamental bug, bad software, or an incompetent provider. The problem is almost always organizational.
The Standish Group, which has been tracking IT project success rates since the 90s, has identified the same causes for failure for thirty years: poorly defined scope, lack of a decision-making sponsor, insufficient client-side resources, and stalled approvals. These are purely human and governance issues.
For an SME, this is even more true. Your employees wear many hats. No one is really steering the ship because no one has the time to do it full-time.
Vague scope. This is the number one cause. A project that starts without a clear, validated list of what is included—and, more importantly, what is not—always ends up ballooning. This phenomenon has a name: scope creep. It results from one thing: the absence of a formalized "no" from the very beginning.
Lack of an internal sponsor. Every IT project needs a decision-maker on the client side—someone with the authority to approve choices, unlock resources, and make final calls. Without this sponsor, the project drifts, and the service provider ends up making decisions for you; sometimes they’re the right ones, often they aren't.
Stalled approval workflows. For an ERP, you need the CFO for accounting, the warehouse manager for logistics, and the lead sales representative for the client interface. These people are never available at the same time: each approval takes two weeks instead of two days. Over a six-month project, that adds up to weeks of slippage.
Lack of initial documentation. Three months after launch, no one remembers exactly what was planned, what changed, or why. When a disagreement arises, the only basis for discussion is everyone’s memory, and those memories never match.
A 45-person distribution SME launches an ERP migration. Budget: 90,000 CHF, planned duration: eight months. On the client side, the CEO oversees the project in addition to their daily responsibilities.
Six months later, the ERP is not in production. The scope has changed three times, two modules were added without an amendment, the logistics manager is bypassing the new system with old Excel files, the integrator has been waiting for approvals for five weeks, and the budget is 30% over. This isn't anyone's fault in particular: it is the direct consequence of not having a dedicated project manager.
A project manager would have done three simple things: lock in the scope in writing from the start, set up a monthly steering committee with the right decision-makers, and ensure that every approval has a deadline and a named owner. This isn't high-tech; it’s organizational rigor.
For an SME with 30 to 80 employees, a full-time IT project manager is rarely justifiable between projects. This is where external support makes sense: for an 80,000 CHF project, dedicating 8 to 12% of the budget to structured external management is often the difference between a project delivered on time and one that drifts by 40%. Not sure what level of support is right for your situation? Our simulator will guide you in 2 minutes.
Project management support does not replace your integrator. It sits between you and them, ensuring someone is formally responsible for keeping things moving forward.
Designate a specific internal sponsor with the authority to approve and make decisions. Write a scoping document (one page covering objectives, scope, exclusions, milestones, and acceptance criteria). Establish a regular management rhythm with written reports. And systematically refuse any scope changes that haven't been formalized in writing.
Successful projects aren't the ones that didn't have problems. They are the ones where someone had the responsibility and authority to fix them.
