+32 473 52 49 31Mon–Fri · 08:30–18:00
Prefer to talk it through first? Just give us a call.
Make IT So

Blog · Programme management

A realistic timeline for digitalisation: why SMEs systematically plan too optimistically

On average, SMEs underestimate digitalisation projects by 40%. Not out of ignorance, but because they underestimate the invisible complexity. Here is a rule of thumb to correct for that.

A realistic timeline for digitalisation: why SMEs systematically plan too optimistically

A CEO from Ghent asked a question we hear every month:

'Walter, we want to completely overhaul our CRM systemA system for managing customer relationships and sales in one clear overview.. How much time do we need? Three months?'

We have seen this pattern countless times: on average, SMEs estimate their digitalisationHelping your organisation work smarter with technology, not as an IT project but as a way of working. projects 40% too optimistically. Not because they are naive, but because they underestimate the invisible complexity.

And that CEO from Ghent? Realistically, his 'three-month project' would take thirteen and a half months. Not because we work slowly, but because real transformation needs time to sink in with people.

The planning illusion every SME falls for

The problem is always the same: business owners think in system time, not in people time. They see the technical implementation, but forget that digitalisation is really change managementBringing people along with a change, so that new ways of working actually stick. with an IT component on top.

A wholesaler in Antwerp wanted to digitalise its stock management. Installing the software took two weeks. Teaching the team to work with it took four weeks. Adapting the process so that it really worked within their existing workflow took three months. That last step is the one most SMEs leave out of their planning entirely.

Three hidden time sinks

  • Process discovery. Before you set up a system, you need to know how things really run today, not how they appear on an organisation chart. Allow at least two to four weeks for what nobody likes to admit: nobody knows the whole process.
  • Edge cases and exceptions. The standard path is 80% of the work in 20% of the time. The other 80% of the time goes on exceptions, error recovery and customers who are different from 'normal'. Many software vendors only plan for the standard path.
  • Getting people used to it. It takes three to six months for new habits to really stick. Until then, the old and the new system run in parallel, and someone has to make sure nothing falls through the cracks.

The 3 x 2 rule that does hold up

Our rule of thumb after twenty years of trial and error:

  1. Multiply the technical estimate by 3 to get the real implementation time. The supplier says two months? Plan for six. Not because they are lying, but because their estimate only covers the happy path.
  2. Then add another 50% for the people side. Train, support, correct, repeat. This happens in parallel with phase 1, but carries on until long after go-live. Count on three to six extra months after technical delivery.

The CEO from Ghent at the start? His original estimate was three months. Times 3 makes 9 months of technical work. Plus 4.5 months for the people side makes 13.5 months in total. We split the project into phases and started with a three-month proof of concept. Eight months later, phase two is up and running. Everything is going to plan, because the plan followed reality, not the other way round.

Why a phased rollout saves you

Most SMEs want everything at once. That's understandable, because the current situation is frustrating. But everything at once is a recipe for crisis. What does work:

  1. Phase 0: proof of concept. Eight to twelve weeks, covering a small part of the business and a small part of the system. The goal is to prove that the solution fits, not that it scales.
  2. Phase 1: core rollout. Three to four months for the main process (often sales or logistics). This is where the first real habits start to form.
  3. Phase 2: extension modules. Three to six months for accounting, reporting and integrations with suppliers. Only build these once the core rollout is running smoothly.
  4. Phase 3: optimisation. Ongoing, based on what the team actually uses versus what was in the specification. This is often where you drop features.

The hidden costs nobody mentions

It's not only about time, but also about money. Belgian SMEs consistently underestimate the total cost of digitalisation projects. This is what most budgets leave out:

  • Process analysis and discovery before the quote
  • Cleaning up data from old systems
  • Integrations with existing tools (accounting, email, online shop)
  • Training and support during the first 6 months
  • Loss of productivity during the transition
  • Adjustments after the first 3 months of use (there are always some)

For a typical SME digitalisation of 50,000 euros, you realistically end up at 65,000 to 70,000 all-in. That's not meant to scare you off, but to prepare you. A budget with no reserve for the last 30% isn't a budget. It's hope.

How do you know whether your planning is realistic?

Four warning signs that, in our experience, point to unrealistic planning:

  1. No time for process discovery. If the plan starts with 'supplier comes to install' without a discovery phase before it, you're missing half the work.
  2. No room for a pilot. Everything is rolled out in one go, with no phase 0. There's a high chance of a crisis in month 3.
  3. Training in two days. Training is not the same as getting used to something. Count on three to six months for real adoption. Two days of training is a kick-off, not a finish.
  4. The vendor claims it's 'turnkey'. IT projects are never turnkey. Whoever promises that has left something out of the plan.

What now?

Do you recognise yourself in this story? The good news is that realistic planning is not a talent but a skill. And it saves you a great deal of stress, money and internal frustration when phase 2 isn't ready on time.

Start with this one conversation with your team: how much time have we really spent on IT projects in the past? Not what was in the quote, but what did it really cost? That figure is your new planning baseline. For future projects, you now know that the quote is only one of the three variables.