Projektmanagement in IT-Projekten – was KMU anders machen sollten

IT-Projekte scheitern. Das ist keine neue Erkenntnis, und es trifft Grossunternehmen genauso wie KMU. Aber die Gründe unterscheiden sich. Während in Konzernen oft politische Dynamiken, überdimensionierte Governance-Strukturen oder endlose Abstimmungsschleifen zum Problem werden, liegt es in KMU meistens an etwas viel Grundlegenderem: Es fehlt an einem funktionierenden Projektmanagement. Nicht an einem perfekten. An einem funktionierenden.

Das klingt hart, ist aber Realität. In vielen KMU werden IT-Vorhaben gestartet, ohne dass jemand klar definiert hat, was genau erreicht werden soll, wer verantwortlich ist, wie der Zeitplan aussieht und woran man erkennt, ob das Projekt auf Kurs ist. Stattdessen gibt es eine vage Idee, einen motivierten Mitarbeitenden, der das Thema «nebenbei» übernimmt, und die Hoffnung, dass sich der Rest schon irgendwie ergibt. Manchmal funktioniert das. Meistens nicht.

Dieser Beitrag beschreibt, warum klassisches Projektmanagement für KMU selten passt, welche Elemente trotzdem unverzichtbar sind und wie Unternehmen IT-Projekte so aufsetzen, dass sie tatsächlich zum Abschluss kommen.

Warum klassisches Projektmanagement in KMU selten funktioniert

Wenn man sich Fachliteratur oder Zertifizierungsprogramme zum Thema Projektmanagement ansieht, begegnet man schnell Begriffen wie Projektcharter, Stakeholder-Register, Work Breakdown Structure, Earned Value Analysis oder Change Advisory Board. Das sind bewährte Werkzeuge – in Umgebungen, die dafür ausgelegt sind. In einem Unternehmen mit 500 oder 5'000 Mitarbeitenden, dediziertem PMO und Vollzeit-Projektleitern haben solche Strukturen ihren Platz.

In einem KMU mit 20 bis 150 Mitarbeitenden sieht die Welt anders aus. Der Projektleiter ist oft gleichzeitig Fachbereichsleiter, IT-Koordinator und operativ eingebunden. Es gibt kein PMO, kein standardisiertes Reporting, keine Projektmanagement-Software, die jemand pflegt. Und vor allem gibt es keine Zeit für Methodik um der Methodik willen.

Das Ergebnis: Entweder wird klassisches Projektmanagement halbherzig eingeführt – mit Templates, die nach dem Kickoff nie wieder angefasst werden – oder es wird ganz darauf verzichtet, weil es als bürokratisch und praxisfern wahrgenommen wird. Beides führt zum gleichen Problem: Das Projekt hat keine verlässliche Steuerung.

Die Lösung liegt nicht darin, Projektmanagement abzuschaffen, sondern es auf das Wesentliche zu reduzieren. KMU brauchen kein Framework. Sie brauchen Klarheit.

Die fünf Elemente, die jedes IT-Projekt braucht

Unabhängig von Grösse, Methodik oder Budget gibt es fünf Dinge, ohne die ein IT-Projekt mit hoher Wahrscheinlichkeit in Schwierigkeiten gerät. Sie klingen einfach. In der Praxis werden sie trotzdem regelmässig übersprungen.

Ein klares Ziel. Was soll am Ende anders sein als heute? Nicht «wir führen ein neues ERP ein», sondern «wir wollen unsere Auftragsabwicklung von der Bestellung bis zur Rechnung in einem System abbilden, mit dem alle Abteilungen arbeiten». Der Unterschied klingt subtil, ist aber entscheidend. Das erste ist eine Massnahme. Das zweite ist ein Ziel. Massnahmen kann man ändern, wenn sie nicht funktionieren. Ziele geben Orientierung, auch wenn der Weg sich ändert.

Ein klares Ziel schützt auch vor einem der häufigsten Probleme in IT-Projekten: dem schleichenden Wachstum des Projektumfangs. Wenn niemand genau weiss, was das Projekt erreichen soll, kann auch niemand beurteilen, ob eine neue Anforderung dazugehört oder nicht. Und so wächst das Projekt still und stetig, bis es unter seinem eigenen Gewicht zusammenbricht.

Eine Person, die verantwortlich ist. Nicht ein Gremium, nicht eine Abteilung, nicht «wir machen das zusammen». Eine Person, die entscheiden darf, die den Überblick hat und die dafür sorgt, dass Dinge vorwärtsgehen. In der Praxis heisst das: ein Projektleiter oder eine Projektleiterin mit einem klaren Mandat der Geschäftsleitung.

Das bedeutet nicht, dass diese Person alles allein machen muss. Aber sie muss die letzte Instanz sein, wenn Fragen offen sind, Prioritäten gesetzt werden müssen oder Entscheidungen anstehen. Ohne diese Klarheit werden Entscheidungen aufgeschoben, Konflikte nicht gelöst und Aufgaben nicht nachverfolgt. Das Projekt verliert an Tempo – und irgendwann an Relevanz.

