Erfolg beginnt vor dem Projekt

Alles, was man über das Projektmanagement digitaler Vorhaben wissen muss. So lässt sich das Gespräch mit Hans Peter Weidele zusammenfassen. Der IT-Experte spricht über Best Practice, Stolpersteine und Erfolgsfaktoren.

Computerworld (CW): Herr Weidele, die digitale Transformation beginnt im Kopf und dann im Projekt. Wie kann sich ein Kunde am besten auf ein IT-Projekt vorbereiten?

Hans Peter Weidele: Bevor ein IT-Projekt gestartet wird, sollte sich der Kunde zunächst über mehrere zentrale Punkte im Klaren sein. Zunächst gilt es zu prüfen, ob es strategische Aspekte gibt, die ein solches Projekt notwendig machen. Gleichzeitig ist es wichtig, einen Überblick über andere parallel geplante Vorhaben zu gewinnen – sowohl operative als auch strategische –, um die eigene Position in einer potenziellen Multiprojektlandschaft realistisch einschätzen zu können. Ein weiterer wesentlicher Punkt betrifft die Finanzierung: Liegt ein belastbares Budget für das IT-Projekt vor, oder bestehen hier noch Unsicherheiten? Ebenso entscheidend ist die Ressourcenfrage. Es muss geklärt sein, ob ausreichend personelle Kapazitäten zur Verfügung stehen – insbesondere vor dem Hintergrund, dass häufig dieselben Mitarbeitenden auch in anderen Projekten oder im operativen Tagesgeschäft stark eingebunden sind. Nur wenn all diese Fragen eindeutig beantwortet sind, ergibt ein Projektstart Sinn. Andernfalls drohen Zielkonflikte, Verzögerungen oder Ressourcenengpässe, die den Erfolg des IT-Projekts gefährden könnten.

CW: Sie sind in Projekten als externer Berater involviert. Welche Unterstützung bieten Sie dabei konkret an?

Weidele: Die Unterstützung durch eine externe Beratung ist bei IT-Projekten in vielerlei Hinsicht sinnvoll – und in vielen Fällen sogar unverzichtbar. Denn die Erfahrung zeigt: Die notwendige Expertise, um komplexe IT-Vorhaben erfolgreich zu steuern, ist in Unternehmen meist nicht in ausreichendem Masse vorhanden. Während spezialisierte Beratungen jährlich mehrere IT-Projekte bei verschiedenen Kunden begleiten, steht ein einzelnes Unternehmen oft nur alle fünf bis zehn Jahre vor einem vergleichbaren Vorhaben. Ein weiterer zentraler Aspekt ist die zeitliche Verfügbarkeit der internen Projektbeteiligten. In der Regel sind Mitarbeitende, unabhängig davon, ob das Projekt aus dem Business oder der IT heraus initiiert wurde, zu 80 bis 100 Prozent im Tagesgeschäft eingebunden. Dies führt zwangsläufig zu Engpässen in der Projektarbeit – sowohl inhaltlich als auch organisatorisch. 

CW: Was sich auch wieder von externen Ressourcen überbrücken lässt.

Weidele: Richtig. Externe Berater können hier gezielt unterstützen – sowohl strategisch als auch operativ. Zu Beginn eines Projekts übernehmen sie idealerweise eine kritische Überprüfung der grundlegenden Rahmenbedingungen: Sind Budget, Ressourcen und Abhängigkeiten aus der Multiprojektlandschaft realistisch eingeschätzt worden? In der Praxis wird dieser Punkt von Unternehmen häufig unterschätzt oder vorschnell abgehakt. Darüber hinaus bringen externe Experten wertvolle Impulse bei der Prozessoptimierung – sowohl im operativen Bereich als auch innerhalb der IT. Besonders hilfreich ist ihre Unterstützung bei der Anforderungsdefinition: Sie sorgen dafür, dass der Fokus auf den wirklich wertschöpfenden Prozessen liegt und nicht jede Sonderlösung umgesetzt wird, nur weil sie gewünscht ist. Ziel sollte es immer sein, Anforderungen möglichst nah am vorhandenen IT-Standard zu definieren – denn jede Abweichung verursacht Zusatzkosten, ohne zwingend einen echten Mehrwert zu schaffen. 

