Project Management in IT Projects – What SMEs Should Do Differently

IT projects fail. That is not a new insight, and it happens in large corporations just as much as in SMEs. But the reasons differ. While enterprises often struggle with political dynamics, oversized governance structures, or endless approval loops, SMEs typically face something far more fundamental: a lack of functioning project management. Not perfect project management. Functioning project management.

That sounds harsh, but it reflects reality. In many SMEs, IT initiatives are launched without anyone clearly defining what exactly should be achieved, who is responsible, what the timeline looks like, and how to tell whether the project is on track. Instead, there is a vague idea, a motivated employee who takes on the topic as a side task, and the hope that everything will somehow work out. Sometimes it does. Usually it does not.

This article describes why traditional project management rarely fits SMEs, which elements are nevertheless indispensable, and how businesses can set up IT projects so they actually reach completion.

Why Traditional Project Management Rarely Works in SMEs

If you look at project management literature or certification programmes, you quickly encounter terms like project charter, stakeholder register, work breakdown structure, earned value analysis, or change advisory board. These are proven tools in environments designed for them. In a company with 500 or 5,000 employees, a dedicated PMO, and full-time project managers, such structures have their place.

In an SME with 20 to 150 employees, the world looks different. The project manager is often simultaneously a department head, IT coordinator, and operationally involved in day-to-day business. There is no PMO, no standardised reporting, no project management software that anyone maintains. And above all, there is no time for methodology for the sake of methodology.

The result: either traditional project management is introduced half-heartedly, with templates that are never touched after the kickoff, or it is abandoned entirely because it is perceived as bureaucratic and impractical. Both lead to the same problem: the project has no reliable steering mechanism.

The solution is not to abolish project management but to reduce it to its essentials. SMEs do not need a framework. They need clarity.

The Five Elements Every IT Project Needs

Regardless of size, methodology, or budget, there are five things without which an IT project is highly likely to run into trouble. They sound simple. In practice, they are regularly skipped.

A clear objective. What should be different at the end compared to today? Not "we are implementing a new ERP" but "we want to map our order processing from purchase order to invoice in a single system that all departments work with." The difference sounds subtle but is decisive. The first is a measure. The second is an objective. Measures can be changed if they do not work. Objectives provide orientation even when the path changes.

A clear objective also protects against one of the most common problems in IT projects: scope creep. When nobody knows precisely what the project is supposed to achieve, nobody can judge whether a new requirement belongs to the project or not. And so the project quietly and steadily grows until it collapses under its own weight.

One person who is responsible. Not a committee, not a department, not "we will do this together." One person who is authorised to make decisions, who has the overview, and who ensures that things move forward. In practice, this means a project manager with a clear mandate from senior management.

This does not mean that this person has to do everything alone. But they must be the final authority when questions remain open, priorities need to be set, or decisions are pending. Without this clarity, decisions are postponed, conflicts go unresolved, and tasks are not followed up. The project loses momentum and, eventually, relevance.

A realistic timeline. Realistic is the keyword. Most IT projects are launched with timelines based on optimistic assumptions: everything goes as planned, nobody falls ill, the vendor delivers on time, requirements do not change, employees have enough capacity alongside their daily work. In reality, none of this is true.

A good timeline acknowledges that delays are normal. It includes buffers, not as an excuse for laziness, but as a recognition of reality. And it is structured in phases with clear milestones where the team checks whether the project is still on track. If a milestone is missed, that is not the end of the world. It is a signal that requires a response, whether that means adjusting the plan, clarifying open points, or reassessing the scope.

Regular status checks. A project that runs for four months without anyone looking at it is not a project. It is an experiment. In SMEs, this does not require elaborate reporting. A short weekly status meeting of 20 to 30 minutes is enough. Three questions are at the centre: What has been completed since the last check? What is next? Where are there obstacles?

That sounds trivial. But the discipline of answering these three questions every week is the difference between a steered project and one that drifts along. The status check forces attention. And attention is the most important resource in project management, more important than any tool or framework.

A defined ending. Every project needs a conclusion. In practice, it happens surprisingly often that IT projects are never formally closed. The solution is deployed, a few loose ends remain, at some point nobody talks about the project anymore, but it was never officially finished. This is problematic because open projects tie up resources, leave expectations unclear, and nobody takes responsibility for the transition to operations.

A clean project closure involves three things: an acceptance of what was delivered, documentation of open items that transition into operations, and a brief reflection on what went well and what should be done better next time. It does not take hours. But it closes a chapter and creates clarity.