Ein realistischer Zeitplan. Realistisch ist das Schlüsselwort. Die meisten IT-Projekte werden mit Zeitplänen gestartet, die auf optimistischen Annahmen basieren: Alles läuft wie geplant, niemand wird krank, der Dienstleister liefert pünktlich, die Anforderungen ändern sich nicht, die Mitarbeitenden haben neben dem Tagesgeschäft genügend Kapazität. In der Realität trifft nichts davon zu.

Ein guter Zeitplan berücksichtigt, dass Verzögerungen normal sind. Er enthält Puffer – nicht als Ausrede für Faulheit, sondern als Anerkennung der Realität. Und er ist in Phasen gegliedert, mit klaren Meilensteinen, an denen überprüft wird, ob das Projekt noch auf Kurs ist. Wenn ein Meilenstein nicht erreicht wird, ist das kein Weltuntergang. Es ist ein Signal, das eine Reaktion erfordert – sei es eine Anpassung des Plans, eine Klärung offener Punkte oder eine Neubewertung des Umfangs.

Regelmässige Standortbestimmung. Ein Projekt, das man vier Monate lang laufen lässt, ohne hinzuschauen, ist kein Projekt. Es ist ein Experiment. In KMU reicht dafür kein aufwendiges Reporting. Ein kurzes, wöchentliches Statusgespräch von 20 bis 30 Minuten genügt. Drei Fragen stehen im Zentrum: Was wurde seit dem letzten Mal erledigt? Was steht als Nächstes an? Wo gibt es Hindernisse?

Das klingt banal. Aber die Disziplin, diese drei Fragen jede Woche zu beantworten, ist der Unterschied zwischen einem gesteuerten Projekt und einem, das vor sich hindriftet. Die Standortbestimmung erzwingt Aufmerksamkeit. Und Aufmerksamkeit ist die wichtigste Ressource im Projektmanagement – wichtiger als jedes Tool und jedes Framework.

Ein definiertes Ende. Jedes Projekt braucht einen Abschluss. In der Praxis passiert es erstaunlich oft, dass IT-Projekte nie formal abgeschlossen werden. Die Lösung wird eingeführt, ein paar Nacharbeiten bleiben liegen, irgendwann spricht niemand mehr vom Projekt, aber offiziell beendet wurde es nie. Das ist problematisch, weil offene Projekte Ressourcen binden, Erwartungen unklar lassen und niemand Verantwortung für den Übergang in den Betrieb übernimmt.

Ein sauberer Projektabschluss umfasst drei Dinge: eine Abnahme dessen, was geliefert wurde, eine Dokumentation der offenen Punkte, die in den Betrieb übergehen, und eine kurze Reflexion darüber, was gut lief und was beim nächsten Mal besser gemacht werden sollte. Das dauert keine Stunden. Aber es schliesst ein Kapitel und schafft Klarheit.

Der grösste Fehler: Projektmanagement als Nebenjob

In vielen KMU wird IT-Projektmanagement behandelt wie eine Aufgabe, die man neben dem Tagesgeschäft erledigen kann. Der IT-Leiter soll das neue CRM einführen – neben Helpdesk, Infrastruktur und Lieferantenmanagement. Die Abteilungsleiterin soll die Anforderungen definieren – neben Budgetplanung, Personalführung und operativen Entscheidungen. Das kann nicht funktionieren.

Projektmanagement braucht Zeit. Nicht Vollzeit, aber regelmässige, geschützte Zeit. Wenn der Projektleiter jede Woche nur in den Lücken zwischen Meetings und Tagesgeschäft an das Projekt denkt, passiert genau das: Er denkt daran, statt es zu steuern. Aufgaben werden nicht nachverfolgt, Entscheidungen nicht eingefordert, Risiken nicht erkannt.

Die Lösung muss nicht teuer sein. In vielen Fällen reicht es, zwei bis vier Stunden pro Woche als feste Projektzeit zu reservieren. In diesen Stunden wird der Projektplan aktualisiert, werden offene Punkte bearbeitet, werden Gespräche mit Beteiligten geführt. Das verändert die Dynamik grundlegend. Denn ein Projekt, das regelmässig Aufmerksamkeit bekommt, bleibt in Bewegung. Eines, das in die Lücken geschoben wird, schläft ein.

Agil oder klassisch – die falsche Frage

In Diskussionen über Projektmanagement fällt früher oder später die Frage: agil oder klassisch? Scrum oder Wasserfall? Sprints oder Phasen? Für die meisten KMU ist diese Frage irrelevant. Nicht weil die Methoden schlecht wären, sondern weil die Voraussetzungen für eine konsequente Umsetzung selten gegeben sind.

Agile Methoden wie Scrum funktionieren hervorragend, wenn ein dediziertes Team in kurzen Zyklen arbeitet, regelmässig liefert und eng mit dem Auftraggeber zusammenarbeitet. In einem KMU, in dem die Projektbeteiligten gleichzeitig im Tagesgeschäft stecken, gibt es selten ein dediziertes Team. Und klassische Wasserfallplanung funktioniert, wenn die Anforderungen zu Beginn klar sind und sich nicht wesentlich ändern – was bei IT-Projekten fast nie der Fall ist.

