Digital transformation

Why IT projects in SMEs fail to meet deadlines and budgets

"We had estimated six months. Fourteen have passed."

I've heard it so many times that at some point I stopped being surprised. What still surprises me is the explanation that almost always accompanies that sentence: "The supplier did not meet the deadline." Or: "The software had issues." Rarely does anyone look the other way.

The numbers

Large IT projects run over budget by an average of 45% and deliver 56% less value than promised. (Source: McKinsey & University of Oxford, study of 5,400 IT projects)

The Chaos Report by the Standish Group, which analyzes the outcomes of over 50,000 global IT projects, shows that only 31% of projects are completed successfully, delivered on time and within budget.

These data mainly concern large organizations. But SMEs are not immune. Indeed, they often pay a higher price because they have fewer resources to absorb errors and less structure to intercept them in time.

The official causes and the real ones

When an IT project slips, the official diagnosis tends to converge on some standard explanations: requirements changed along the way, unforeseen technical problems, difficulties in integrating with existing systems.

These things happen. But they are symptoms, not causes.

In my experience on the field, the real causes are almost always three other things.

The first is that no one actually owns it.

An IT project in an SME typically involves IT, the business area involved, management, and the vendor. Everyone has their own priorities, their own timing, their own language. If there is no person with an explicit mandate who holds these worlds together and makes decisions when things get stuck, the project slows down. Every decision bounces between different functions, emails pile up, problems remain unresolved for weeks.

It is not incompetence. It is an absence of governance.

The second: requirements are written before understanding the problem

One of the most costly mistakes I see is the writing of detailed technical specifications at a stage when the company does not yet truly understand what it wants to achieve. Functionalities are described, modules are listed, integrations are defined. But the question "what problem are we solving and how do we measure success?" often remains without a precise answer.

The result is that halfway through the project, needs emerge that no one had considered, requirements change, the vendor extends timelines and increases costs. Not out of bad faith, but because the problem was poorly defined from the very beginning.

The third: the project is not managed on a daily basis

An IT project does not move forward on its own. It needs someone to track progress week by week, to intercept signs of slowdown before they become emergencies, and to keep all the involved actors aligned.

In SMEs, this figure often does not exist or is part-time relative to the project. The result is that problems emerge late, when the delay is already consolidated and recovering from it costs much more than preventing it.

The warning sign that is always ignored

There is a precise moment when almost every project I have seen go wrong could still have been saved. It is called the "first month of silence."

In the first few weeks after the kick-off, there is always movement: meetings, document exchanges, enthusiasm. Then, around the fourth or fifth week, a slowdown arrives. No news from the vendor for days, some emails left unanswered, a date pushed back by a week "to align schedules."

That silence is the signal. If it is not intercepted and addressed immediately, it becomes the pattern for the entire project.

What changes in projects that work

IT projects that meet timelines and budgets in SMEs are not those with the best vendors or the most advanced technologies. They are those in which someone, from the inside, has taken responsibility for the progress, not of the technical part, but of making things actually happen.

Three questions to ask before approving any IT project:

Who is the internal person monitoring progress each week, first and last name?

How do we measure success in six months, in terms of business and not in terms of features delivered?

What is the decision-making process when problems emerge? Who decides, in what timeframe, with what mandate?

If these questions do not have a precise answer before the project starts, the probability of exceeding time and budget is very high, regardless of the quality of the chosen vendor.

Have you experienced an IT project that exceeded its schedule or budget? Looking back, what was the real cause?

If you want to understand where your projects get stuck, book a call, no commitment, just a concrete conversation.

*Marco De Vecchi is a Fractional Executive specialized in digital transformation for Italian SMEs. He has led digital projects in highly complex contexts such as Ferrari, the Italian Navy, ENI, and the Presidency of the Council of Ministers.*