CW: Und wenn der Standard doch nicht genügt?

Weidele: Anforderungen ausserhalb eines Standardprozesses sollten deshalb immer durch den Anforderer selbst plausibilisiert werden – insbesondere im Hinblick auf Kosten und Nutzen über den Zeitverlauf. Auch im Projektmanagement leistet externe Unterstützung wertvolle Dienste, etwa bei der Kontrolle von Budget, Zielen, Aufgaben oder auch durch den Einsatz spezialisierter Tools.  Zudem können externe Berater Aufgaben im Risiko- und Ressourcenmanagement übernehmen, wenn diese Kompetenzen intern nicht vorhanden oder verfügbar sind. Besonders wichtig: Als neutrale Instanz fungieren sie als Vermittler und Sparringspartner zwischen dem IT-Lieferanten und dem Kunden – etwa wenn es zu Verzögerungen, Unklarheiten oder Streitigkeiten über Change Requests kommt. 

Ein weiterer Mehrwert liegt in der kontinuierlichen Begleitung beim Scoping des Projektinhalts – vor und während der Projektlaufzeit. Denn es gilt als eine der Hauptursachen für Budget- und Zeitüberschreitungen, dass während des Projekts neue Anforderungen eingebracht werden, die nicht sauber bewertet und priorisiert wurden. Auch in Vertragsverhandlungen oder bei der Ausgestaltung von Leistungsvereinbarungen bringen erfahrene Berater ihr Know-how ein und schützen das Projekt so vor kostspieligen Missverständnissen.

CW: Als Berater begleiten Sie Kunden auch schon während der Ausschreibung. Welche Erfahrungen haben Sie dabei gemacht?

Weidele: Bei der Ausschreibung von IT-Projekten kommt es in erster Linie auf eine saubere und nachvollziehbare Anforderungsdefinition an. Nur wenn die Systemlieferanten genau verstehen, was das Unternehmen benötigt, können sie passende und realistische Angebote erstellen. Dabei sollte darauf geachtet werden, dass die Anforderungen klar strukturiert und fachlich nachvollziehbar formuliert sind – ohne Interpretationsspielraum. Ein weiterer zentraler Punkt ist die Vergleichbarkeit der eingehenden Offerten. Diese lässt sich am besten durch ein einheitliches Angebotsraster sicherstellen, das allen potenziellen IT-Lieferanten zur Verfügung gestellt wird. So kann das Unternehmen die Angebote objektiv und effizient bewerten – sowohl inhaltlich als auch preislich. 

Zudem ist bei der Auswahl der Anbieter Zurückhaltung oft die bessere Strategie: Ausschreibungen sollten nicht an möglichst viele IT-Lieferanten versendet werden, da dies nicht nur den Aufwand erhöht, sondern auch die Qualität der Rückmeldungen verwässert. Eine Ausnahme bilden Plattform-basierte Ausschreibungen, bei denen ohnehin alle Anbieter mit generischen Anforderungen bedient werden – hier ist eine breite Streuung üblich und teilweise auch sinnvoll. Schliesslich ist die Lieferantenauswahl idealerweise referenzbasiert zu treffen. Anbieter, die bereits vergleichbare Projekte erfolgreich umgesetzt haben, bringen nicht nur die notwendige Erfahrung mit, sondern reduzieren auch das Projektrisiko erheblich. Eine belastbare Referenzlage schafft Vertrauen und erhöht die Wahrscheinlichkeit, dass das Projekt im Zeit- und Budgetrahmen umgesetzt werden kann.

CW: Welchen Tipp würden Sie einem Unternehmen hinsichtlich Entscheidungsfindung geben?