Die pragmatische Antwort für die meisten KMU liegt irgendwo dazwischen. Man plant in Phasen, aber nicht starr. Man passt den Plan an, wenn sich die Realität ändert. Man arbeitet in überschaubaren Abschnitten und überprüft regelmässig, ob die Richtung stimmt. Das ist kein Methodenbruch. Das ist gesunder Menschenverstand, angewandt auf Projektarbeit.

Wichtiger als die Wahl der Methodik ist die Konsequenz, mit der man sie umsetzt. Ein einfacher Ansatz, der konsequent durchgezogen wird, schlägt jedes ausgefeilte Framework, das nach zwei Wochen im Alltag untergeht.

Was ein guter Projektleiter in KMU wirklich können muss

Die Anforderungen an Projektleiter in KMU unterscheiden sich grundlegend von denen in Grossunternehmen. Zertifizierungen und Methodenwissen sind nützlich, aber nicht entscheidend. Was in KMU zählt, sind andere Fähigkeiten.

Kommunikation. In einem KMU kennt jeder jeden. Konflikte werden schnell persönlich, Informationen fliessen über den Flur statt über formale Kanäle. Ein guter Projektleiter kann in diesem Umfeld klar kommunizieren, ohne bürokratisch zu wirken. Er bringt die richtigen Leute an einen Tisch, sorgt dafür, dass Entscheidungen getroffen und festgehalten werden, und hält alle Beteiligten informiert – ohne sie mit Reports zu überschwemmen.

Pragmatismus. In einem KMU gibt es weder die Ressourcen noch die Geduld für theoretisch perfekte Lösungen. Der Projektleiter muss erkennen, wo die 80-Prozent-Lösung reicht und wo die letzten 20 Prozent den Unterschied machen. Er muss Kompromisse eingehen können, ohne das Ziel aus den Augen zu verlieren.

Durchsetzungsvermögen. In einem Umfeld, in dem das Tagesgeschäft immer dringender erscheint als das Projekt, braucht es jemanden, der das Projekt auf der Agenda hält. Der einfordert, dass zugesagte Termine eingehalten werden. Der eskaliert, wenn Blockaden nicht aufgelöst werden. Das erfordert Rückgrat – und das Mandat der Geschäftsleitung, um es einzusetzen.

Fachliches Verständnis. Der Projektleiter muss kein Entwickler sein. Aber er muss verstehen, worum es geht. Er muss in der Lage sein, mit dem IT-Dienstleister auf Augenhöhe zu sprechen, Risiken einzuschätzen und Vorschläge zu hinterfragen. Ohne dieses Grundverständnis wird er zum reinen Administrator – und das reicht nicht, um ein Projekt zu steuern.

Der Dienstleister als Partner – nicht als Problemlöser

In vielen KMU wird der externe IT-Dienstleister nicht nur als technischer Umsetzer, sondern auch als de facto Projektleiter betrachtet. Das ist verständlich – schliesslich hat der Dienstleister Erfahrung mit solchen Projekten. Aber es ist riskant.

Ein Dienstleister hat naturgemäss andere Interessen als das Unternehmen. Er will das Projekt erfolgreich abschliessen, aber er kennt die internen Abläufe, die politischen Dynamiken und die realen Prioritäten des Unternehmens nicht so gut wie jemand, der dort arbeitet. Und er hat wenig Einfluss darauf, ob die Mitarbeitenden das neue System annehmen, ob die Geschäftsleitung hinter dem Projekt steht und ob die internen Zuarbeiten rechtzeitig kommen.

Die Projektsteuerung muss beim Unternehmen selbst liegen. Der Dienstleister ist ein wichtiger Partner, der fachlich berät, technisch umsetzt und Erfahrung einbringt. Aber die Verantwortung für den Projekterfolg – also dafür, dass am Ende etwas herauskommt, das im Unternehmen funktioniert – kann er nicht übernehmen. Das muss das Unternehmen selbst tun.

Fazit: Weniger Methodik, mehr Konsequenz

KMU brauchen kein aufwendiges Projektmanagement-Framework, um IT-Projekte erfolgreich umzusetzen. Was sie brauchen, ist das Gegenteil von Komplexität: Klarheit über das Ziel, eine verantwortliche Person, einen realistischen Plan, regelmässige Standortbestimmungen und einen sauberen Abschluss. Fünf Dinge. Keine davon erfordert spezielle Software, teure Zertifizierungen oder wochenlange Vorbereitungen.

Der entscheidende Faktor ist nicht die Methode. Es ist die Konsequenz. Ein IT-Projekt, das wöchentlich gesteuert wird, das klare Verantwortlichkeiten hat und das von der Geschäftsleitung getragen wird, hat gute Chancen auf Erfolg – unabhängig davon, ob es agil, klassisch oder irgendwo dazwischen geführt wird.

Und das ist vielleicht die wichtigste Erkenntnis für KMU: Projektmanagement ist keine zusätzliche Last. Es ist das, was dafür sorgt, dass die eigentliche Arbeit nicht umsonst ist.