Im zweiten Teil unseres Gesprächs mit Georg Strömer zum Thema Agilität im IT-Projektmanagement geht es unter anderem darum, wann klassische Methoden besser geeignet sind.

 

Kann man in einem regulierten Umfeld überhaupt agil arbeiten? Schließen sich Regulierung und Agilität nicht gegenseitig aus?

Agilität bezieht sich auf die Art und Weise, wie neue Systeme und Lösungen erarbeitet werden und stellt deshalb keinen Widerspruch zur Frage der Regulierung dar. Entscheidend ist ja das Ergebnis. So könnte eine Anforderung an ein mithilfe von agilen Methoden oder Prinzipien entwickeltes System sein, dass es leicht validierbar ist.

 

Worin liegen die besonderen Vorteile von agilen Vorgehensweisen im Pharma-/Medizin-Umfeld?

Grundsätzlich ist es so, dass Ergebnisse in einem Projekt passgenauer sind, wenn die Anforderungen der Endanwender ausreichend berücksichtigt werden. Und hier spielen agile Vorgehensweisen ihre Vorteile in besonderem Maße aus, da ich durch die schnellen schrittweisen Pilotumsetzungen sehr schnell Erfahrungswerte bzw. Feedback aus dem praktischen Einsatz vorliegen habe. Das heißt, dass ich gegebenenfalls schnell und auf den Punkt reagieren und Abläufe oder Funktionen optimieren kann.

Anders liegt der Fall, wenn es um Projekte geht, in denen Softwareprodukte mit bereits vorhandener, großer Funktionstiefe zum Einsatz kommen. Denn aufgrund der in diese Systeme eingebrachten branchenspezifischen Erfahrungen sind Detailausarbeitungen bezüglich der benötigten Funktionen und Abläufe meist unnötig. Hier wird dann eine passende Konfiguration erarbeitet, die entsprechend implementiert wird und für die die Mitarbeiter geschult werden.

 

Können Sie den Unterschied zwischen agiler und klassischer Vorgehensweise an einem Beispiel erklären?

Vielleicht macht ein Bild es klarer als ein bestimmtes Beispiel: Sie können einen Fluss komplett begradigen und in einem Betonbett führen oder ihn natürlich mäandrieren lassen. In beiden Fällen kann man auf diesem Wasserweg sein Ziel erreichen.

Ersteres kann sinnvoll sein, wenn Sie die Rahmenbedingungen ganz genau kennen, also beispielsweise wissen, wie viel Ladung Sie auf einem Containerschiff einer bestimmten Größe über eine bestimmte Strecke schnell und sicher in einen großen Hafen bringen möchten.

Wenn Sie dem natürlich verlaufenden Fluss folgen, müssen Sie Ihr Schiff wahrscheinlich kleiner bauen, wollen zwar auch irgendwann in den großen Hafen, aber das Tempo ist nicht so entscheidend. Im ersten Schritt möchten Sie vielleicht nur, dass sie die Ladung auch schon in kleineren Häfen löschen können, um straßengebundene Transportkosten zu sparen, sind aber auch offen für weitere Ideen.

Das Projekt Betonbett kann problematisch werden, wenn die Strecke von X Kilometern eine mehrjährige Bautätigkeit bedeutet und das bereits gekaufte Containerschiff womöglich mit einem Treibstoff fährt, der sich am Ende der Bauzeit drastisch verteuert hat oder die Ladekapazitäten nicht mehr auf die aktuellen Anforderungen ausgelegt sind. Dann haben Sie alles fertig geplant, aber auf Anforderungen, die so gar nicht mehr gegeben sind.

Im Fall des mäandrierenden Flusses und der „offeneren“ Haltung hingegen stellen Sie vielleicht fest, dass die kleinen Häfen zwar höhere Gebühren verlangen, Sie dafür aber die frei werdende Ladefläche nutzen können, um zusätzlich lukrativere Aufträge für Transporte zwischen den kleinen Häfen anzunehmen. Sie brauchen zwar mehr Leute, aber der Erholungswert der landschaftlich schöneren Strecke führt dazu, dass ihre Crew mit mehr Begeisterung arbeitet, weniger krank ist und so bereits während der Fahrt Wartungsarbeiten durchführen kann. Sie erkennen Probleme und neue Anforderungen viel schneller und können entsprechend reagieren.

 

Wer oder was entscheidet, ob ein agiler oder ein klassischer Projektmanagement-Ansatz sinnvoller ist? Lassen sich die beiden Ansätze auch kombinieren?

Letztlich geht es immer darum, das Risiko einer Fehlinvestition besser in den Griff bekommen und, wie eben skizziert, denke ich, dass Unternehmen mit einem agilen Ansatz meist besser fahren.

Das heißt nun keinesfalls, dass man auf Biegen und Brechen alles agil betrachten muss. Es wird immer auch einfache, eindeutig umrissene Modelle mit klarem Ausgang geben, für die es nicht erforderlich ist, agil vorzugehen.

Kombinationen der beiden Management-Ansätze in einem Projekt sind aus unserer Erfahrung allerdings wenig sinnvoll. Falls beide zum Tragen kommen sollen, beispielsweise weil die betreffenden Mitarbeiter noch nicht ausreichend mit agilen Methoden vertraut sind, funktioniert das nur, wenn es sich um klar abgrenzbare Teilprojekte handelt. Im Zweifelsfall muss man versuchen, Teilprojekte entsprechend zuzuschneiden.

Sprechen Sie mich einfach an, gemeinsam finden wir den für Ihr IT-Projekt am besten geeigneten Managementansatz!