Weidele: Bei der Entscheidungsfindung für ein IT-Projekt ist ein klar strukturiertes Entscheidungsraster von zentraler Bedeutung. Es schafft Transparenz für alle Beteiligten und dokumentiert nachvollziehbar, auf welcher Grundlage die Auswahl getroffen wurde. Gerade in komplexen Projekten mit mehreren involvierten Personen hilft ein solches Raster, Diskussionen zu versachlichen und die Entscheidungsfindung zu objektivieren. Entscheidend ist auch, dass der Kunde festlegt, welche Personen fachlich und methodisch am besten geeignet sind, um die vorgeschlagenen IT-Lösungen zu bewerten. Dabei geht es nicht nur um Hierarchie oder Funktion, sondern um die Fähigkeit, technische und funktionale Anforderungen kompetent einzuschätzen. 

Für den Projektsponsor – also jene Person, die das Projekt verantwortet, aber nicht unbedingt aktiv in den Entscheidungsprozess eingebunden ist – muss jederzeit ersichtlich sein, wie und warum eine Entscheidung getroffen wurde. Diese Transparenz stärkt das Vertrauen in den Prozess und unterstützt die spätere Umsetzung. Neben fachlichen und technischen Kriterien spielt auch der zwischenmenschliche Aspekt eine wichtige Rolle. Es ist von Vorteil, wenn sich die Projektbeteiligten auf Kunden- und Lieferantenseite bereits kennen oder im Vorfeld der Entscheidung Gelegenheit hatten, sich auszutauschen. Persönliche Reibungsverluste können so minimiert werden, was wiederum die Zusammenarbeit im späteren Projektverlauf erheblich erleichtert.

CW: Schlussendlich fallen irgendwann die Würfel und es erfolgen einige Absagen, aber nur eine Zusage. Eine unangenehme Situation?

Weidele: Eigentlich nicht. Absagen im Rahmen einer IT-Ausschreibung sollten stets transparent und respektvoll erfolgen – insbesondere gegenüber jenen Lieferanten, die Zeit und Aufwand in ihre Offerte investiert haben. Jeder Anbieter, der eingeladen wurde und tatsächlich am Ausschreibungsverfahren teilgenommen hat, sollte eine begründete Rückmeldung erhalten, warum er den Zuschlag nicht erhalten hat. Diese Absage muss kein ausführliches Schreiben sein, aber sie sollte die wichtigsten Entscheidungsgründe knapp und klar benennen. Typische Beispiele sind etwa: die Komplexität der Prozesse wurde nicht richtig erfasst, das Kostenmodell war nicht schlüssig, der Präsentationstermin verlief nicht überzeugend oder es gab Bedenken bezüglich des eingesetzten Personals. Wichtig ist, dass die Begründung professionell und sachlich formuliert ist – nicht zuletzt, um sich auch für zukünftige Projekte eine gute Beziehung zu potenziellen Anbietern offenzuhalten. Bei der Ausarbeitung kann ein externer Berater unterstützen und helfen, die Rückmeldung konstruktiv und diplomatisch zu gestalten. So wird das Auswahlverfahren für alle Beteiligten nachvollziehbar und fair abgeschlossen.

CW: Wenn es um grössere Investitionen wie bei einem IT-Projekt geht, geht es auch um juristische Fragen. Was sind die gängigsten Vertragswerke?

Weidele: In IT-Projekten empfiehlt es sich, ein strukturiertes Vertragswerk aufzusetzen, das sowohl die übergeordnete Projektplanung als auch die konkrete Umsetzung absichert. Eine bewährte Vorgehensweise ist die Erstellung eines Rahmenvertrags, der als übergeordnete Grundlage für das gesamte Projekt dient. In diesem Dokument werden die allgemeinen Rahmenbedingungen, das strategische Ziel des IT-Projekts sowie grundlegende rechtliche und organisatorische Aspekte festgehalten. Darauf aufbauend werden für einzelne Umsetzungsphasen separate Leistungsverträge (LV) erstellt. Diese definieren jeweils den funktionalen Umfang, das konkrete Budget und die operativen Ziele der nächsten Projektschritte. Ein typisches Beispiel: Ein international tätiges Unternehmen plant, eine neue IT-Lösung in 20 Ländern einzuführen. Hier empfiehlt es sich, zunächst einen Leistungsvertrag für das Pilotland – meist das Headquarter – zu erstellen. In weiteren Schritten folgen dann einzelne Verträge für die internationalen Rollouts oder für spezifische Erweiterungen. 

