Woran IT-Projekte im Mittelstand scheitern

IT-Projekte im Mittelstand scheitern selten an der Technik. Sie scheitern an unklarem Umfang, der sich erst während der Umsetzung als unklar herausstellt, an fehlenden Ansprechpartnern auf Kundenseite, an einem Umbau im laufenden Betrieb ohne Rückfallplan, an einer Abnahme ohne vollständige Dokumentation und daran, dass nach Projektabschluss niemand mehr klar zuständig ist. Die Technik funktioniert in den meisten Fällen am Ende – das Projekt scheitert trotzdem, weil diese fünf Punkte im Vorfeld nicht geklärt wurden.

Unklarer Umfang

Der häufigste Grund, warum ein IT-Projekt aus dem Ruder läuft, ist ein Angebot, das auf einer zu groben Vorstellung vom tatsächlichen Bedarf beruht. „Neues Netzwerk für den Standort” klingt eindeutig, deckt aber nicht ab, ob Videoüberwachung mitgedacht ist, ob Produktionsanlagen ins Netz sollen oder ob ein zweiter Serverraum als Redundanz vorgesehen ist. Solche Lücken werden erst während der Umsetzung sichtbar – und dann steht die Frage im Raum, ob es sich um einen Nachtrag oder um einen ursprünglich vereinbarten Leistungsteil handelt. Erkennbar ist ein unklarer Umfang meist schon am Angebot selbst: Wenn es auf einer Seite Platz hat, ohne dass vorher eine Bestandsaufnahme vor Ort stattgefunden hat, fehlt in der Regel die Grundlage für eine belastbare Kalkulation.

• Angebot erst nach einer Bestandsaufnahme vor Ort erstellen lassen, nicht auf Basis einer kurzen Beschreibung
• Leistungsumfang schriftlich so konkret festhalten, dass beide Seiten dieselbe Erwartung haben
• Explizit festhalten, was nicht Teil des Projekts ist, nicht nur was enthalten ist

Fehlende Ansprechpartner auf Kundenseite

Ein Projekt braucht auf Kundenseite jemanden, der Entscheidungen tatsächlich treffen kann und während der Umsetzung erreichbar ist – nicht nur zu Projektbeginn und bei der Abnahme. Fehlt diese Person, oder wechselt sie mitten im Projekt ohne Übergabe, entstehen Verzögerungen an Stellen, die technisch in wenigen Minuten geklärt wären: Welche IP-Adresse soll der neue Server bekommen, darf ein bestimmter Bereich am Wochenende abgeschaltet werden, wer gibt die Freigabe für eine Änderung an der Firewall. Erkennbar wird das Problem daran, dass Rückfragen tagelang unbeantwortet bleiben oder von wechselnden Personen widersprüchlich beantwortet werden.

• Einen festen Ansprechpartner mit tatsächlicher Entscheidungsbefugnis für die Projektdauer benennen
• Vertretung für Urlaub oder Krankheit vorher klären, statt das Projekt in dieser Zeit stillstehen zu lassen
• Kurze, feste Rückmeldezeiten für Entscheidungen vereinbaren, damit Verzögerungen früh auffallen

Umbau im laufenden Betrieb ohne Plan B

Netzwerk-, Firewall- oder Serverumbauten passieren in den seltensten Fällen in einem stillstehenden Betrieb – meist läuft der Alltag während der Umsetzung weiter. Wird eine solche Änderung ohne definierten Rückfallweg umgesetzt, steht im Fehlerfall niemand vor der Wahl zwischen zwei Optionen, sondern vor einem Betrieb, der stillsteht, bis das Problem gelöst ist. Das betrifft besonders Änderungen an zentralen Komponenten wie der Firewall oder dem Kern-Switch, bei denen ein einzelner Fehler den gesamten Standort von der Kommunikation abschneiden kann. Erkennbar ist das Fehlen eines Plan B meist erst im Ernstfall – wenn eine Änderung geplant war, aber niemand sagen kann, wie in den nächsten zehn Minuten der vorherige Zustand wiederhergestellt wird.

• Kritische Änderungen außerhalb der Kernbetriebszeiten durchführen, wenn ein Stillstand am wenigsten kostet
• Vor jeder Änderung an zentralen Komponenten den Rückweg zum vorherigen Zustand konkret festlegen, nicht nur den Plan nach vorne
• Bei besonders kritischen Systemen eine Testphase mit begrenztem Nutzerkreis vorschalten, bevor die Änderung für alle gilt

Abnahme ohne Dokumentation

Ein Projekt gilt oft schon dann als abgeschlossen, wenn die Technik funktioniert – Dokumentation wird nachgereicht, „sobald Zeit ist”, was in der Praxis häufig bedeutet: nie. Die Abnahme bestätigt damit einen funktionierenden Zustand, aber nicht, dass dieser Zustand für jemand anderen als den ausführenden Techniker nachvollziehbar ist. Das Problem zeigt sich meist erst Monate oder Jahre später, wenn eine Änderung ansteht oder ein anderer Dienstleister übernehmen soll und niemand mehr genau weiß, wie das System aufgebaut ist. Erkennbar ist das Risiko schon bei der Abnahme selbst: Liegt zu diesem Zeitpunkt eine vollständige Dokumentation vor, oder wird sie „nachgeliefert”?

• Vollständige Dokumentation (Netzplan, Konfigurationen, Zugangsdaten) als Teil der Abnahme verlangen, nicht als spätere Zugabe
• Abnahme erst unterschreiben, wenn die Dokumentation tatsächlich vorliegt und stichprobenartig geprüft wurde
• Dokumentationspflicht bereits im Angebot oder Vertrag festhalten, nicht erst am Ende einfordern

Niemand ist danach zuständig

Nach der Abnahme endet das Projekt formal – aber die Infrastruktur läuft weiter, verändert sich, braucht Updates und irgendwann eine Anpassung. Wenn zu diesem Zeitpunkt nicht klar geregelt ist, wer im Zweifel zuständig ist, entsteht eine Lücke zwischen zwei Zuständen: Das Projekt ist fertig, ein laufender Betreuungsvertrag existiert aber nicht oder ist inhaltlich unklar. In der Praxis heißt das oft, dass bei der nächsten Störung erst geklärt werden muss, wer überhaupt angerufen wird – wertvolle Zeit, die im Ernstfall fehlt. Erkennbar ist diese Lücke, wenn nach Projektende niemand sagen kann, welche Reaktionszeiten oder welcher Ansprechpartner für den laufenden Betrieb gilt.

• Bereits vor Projektende klären, ob und in welcher Form eine laufende Betreuung folgt
• Zuständigkeit für den laufenden Betrieb schriftlich festhalten, auch wenn sie beim Kunden selbst liegt
• Übergabegespräch führen, in dem die interne Zuständigkeit für Wartung, Updates und Störungen konkret benannt wird

Was macht ein IT-Projekt tatsächlich erfolgreich?

Ein erfolgreiches IT-Projekt unterscheidet sich von einem gescheiterten selten durch bessere Technik, sondern durch bessere Klärung im Vorfeld: ein Angebot auf Basis einer echten Bestandsaufnahme, ein fester Ansprechpartner auf beiden Seiten, ein definierter Rückfallweg für kritische Änderungen, eine Abnahme, die Dokumentation einschließt, und eine klare Antwort auf die Frage, wer nach Projektende zuständig ist. Wer diese fünf Punkte vor dem ersten Handgriff klärt, reduziert das Risiko eines gescheiterten Projekts deutlich stärker als durch die Wahl eines bestimmten Herstellers oder einer bestimmten Technologie.