The Biggest Mistake: Project Management as a Side Job

In many SMEs, IT project management is treated as a task that can be handled alongside day-to-day operations. The IT manager is supposed to implement the new CRM on top of helpdesk management, infrastructure, and vendor relations. The department head is supposed to define requirements alongside budget planning, people management, and operational decisions. That cannot work.

Project management requires time. Not full-time, but regular, protected time. When the project manager only thinks about the project in the gaps between meetings and daily tasks, that is precisely what happens: they think about it rather than steering it. Tasks are not followed up, decisions are not demanded, risks are not identified.

The solution does not have to be expensive. In many cases, reserving two to four hours per week as dedicated project time is enough. During these hours, the project plan gets updated, open items are addressed, and conversations with stakeholders take place. This changes the dynamic fundamentally. A project that receives regular attention stays in motion. One that gets squeezed into the gaps falls asleep.

Agile or Traditional – The Wrong Question

In discussions about project management, the question inevitably comes up: agile or traditional? Scrum or waterfall? Sprints or phases? For most SMEs, this question is irrelevant. Not because the methods are bad, but because the prerequisites for rigorous implementation are rarely in place.

Agile methods like Scrum work brilliantly when a dedicated team works in short cycles, delivers regularly, and collaborates closely with the client. In an SME where project participants are simultaneously immersed in daily operations, there is rarely a dedicated team. And traditional waterfall planning works when requirements are clear at the outset and do not change significantly, which is almost never the case in IT projects.

The pragmatic answer for most SMEs lies somewhere in between. You plan in phases but not rigidly. You adjust the plan when reality changes. You work in manageable segments and regularly check whether the direction is still right. That is not a methodological failure. It is common sense applied to project work.

More important than the choice of methodology is the consistency with which you implement it. A simple approach executed consistently beats every sophisticated framework that disappears into daily routine after two weeks.

What a Good Project Manager in SMEs Actually Needs

The requirements for project managers in SMEs differ fundamentally from those in large enterprises. Certifications and methodological knowledge are useful but not decisive. What matters in SMEs are different skills.

Communication. In an SME, everyone knows everyone. Conflicts quickly become personal, and information flows through hallways rather than formal channels. A good project manager can communicate clearly in this environment without seeming bureaucratic. They bring the right people to the table, ensure that decisions are made and documented, and keep all stakeholders informed without drowning them in reports.

Pragmatism. In an SME, there are neither the resources nor the patience for theoretically perfect solutions. The project manager must recognise where the 80 percent solution is good enough and where the final 20 percent makes the difference. They must be able to make compromises without losing sight of the objective.

Assertiveness. In an environment where daily operations always seem more urgent than the project, someone needs to keep the project on the agenda. Someone who demands that committed deadlines are met. Someone who escalates when blockers are not resolved. This requires backbone and the mandate from senior management to use it.

Domain understanding. The project manager does not need to be a developer. But they need to understand what the project is about. They must be able to speak with the IT vendor on equal footing, assess risks, and challenge proposals. Without this basic understanding, they become a mere administrator, and that is not enough to steer a project.

The Vendor as Partner – Not as Problem Solver

In many SMEs, the external IT vendor is viewed not just as a technical implementer but also as the de facto project manager. That is understandable since the vendor has experience with such projects. But it is risky.

A vendor naturally has different interests from the company itself. They want to complete the project successfully, but they do not know the internal processes, political dynamics, and real priorities of the business as well as someone who works there. And they have little influence on whether employees adopt the new system, whether management stands behind the project, and whether internal deliverables arrive on time.

Project governance must remain with the company. The vendor is an important partner who provides expert advice, handles technical implementation, and contributes experience. But responsibility for the project's success, meaning that the result actually works within the organisation, cannot be outsourced. The company must own that itself.

Conclusion: Less Methodology, More Consistency

SMEs do not need an elaborate project management framework to deliver IT projects successfully. What they need is the opposite of complexity: clarity about the objective, one responsible person, a realistic plan, regular status checks, and a clean closure. Five things. None of them require special software, expensive certifications, or weeks of preparation.

The decisive factor is not the method. It is consistency. An IT project that is steered weekly, that has clear responsibilities, and that is supported by senior management has a good chance of success, regardless of whether it is run in an agile, traditional, or hybrid fashion.

And that is perhaps the most important insight for SMEs: project management is not an additional burden. It is what ensures that the actual work is not done in vain.