Diese modulare Vertragsstruktur ermöglicht eine klare Abgrenzung der Teilprojekte und reduziert das Risiko von Missverständnissen zwischen Kunde und IT-Lieferant. Sie stellt sicher, dass beide Seiten eine einheitliche Vorstellung vom jeweiligen Projektabschnitt haben – sowohl inhaltlich als auch finanziell – und erleichtert die Steuerung des Gesamtprojekts erheblich.

CW: Nicht nur der Lieferant ist gefordert, sondern auch der Kunde. Welche Ressourcen sind seitens des Kunden zu planen?

Weidele: Die benötigten Ressourcen auf Kundenseite variieren stark – abhängig vom Umfang, der Komplexität und der Vorbereitung eines IT-Projekts. Besonders bei grossen Vorhaben wie der Einführung eines ERP-Systems sollten Unternehmen damit rechnen, dass ihr interner Aufwand deutlich höher liegt als oft angenommen. Als Faustregel gilt: Der Ressourceneinsatz auf Kundenseite kann das 1,5- bis 2-Fache der im Angebot des IT-Lieferanten kalkulierten Projekttage betragen. Hilfreich ist es, wenn das Unternehmen eine übersichtliche Multiprojektlandschaft erstellt. Diese sollte aufzeigen, welche Projekte in den nächsten 24 Monaten geplant sind – unabhängig davon, ob es sich um IT-, Strategie- oder Veränderungsprojekte handelt. Nur so lässt sich abschätzen, ob die verfügbaren personellen Kapazitäten ausreichen, um ein weiteres IT-Projekt sinnvoll zu starten. Der Ressourceneinsatz hängt zudem wesentlich davon ab, wie gut das Unternehmen vorbereitet in das Projekt einsteigt. Sind Anforderungen bereits geklärt? Steht ein erfahrenes Projektteam bereit? Oder müssen grundlegende Inhalte noch erarbeitet werden? Je nach Ausgangslage variiert der interne Aufwand erheblich. Eine pauschale Aussage zur benötigten Ressourcengrösse lässt sich nicht seriös treffen. Die Erfahrung aus über 20 Jahren IT-Projektpraxis zeigt jedoch klar: In keinem Projekt war der Ressourcenbedarf auf Kundenseite geringer als die Anzahl der vom Lieferanten angebotenen Personentage. Aussagen, die das Gegenteil behaupten, sind mit Vorsicht zu geniessen – denn sie verkennen den tatsächlichen Aufwand, der intern notwendig ist, um ein IT-Projekt erfolgreich umzusetzen.

CW: Wie sieht für Sie eine ideale Projektorganisation aus?

Weidele: Ab einer gewissen Projektgrösse empfiehlt sich eine klare und strukturierte Projektorganisation, um Komplexität zu beherrschen und den Projekterfolg sicherzustellen. Eine bewährte Struktur basiert auf mehreren Ebenen mit klar definierten Rollen und Verantwortlichkeiten. An oberster Stelle steht das Steering Committee bzw. der Lenkungsausschuss, der die strategische Steuerung des Projekts übernimmt. Hier sitzen die entscheidenden Vertreter von Kunde und IT-Lieferant, meist aus dem oberen Management. Das Projektmanagement beider Seiten rapportiert an dieses Gremium den Projektstand – inklusive Budget, Fortschritt und Risiken – und bringt Entscheidungsanträge ein, etwa bei Änderungswünschen oder Budgetüberschreitungen.

Die operative Umsetzung liegt in der Hand des Projektmanagements, das idealerweise sowohl vom Kunden als auch vom IT-Lieferanten je mit einem Projektleiter besetzt wird. Diese Doppelspitze gewährleistet Transparenz, gegenseitige Verantwortung und eine enge Zusammenarbeit.  Bei grösseren Projekten empfiehlt sich zudem der Einsatz eines Project Management Office, das administrative Aufgaben übernimmt und so das Projektmanagement entlastet. Dazu zählen etwa Terminplanung, Protokollführung, Dokumentation und Reporting. 

