Was charakterisiert Projekte, welche die Abspaltung einer Geschäfts-Entität zum Inhalt haben? Dies sind typischerweise nicht Projekte, die neue Funktionalität erstellen. Vielmehr werden Kunden-Stammdaten geteilt oder dupliziert, Lizenzen und User-Berechtigungen neu vergeben, Software-Systeme, ja ganze System-Landschaften werden gegebenenfalls geklont und auf anderer Plattform wieder aktiviert. Dies erfordert umfangreiche Koordination und Kommunikation, detaillierte Planung sowie umfassende Testaktivitäten, Nagler & Company kann Sie dabei unterstützen.
Warum ist die erfolgreiche Durchführung eines solchen Projektes eine hoch komplexe Aufgabe? Man erstellt einen Projektplan, holt sich das notwendige Budget, organisiert die Ressourcen – der Plan wird exekutiert, das Monitoring ordentlich aufgesetzt. Einfach, oder?
Je nachdem, ob man ein agiles Vorgehen wählt, oder mehr dem traditionellen Wasserfallmodell folgt, kann ein entsprechendes Rahmenwerk generiert werden, woraus sich das weitere Vorgehen ableitet. Dieses besteht beispielsweise aus einer der etablierten Projektmanagement-Methoden (wie z.B. PRINCE2 oder SCRUM), wobei darauf zu achten ist, dass von der gewählten Methode nicht abgewichen wird. Sehr häufig passiert leider genau das Gegenteil – so deklariert man sich zum Beispiel zum agilen Vorgehen, teilt dann aber den Gesamtaufwand in Sprints, vergibt von Seiten der Projektleitung Arbeitspakete und verschiebt diese je nach Notwendigkeit von einem Sprint in den nächsten. Damit hat man sich zwar „Agilität“ auf die Fahnen geheftet, ist aber nach wie vor im Korsett des traditionellen Wasserfallmodells verankert. Die Vorteile der agilen Vorgehensweise können nicht lukriert werden.
Häufig anzutreffenden Fehler werden in den nachfolgenden Absätze kurz umrissen. Um beispielsweise einen Plan zu erstellen (bzw. im Rahmen eines agilen Vorgehens, die Backlog-Items), muss man zu allererst wissen, wie denn die zu erstellende Funktionalität aussehen soll. Das heißt die User-Anforderungen müssen detailliert ausgearbeitet werden. Dies ist im Falle der Separation einer Geschäftseinheit zwar mehr oder minder vorgegeben, darf aber trotzdem nicht vernachlässigt werden. Eine der häufigsten Gründe für Verzögerungen (bzw. im Extremfall das Scheitern) solcher Projekte sind unklare User-Anforderungen. Dies reicht von, im einfachsten Fall, unzureichender Dokumentation bis zum exorbitanten Scope-Creep, der jeglichen Projekterfolg in Frage stellt.
Geht es um Ressourcen, die benötigt werden, um das Projekt durchzuführen, stellen sich zahlreiche Fragen. Werden beispielsweise Tester (Anwender, welche die erforderliche Funktionalität kennen und das System auch nutzen) zur angepeilten Zeit im notwendigen Umfang zur Verfügung stehen, oder sind sie durch ihre üblichen Tagesabläufe ausgelastet? Dieser Punkt ist eine Falle, in die sehr häufig getappt wird. Man sollte nicht unterschätzen, dass Anwender je nach Geschäftssituation vorwiegend an ihren täglichen Linienaufgaben gebunden sind, als dass Sie frei für Test-Aktivitäten sind. Sie werden in dieser Priorität oft auch von ihrem eigenen Management unterstützt (oder sogar diesbezüglich angewiesen) – unabhängig von vom selben Management während der Planungsphase gegebenen Commitments.
Das Projektmonitoring inkludiert typischerweise ein oder mehrere der nachfolgenden Fragen:
- Gibt es regelmäßige Status-Reports?
- Sind alle Stakeholder eingebunden?
- Ist man sich der Projektrisiken bewusst und behält man diese im Auge?
- Gibt es ein etabliertes Defect-Management System?
Speziell der letztgenannte Punkt, das Vorhandensein eines dezenten Defect-Management Systems ist kritisch – insbesondere, wenn die Umsetzung geographisch und womöglich auch auf mehrere Projekt-Zulieferer verteilt stattfindet. Ein Tracking von Defects und Incidents per Excel, mag es noch so durchdachte Makros beinhalten, ist besonders unter solchen Umständen nicht empfehlenswert.
Hier ist selbstverständlich nur ein kurzer Ausschnitt illustriert. Fakt ist jedoch, Stolpersteine gibt es viele. Und irgendetwas geht immer schief.
Sobald allerdings etwas schiefläuft, beginnt man reaktiv zu agieren. Das heißt, man ist ab diesem Zeitpunkt mehr und mehr damit beschäftigt, aus dem Sumpf, in dem man sich verlaufen hat, wieder auf den feinen geordneten Weg zu finden. Dieses natürliche Bestreben übertrumpft ab diesem Zeitpunkt das Bedürfnis, planmäßig vorwärts zu kommen. Das bedeutet wiederum, man kann sich nicht darauf fokussieren, warum etwas schiefgegangen ist. Und damit ist neuerlichen „Schieflagen“ Tür und Tor geöffnet.
Hier hilft der Blick von außen
Ein unabhängiger Projekt-Review analysiert ohne Vorbelastung das Vorgehen und die Methodik , identifiziert durch strukturiertes Vorgehen Schwachpunkte und schlägt korrigierende Maßnahmen vor. Im Projekt-Review werden sämtliche Aspekte anhand gesetzter Kriterien beleuchtet und können somit bewertet und in übersichtlicher graphischer Form dargestellt werden.
Diese Aspekte umfassen:
- Vorgehensmethode (Agil, Wasserfall,…)
- Planung
- Ressourcen-Besetzung und ‑Verfügbarkeit
- User-Anforderungen
- Zielarchitektur
- Identifikation der Stakeholder und Kommunikation
- Defect-Tracking
- Kommunikation im Projekt-Team (informell und formell)
- Evaluierung der Projektrisiken
Nagler & Company greift für den Review von Projekten – speziell im Bereich der Abspaltung von Geschäfts-Entitäten – auf langjährige Erfahrung zurück. Unsere Spezialisten sind seit Jahrzehnten in unterschiedlichsten Funktionen in Projekte eingebunden und bringen ihr Know-How zum Vorteil unserer Kunden ein.
Change is constant – sprechen wir darüber!
