Viele Wünsche, begrenzte Ressourcen Mit der Roadmap die Projektlandschaft effizient gestalten

Individualsoftware muss beständig an veränderte Geschäftsprozesse und Bedürfnisse der Anwender angepasst werden. In einem dynamischen Umfeld mit vielen Anforderungen kann der Systemverantwortliche sie mit den vorhandenen Ressourcen oft nicht sofort umsetzen. Ralf Neubauer beschreibt an einem Beispiel, wie mit einer sog. Roadmap, d.h. einer langfristigen Grobplanung, die zahlreichen Anforderungen über mehrere Jahre so geplant werden können, dass die Prioritäten mit allen Beteiligten abgestimmt sind und eine weitsichtige Ressourcenplanung möglich ist. Dieses bewährte Vorgehen erlaubt es, auf einfache Weise Szenarien zu entwerfen und deren Auswirkungen zu beurteilen.

 

Download ZIPDownload ZIP
Download PDFDownload PDF

Viele Wünsche, begrenzte Ressourcen Mit der Roadmap die Projektlandschaft effizient gestalten

Individualsoftware muss beständig an veränderte Geschäftsprozesse und Bedürfnisse der Anwender angepasst werden. In einem dynamischen Umfeld mit vielen Anforderungen kann der Systemverantwortliche sie mit den vorhandenen Ressourcen oft nicht sofort umsetzen. Ralf Neubauer beschreibt an einem Beispiel, wie mit einer sog. Roadmap, d.h. einer langfristigen Grobplanung, die zahlreichen Anforderungen über mehrere Jahre so geplant werden können, dass die Prioritäten mit allen Beteiligten abgestimmt sind und eine weitsichtige Ressourcenplanung möglich ist. Dieses bewährte Vorgehen erlaubt es, auf einfache Weise Szenarien zu entwerfen und deren Auswirkungen zu beurteilen.

 

Wir empfehlen zum Thema Portfoliomanagement
6 Monate
14.05.2024
2.699,00,-
Masterclass Project Management Office (PMO)

Erfolgreich zum PMO Professional: Lösungen für Ihre Herausforderungen im Project Management Office in einem hybriden Umfeld! Mehr Infos

Benutzerspezifisch entwickelte Software (Individualsoftware) muss fortlaufend an die sich verändernden Geschäftsprozesse und Bedürfnisse der Anwender angepasst werden. In einem dynamischen Umfeld mit vielen Stakeholdern stellt dies eine große Herausforderung für die verantwortlichen, zentralen IT-Abteilungen dar. Diese sind in großen und mittleren, oft international organisierten Unternehmen zuständig für den Support dieser Softwaresysteme und müssen auch deren operative und langfristige Weiterentwicklung steuern. Zentrale IT-Systeme werden häufig von vielen unterschiedlichen Fachbereichen benutzt. Diese Fachbereiche stellen als interne Auftraggeber Anforderungen an die Erweiterung der Systeme. Diese Anforderungen entstehen aus geänderten Prozessen, spezifischen Arbeitsabläufen der Fachbereiche, einer geänderten Unternehmensorganisation (Zusammenschlüsse oder Abtrennungen von Unternehmensanteilen), einem erweiterten Einsatz der Software in neuen Organisationseinheiten oder Gesetzesänderungen, die in der Software abzubilden sind.

Auf diese Weise entstehen oft so viele Anforderungen, dass der für das IT-System Verantwortliche den Eindruck hat, er könne die Ressourcen der IT-Abteilung mit deren Erfüllung die nächsten drei bis fünf Jahre auslasten. Die Menge der Anforderungen ist an und für sich ein positives Zeichen, da die Benutzer die Software einsetzen und weiter entwickeln wollen. Für den Systemverantwortlichen bringen sie jedoch einige typische Herausforderungen mit sich, denen er sich stellen muss:

  • Er muss auf Basis von Anforderungen arbeiten, die oft nur als Stichwort vorliegen.
  • Als zentrale Stelle muss er dafür sorgen, dass die Anforderungen über alle Fachbereiche hinweg priorisiert werden.
  • Trotz der teilweise ungenauen Informationen muss er dem IT-Management und dem Management der Fachbereiche oft einen Termin- und Kostenplan über drei bis fünf Jahre im Voraus liefern.
  • Er muss frühzeitig seinen Ressourcenbedarf an das interne Ressourcenmanagement und externe Dienstleister liefern, damit die Anforderungen auch tatsächlich umgesetzt werden können.

Im Idealfall erstellt er in Zusammenarbeit mit den Fachabteilungen für unkonkrete Anforderungen zunächst ein Grobkonzept und dann ein Fachkonzept, bevor eine Bewertung für die Umsetzung stattfindet. In der Praxis stehen die hierfür benötigten Ressourcen oft nicht zur Verfügung. Ebenso müssen die Fachbereiche sehr früh ihre Budgets zur Finanzierung der Anpassungen planen und können dies deshalb nur anhand grober Informationen vornehmen.

Anhand eines Beispiels aus unserer Praxis zeigen wir eine Möglichkeit auf, wie Systemverantwortliche mit einem schlanken Prozess und einfachen Werkzeugen diese Herausforderungen bewältigen können, so dass Produkt-, Ressourcen- und Budgetplanung für alle Beteiligten schrittweise vom Groben zum Detail möglich wird.

Beispiel: Produktdaten an verteilten Standorten verwalten