Für das Changemanagement sollte eine eigene Instanz definiert werden, die als koordinierende Stabstelle innerhalb der Projektorganisation agiert. Diese sorgt dafür, dass Veränderungen strukturiert eingeführt und sauber dokumentiert werden.Auf technischer Ebene ist es ratsam, dass sowohl der Kunde als auch der IT-Lieferant je einen Lösungsarchitekten benennen. Diese Experten tragen die Verantwortung für das technische Gesamtkonzept und behalten den Überblick über Systemarchitektur, Schnittstellen und Integrationen. 

Unterhalb des Projektmanagements arbeiten Verantwortliche für Teilbereiche, beispielsweise für einzelne Geschäftsprozesse oder Funktionsgruppen. Ihnen unterstellt sind die Key-User, welche als fachliche Brücke zwischen dem Projektteam und den Endanwendern fungieren und eine wichtige Rolle bei der Akzeptanz der neuen Lösung spielen. Bei rein technischen IT-Projekten kann die Organisation im Detail abweichen, doch das Grundprinzip bleibt gleich: Klare Strukturen, definierte Rollen und abgestimmte Kommunikationswege bilden das Fundament jeder erfolgreichen Projektorganisation.

CW: Noch einmal zurück zu Ihrer Rolle als externer Berater. Welchen Spielraum haben Sie bei Ihren Kunden?

Weidele: Ein externer Berater kann im Rahmen eines IT-Projekts eine zentrale Rolle einnehmen – insbesondere auf organisatorischer Ebene. Idealerweise übernimmt er für den Kunden sämtliche projektorganisatorischen Aufgaben, von der Planung über das Controlling bis hin zur Koordination der verschiedenen Beteiligten. Wie tief der Berater dabei auch in technische Fragestellungen oder die Anforderungsdefinition eintaucht, hängt von seiner individuellen Expertise ab. 

Der grösste Mehrwert eines externen Beraters liegt in seiner Erfahrung und Routine: Während ein Unternehmen in der Regel nur alle zehn Jahre ein grosses IT-Projekt durchführt, begleitet ein spezialisierter Berater im selben Zeitraum oft zehn oder mehr ähnliche Vorhaben – eine Relation, die den Wissensvorsprung und die Methodenkompetenz deutlich macht. 

Eine strukturierte Übersicht aller möglichen Unterstützungsleistungen hilft dem Kunden, gemeinsam mit dem Berater zu entscheiden, welche Aufgaben zwingend ausgelagert werden sollten, welche optional intern abgedeckt werden können und welche zwingend in der Verantwortung des Unternehmens verbleiben müssen. Auf diese Weise entsteht eine effiziente Rollenverteilung, die Ressourcen schont, Risiken minimiert und den Projekterfolg aktiv unterstützt. Ein externer Berater ist damit nicht nur ein operativer Helfer, sondern auch ein strategischer Sparringspartner – vorausgesetzt, seine Rolle wird von Anfang an klar definiert.

CW: Der Hunger wächst bekanntlich beim Essen. Was tun, wenn Kundenwünsche und Realität auseinanderdriften?

Weidele: Wenn Kundenwünsche und die technische oder organisatorische Realität auseinanderdriften, ist es wichtig, frühzeitig für Klarheit zu sorgen – und genau hier kommt ein externer Berater ins Spiel. Eine zentrale Aufgabe des Beraters besteht darin, aus seiner Erfahrung heraus realistisch einzuordnen, was tatsächlich umsetzbar ist und was eher einem Idealbild entspricht. Ein bewährter Ansatz ist es, bereits vor Projektstart eine strukturierte Prozessoptimierung durchzuführen – mit dem Fokus auf die spätere IT-Umsetzbarkeit. Dabei wird der «Blumenstrauss» an Anforderungen gemeinsam mit dem Kunden konkretisiert, priorisiert und auf das Wesentliche reduziert. So kann realistisch abgeschätzt werden, was technisch machbar ist – ohne unnötige Zeit mit Wunschvorstellungen zu verlieren, die später nur aufwendig oder gar nicht realisiert werden können. Wichtig ist, dass diese Diskussion nicht ausschliesslich mit dem Umsetzungspartner geführt wird, da dieser naturgemäss eigene Interessen verfolgt. Ein externer Berater agiert dagegen neutral und im Sinne des Kunden – und sorgt so dafür, dass Erwartungen und Realität möglichst nah beieinander liegen, bevor das Projekt in die entscheidende Phase geht.

