Aus den umfangreichen Cassini-Projekterfahrungen haben wir folgendes Beispiel eines prototypischen IT-Projekts mit einer komplexen Dienstleister- und Lieferantenstruktur abgeleitet, an dem die o.g. Regelungsdimensionen illustriert werden. Das Projekt unterliegt folgenden Rahmenbedingungen:
Es handelt sich um ein IT-Programm, das bei einer obersten Bundesbehörde verortet ist. Programmteilnehmer sind jedoch diverse weitere öffentliche Institutionen. Ziel des Programms ist die Vereinheitlichung von bestehenden Alt-IT-Systemen, bspw. dislozierten Datenbanken, und der Abbau von Daten-Silos durch Konsolidierung in einer redundant ausgelegten Cloudumgebung. Jeder Programmteilnehmer hat in der Vergangenheit individuelle Dienstleister beauftragt, die sich mit der Wartung und Pflege der Alt-Systeme beschäftigen. Die Einführung einer einheitlichen Lösung wird sowohl Hard- als auch Software-Komponenten (Cloudhardware, Housing, Klimatisierung, Betriebssystem, Storagemanagement und Storageverwaltung) beinhalten. Aufgrund der sich stetig verändernden Rahmenbedingungen und der Anforderung, zukünftig weitere Systeme an die neue Lösung anbinden zu können (bspw. Implementierung von Archivierungsdiensten in der Cloud), soll die Umsetzung größtmögliche Flexibilität ermöglichen. Die Personalsituation der Programmteilnehmer ist angespannt – dementsprechend lassen sich die notwendigen Kapazitäten zur Steuerung und zur Umsetzung in vollem Umfang nicht zur Verfügung stellen.
Vertragstyp
Wir ziehen in unserem Beispiel-Case als Liefergegenstand sowohl Hardware- als auch Software-Komponenten und somit mind. zwei verschiedene Formen von Liefergegenständen heran. Im Hardware-Bereich lassen sich Liefergegenstände sehr detailliert beschreiben, sodass die Nutzung von Pauschalfestpreisen möglich ist. Da die Software nicht nur beschafft, sondern weiterentwickelt und implementiert werden muss, wird hier eine Kombination von Pauschalfestpreis (Beschaffung von Standard-Lizenzen) und Vergütung nach Aufwand (für die Weiterentwicklung und das Projektmanagement) empfohlen.
Bezugsstrategie
Grundsätzlich sind hier die beiden Stränge Lieferungen (o.g. Hard- und Software) sowie Dienstleistungen (bspw. Umsetzungsbegleitung und Projektmanagement, ggf. IT-Sicherheitsbetrachtungen) zu unterscheiden. Es ergeben sich bezüglich Ersterem Vorteile, wenn alles (Appliance aus Hard- und Software) aus „einer Hand“ bezogen werden kann. Dies führt später jedoch über entsprechende Produktzyklen und auf die Produkte zugeschnittene Beratungsleistungen schnell zum Vendor-Lock-in. Sollte es für den Anwendungsfall mehrere Hersteller am Markt geben, sichert die Bezugsstrategie über mehrere Anbieter (Multi-Vendor-Strategie) gegen etwaige Lieferantenausfälle und schafft Wettbewerb. Der Betrieb gestaltet sich bei mehreren Lösungen aufwändiger, dies sollte bei der Entscheidungsfindung mitbedacht werden.
Das (übergreifende) Projektmanagement sollte grundsätzlich nicht nur beim Lieferanten liegen, da damit die Chance zur Installation einer (unabhängigen) Kontrollinstanz neben dem Auftraggeber vertan wird. Je nach Größe des Projektes kann dieser (dritte) Dienstleister als Nebenleistung zum Projektmanagement bspw. die Bearbeitung von IT-Sicherheitsthemen mitanbieten. Im hiesigen Fall handelt es sich jedoch um ein komplexes Programm, welches besonderes Know-how in diesem Feld benötigt. Daher wird auch hier eine Multi-Vendor-Strategie empfohlen.
Vorgehensmodell
In Bezug auf das Vorgehens- oder Steuerungsmodell könnte im umrissenen Kontext klassisch, also Meilenstein-basiert, als auch agil auf Basis von Inkrementen vorgegangen werden. Der realistische Mittelweg in der Öffentlichen Verwaltung lautet „hybrides Projektmanagement“, also die Kombination zweier oder mehrerer Projektmanagement-Methodiken. Hybrides Projektmanagement kombiniert eine klassische Rahmenplanung (Termine, Ressourcen, Meilensteine) mit agilen Vorgehensweisen z.B. Scrum in der eigentlichen Projektarbeit, hier bspw. der Softwareentwicklung. Dadurch kann auf der höheren Ebene, im Rahmen der Hardwarebeschaffung und passend zu Verwaltungsstrukturen, grob klassisch agiert werden. Im operativen Geschäft, wie der anschließenden Softwareentwicklung und -implementierung, ergänzen sodann agile Arbeitsweisen das iterative Element.
Mandat
Aufgrund der angespannten Personalsituation unter den Programmteilnehmern muss neben externer operativer Unterstützungsleistung ebenfalls eine externe Steuerung beauftragt und entsprechend befähigt werden (inhaltliches Mandat). Der Dienstleister, der weitere Dienstleister sowie ggfs. Internes Personal über Projekt- und Silo-Grenzen hinweg steuern soll, muss seitens des Auftraggebers / Programms explizit mit ausreichenden Kompetenzen ausgestattet sein, um dieser Anforderung erfolgreich nachkommen zu können.
Integration
Im Bereich der Hardwarebeschaffung und der Beschaffung der Software-Lizenzen ist keine vollumfängliche Integration notwendig, weil die Anforderungen über das Gewerk (Lieferung oder Leistung zum Pauschalfestpreis) sauber zu definieren sind und dementsprechend ein Need-to-Know der Lieferanten ausreicht. Aufgrund der Tatsache, dass die Kapazitäten der Programmteilnehmer gering sind, müssen die Dienstleister für die Weiterentwicklung und das Projektmanagement viele Aufgaben ebenjener übernehmen, wofür ein tiefes Wissen vorauszusetzen ist. Daher lohnt sich eine möglichst vollumfängliche Integration der Dienstleister in die Informationsflüsse des Programms.
