Projektleistungen externer Lieferanten sind eine Quelle vielfältiger Risiken für den Projekterfolg. Im Folgenden stelle ich Ihnen zum einen Indikatoren vor, an denen Sie frühzeitig diese Risiken erkennen können. Zum anderen gebe ich Hinweise und Handlungsempfehlungen, damit Projektrisiken aus der Lieferantensteuerung beherrschbar bleiben. Den Hintergrund bilden Erfahrungen aus einem gescheiterten Projekt, in dem ein Lieferant eine Standard-Software in die IT-Landschaft einer großen Organisation implementieren sollte.
Organisationen stehen immer wieder vor der Herausforderung, dass für das Funktionieren der Organisation wesentliche und oft historisch gewachsene IT-Systeme komplett ausgetauscht werden müssen. Diese erheblichen Veränderungen sind meist nur dann wirtschaftlich vertretbar, wenn durch den Zukauf einer Standard-IT-Lösung am Markt Effizienzvorteile, Prozessoptimierung und Zukunftsorientierung der IT(-Plattform) verwirklicht werden kann. Diese Kriterien trafen auch auf das hier als Beispiel dienende Projekt zu.
Die Tochtergesellschaft eines weltweit tätigen Konzerns hatte sich nach langem und komplexem Auswahlverfahren für die Software eines am Markt etablierten, mittelständischen Anbieters entschieden. Die Gesellschaft mit ihren fast 1.000 Mitarbeitern stand in enger Leistungsverflechtung mit anderen Gesellschaften des Mutterkonzerns Während der Konzern mit vielen kleineren und mittleren IT-Projekten den gewünschten Modernisierungs- und Standardisierungsgrad der IT anstrebte, musste die Tochtergesellschaft ihr IT-Herzstück komplett umwandeln bzw. erneuern.
Schon zu Beginn war klar, dass das Projekt trotz Verwendung einer Standard-Software aufgrund zwingend notwendiger Anpassungen – die auch nicht anderweitig zu beschaffen sind – ca. zwei Jahre Anpassungs-, Implementierungs- und vor allem Testzeit bedurfte. Hinzu kamen zeitliche und inhaltliche Abhängigkeiten von Konzernthemen, wie z.B. Jahresabschluss und Anpassung von Schnittstellen. Insgesamt umfasste das Projektbudget einen mittleren 7-stelligen Betrag, der sich zu je einem Drittel aus Software-Lizenzen, Anpassungen durch die IT-Ressourcen und fachlicher Zuarbeit bzw. Projektsteuerung zusammensetzte.
Mein wichtigster Ratschlag an Projektleiter eines vergleichbaren Projekts lautet daher: Binden Sie Ihre Lieferanten von Anfang an so eng es geht ein, indem Sie diese zu Projektpartnern aufwerten. Nur so haben Sie eine Chance, dass u.a. die Mitarbeiter des Lieferanten einen inneren Zusammenhang zu Ihrem Projekt aufbauen, d.h. eine ähnliche Zielsetzung sowie "Empathie" für Ihre Organisation entwickeln, und ausreichend motiviert sind. Außerdem schafft nur diese Aufwertung den nötigen Freiraum für den Projekteileiter auf Lieferantenseite; ansonsten droht er in der eigenen Linienorganisation "unterzugehen".
Sorgen Sie dafür, dass sich auf der täglichen Arbeitsebene unter den Mitgliedern der beteiligten Unternehmen und Organisationseinheiten von Beginn an eine vertrauensvolle und pragmatische Zusammenarbeit entwickelt. Dazu bietet es sich an, dass die Mitarbeiter in räumlicher Nähe – am besten im selben Raum – arbeiten ("Co-Location"), um beständigen Austausch zu gewährleisten und die Arbeitsweise des anderen kennenzulernen.
Projekte dieser Art haben nicht nur für die jeweilige Tochtergesellschaft eine hohe Bedeutung, sondern auch für den Gesamtkonzern. Sowohl aufgrund der erheblichen Budgetgröße, als auch als Teil der neuen technologischen Plattform im Konzern, die zur Vereinheitlichung im Sinne der IT-Strategie sowie der Einsparung von Betriebskosten führen soll. Daher stehen solche Projekte in der Regel "unter Beobachtung" verschiedener Konzerngremien. Was Sie als Projektleiter in diesem Zusammenhang beachten sollten, wird an späterer Stelle beleuchtet.
Der Konzern verfügte bereits über Erfahrung mit fachlichen und technischen Teilprojekten. Wie in der Vergangenheit stellte sich auch bei dem Projekt die Frage, ob die neue, zugekaufte Software als Teilprojekt oder als integrierter Bestandteil des Gesamtprojekts gesteuert werden sollte. Wir beantworteten die Frage – wie in dem Konzern üblich – indem wir ein Teilprojekt aufsetzten.
Im Nachhinein stellte sich die Frage nach der Projektorganisation als Schicksalsfrage heraus – und unsere damalige Beantwortung als falsch. Durch die Entscheidung, die zugekaufte Software als Teilprojekt zu steuern, entstanden erhebliche Risiken, von denen einige auch eintraten und sich zu großen Schwierigkeiten auswuchsen, die letztendlich zum Projektscheitern führten.
Ein erster Ansatzpunkt für die richtige Projektorganisation ist die vertragliche Ausgangslage. Große Organisationen neigen dazu, bei Werkverträgen auch ein eigenes Teilprojekt für den Lieferanten zu kreieren. Regelmäßig führt diese Projektorganisation zu desaströsen Projekten, wie die folgenden beispielhaften Probleme zeigen:
Erster Monat kostenlos,
dann 24,95 € pro Monat
Know-how von über 1.000 Profis
Methoden für alle Aufgaben
Websessions mit Top-Expert:innen