CW: Wo liegen aus Ihrer Sicht die grössten Risiken bei IT-Projekten?

Weidele: Die grössten Risiken in IT-Projekten entstehen häufig schon lange vor dem eigentlichen Projektstart – und liegen in der unzureichenden Vorbereitung auf Kundenseite. Ein zentraler Risikofaktor ist die fehlende Ressourcenplanung. Viele Unternehmen starten ein IT-Projekt, ohne im Vorfeld zu klären, ob die benötigten internen Kapazitäten überhaupt verfügbar sind – insbesondere im Kontext einer bestehenden Multiprojektlandschaft, in der Mitarbeitende bereits in andere Projekte oder das Tagesgeschäft eingebunden sind.

Ein weiteres Risiko besteht in der fehlenden Budgetplanung. Oft wird mit einem IT-Vorhaben begonnen, ohne zumindest ein grobes finanzielles Rahmenwerk festzulegen. Dabei könnte bereits ein erfahrener Berater helfen, auf Basis vergleichbarer Projekte eine realistische Budgetschätzung zu erstellen – ein wichtiger Schritt, um spätere Kostenüberschreitungen zu vermeiden. 

Ebenso kritisch ist, wenn vorbereitende Arbeiten nicht rechtzeitig vom Kunden erledigt werden. Gerade im ERP-Umfeld gehören dazu typische Themen wie die Bereinigung und Strukturierung der Stammdaten, die Definition relevanter Belege und Reports, eine saubere Migrationsstrategie sowie die Optimierung bestehender Prozesse. Werden diese Grundlagen nicht im Vorfeld geklärt, führt dies im Projektverlauf fast zwangsläufig zu Verzögerungen, Qualitätseinbussen oder zusätzlichen Kosten.  Kurz gesagt: Die grössten Risiken entstehen nicht in der Technik – sondern im menschlichen und organisatorischen Vorfeld. Wer sie frühzeitig erkennt und gezielt adressiert, kann sein IT-Projekt wesentlich stabiler und erfolgreicher aufsetzen.

CW: Irgendwann ist Schluss. Oder doch nicht? Wann endet ein IT-Projekt wirklich?

Weidele: Ein IT-Projekt endet nicht mit dem letzten Projekttag, sondern mit dem erfolgreichen Übergang in den operativen Betrieb – idealerweise termingerecht und innerhalb des geplanten Budgets. In dieser Phase beginnt sich das Projektteam aufzulösen: Einige Teammitglieder kehren in ihre ursprünglichen Rollen zurück, andere übernehmen Aufgaben im laufenden Betrieb der neuen Lösung oder werden in neue Projekte eingebunden. Doch auch wenn das Projekt formal abgeschlossen ist, bedeutet das nicht, dass die Arbeit an der Lösung endet. Im Gegenteil: Die Umsetzung geht inhaltlich weiter. Funktionale Erweiterungen, Anpassungen an veränderte gesetzliche Vorgaben oder Feedback aus dem Tagesgeschäft führen immer wieder zu weiteren Entwicklungszyklen. 

Ein IT-Projekt endet also nicht mit einem «Punkt», sondern vielmehr mit einem «Doppelpunkt»: Es markiert den Start eines neuen, kontinuierlichen Prozesses, in dem die Lösung gepflegt, weiterentwickelt und an sich wandelnde Anforderungen angepasst wird. Erfolgreiches Projektmanagement bedeutet deshalb auch, den Übergang vom Projekt zur Betriebsverantwortung sauber zu gestalten – mit klaren Zuständigkeiten, dokumentierten Prozessen und einem reibungslosen Know-how-Transfer.