In unserem Praxisbeispiel betrachten wir ein seit ca. vier Jahren in einem produzierenden Großunternehmen ausgerolltes Individualsystem zur Verwaltung von Produktdaten. Eingesetzt wird dieses IT-System bereits in sieben von weltweit 15 Produktionsstandorten des Unternehmens. Je Standort werden ein bis zwei Kernprozesse durch das System unterstützt. Daneben dient es unter anderem zur Organisation der Kommunikation mit Lieferanten.

Tabelle 1: Nutzungsmatrix (Ausschnitt) des Systems über die Standorte (FB= Fachbereich).

Das IT-System wurde im Rahmen eines umfangreichen Projekts erstellt und befindet sich jetzt im Regelbetrieb, bei dem täglich rund 9.000 Anwender über eine Web-Oberfläche Produktdaten pflegen oder auswerten. Die zentrale IT-Abteilung betreibt die Software und wartet sie. Darüber hinaus ist sie für Planung, Steuerung und Umsetzung der Weiterentwicklung zuständig. Obwohl das System zentral bereitgestellt wird, müssen für jeden neuen Standort fünf bis zehn Schnittstellen zu Logistik- und Finanzsystemen in der lokalen IT-Landschaft erstellt werden.

Pflege und Weiterentwicklung erfordert systematisches Vorgehen

Innerhalb der IT-Abteilung wurde ein Systemverantwortlicher für das System benannt. Der Systemverantwortliche ist zuständig für:

  • die Releaseplanung,
  • die Finanzierung der geforderten Änderungen durch die Fachbereiche, die das System verwenden,
  • die Klärung der Anforderungen,
  • die Beauftragung des externen Dienstleisters, welcher die Entwicklungsarbeiten am System vornimmt, sowie
  • die termin- und qualitätsgerechte Verfügbarkeit der Software.

Für die Bereitstellung neuer Funktionen sind zwei Release-Termine je Jahr fest definiert. Die Umsetzung von Anforderungen mit einem Aufwand von wenigen Tagen wird über eine fortlaufende Wartung durchgeführt, größere Änderungen am System werden in Form von Projekten abgewickelt. Die von den Fachbereichen gestellten Anforderungen werden dann vom Team des Systemverantwortlichen gemeinsam mit dem Fachbereich detailliert und in Fachkonzepten für die Weiterentwicklung dokumentiert.

Langfristiges Ziel ist es, das System weltweit an allen Standorten in jeweils beiden unterstützten Prozessen einzusetzen und damit Funktionen abzulösen, die derzeit noch durch andere Systeme abgedeckt werden. Diese Ziele sind in den unternehmensweiten IT-Bebauungsplänen und der IT-Strategie verankert.

Vielfältige Interessen müssen berücksichtigt werden

Alle Kommentare (2)

Jürgen
Sturany

Ich habe den Eindruck das man mangels Kenntnis professioneller Netzplantechnik wieder einmal EXCEL für solche Planungsaufgaben heranzieht. Ein Fehler der extrem häufig gemacht wird und nun sogar in unser ProjektMagazin Einzug gehalten hat... Traurig aber wahr. Immerhin, der Autor hat sich die (große) Mühe gemacht einen Artikel zu schreiben. Das erkenne ich voll und ganz an!

 

Guest

Den Kommentar von JS verstehe ich nicht. Grundlage für die die Erstellung eines Netzplans ist in der Regel ein PSP (wie er in Schritt 7 des Artikels beschrieben wird). Das hier vorgeschlagene Vorgehen geht aber doch davon aus, dass die Grundlagen für eine belastbare Planung (Abhängigkeiten, Aufwand, Termine) noch gar nicht gegeben sind. Welchen Mehrwert würde an dieser Stelle die Erstellung eines Netzplans bieten, der scheinbare Sicherheit vorgauckelt? Wie soll ich FAZ/FEZ/SAZ/SEZ berechnen, wenn ich weder die genauen Abhängigkeiten kenne, noch weiss, in welchem Jahr ich die Anforderung umsetzen möchte oder kann? Die vorgeschlagene "Roadmap" bietet da m.E. eine flexible Sicht auf die Themen und erlaubt ein "Herumspielen" mit unterschiedlichen Szenarien, inklusive Dokumentation von Voraussetzungen/Randbedingungen pro Szenario. Das Ergebnis dieses Spiels könnte dann den Input für eine detailliertere Planung liefern, ggf. auch einen Netzplan. Ich finde den Artikel sehr gut! Gerade die Empfehlung Unsicherheiten durch Analogschlüsse abzufedern ("Der Roll-out in Werk x ist ungefähr so komplex wie in Werk y") ist sehr hilfreich für die Praxis (nicht nur für die hier beschriebene Multiprojektumgebung). Aber auch das reicht noch nicht für eine belastbare Detailplanung. Es ist außerdem davon auszugehen, dass in jedem Unternehmen MS Office (oder kompatible Tools) vorhanden sind und von der Mehrheit der Mitarbeiter beherrscht werden. Für professionelle Netzplanungs-Software gilt beides eher nicht - das Ergebnis der Netzplanung wäre somit nur einem eingeschränkten Nutzerkreis zugänglich. Daher die zweite wertvolle Empfehlung: Für das neue Artefakt des "Anforderungs-Steckbriefs" wurde nicht etwa ein neues Template entwickelt oder Tool eingeführt, sondern das vorhandene Template "Projektauftrag" verwendet! Damit wird die Widerverwendbarkeit und die Akzeptanz bei den Mitarbeitern deutlich erleichtert. Zugegebenermaßen ist das weniger spektakulär als sich als Berater für die Einführung bisher "unbekannter" Tools & Methoden feiern zu lassen.