Wann kommt Agilität an seine Grenzen? Agile Methoden außerhalb der Software-Entwicklung

Agile Methoden im Projektmanagement haben sich seit vielen Jahren bewährt. XP und insbesondere Scrum, um nur zwei zu nennen, sind in der Softwareentwicklung etabliert.

Die Vorteile der agilen Vorgehensweise in der Entwickung komplexer Software-Anwendungen sind anerkannt. Was ist aber mit den vielen anderen Projektarten? In Bau- und großen Engineering-Projekten kommen agile Methoden an ihre Grenzen. Auch darüber gibt es, denke ich, keinen Dissens.

Im Moment arbeite ich einem großen Beschaffungsprojekt. Zwei Werkzeugmaschinen werden für die Serienfertigung von Motorenteilen angeschafft und in eine Produktionslinie eingephast. Ähnlich zu klassischen Bauprojekten liegt es auch hier nahe, agile Methoden in der Schublade zu lassen. Das Vorgehen ist gut planbar. Es ist bekannt, welche Teile die Maschinen fertigen sollen, wie diese vor und nach der Bearbeitung durch die Maschine auszusehen haben, wie viele Teile gefertigt werden sollen usw. Kurz: Die Anforderungen sind also klar.

Im Großen und Ganzen stimmt das auch. Aber auch in solchen scheinbar klar strukturierten Projekten gibt es Bereiche, denen Agilität gut tut. Der Grund ist derselbe, der aus meiner Sicht auch der Hauptgrund im Softwarebereich ist: Unklare, unbekannt, unscharfe oder sich ändernde Anforderungen.

Allerdings ist in meinem hier beschriebenen Projekt Agilität ungleich schwerer umzusetzen als in der Softwareentwicklung. Erstens muss der Hersteller die Maschine natürlich irgendwann die Maschine tatsächlich entwickeln, Komponenten beschaffen und die Anlage bauen. Änderungen nur noch in engen Grenzen möglich. Es ist ja auch logisch: Je weiter das Projekt fortgeschritten ist, umso geringer sind Änderungsmöglichkeiten bzw. umso teurer oder zeitaufwendiger werden Änderungen. Binsenweisheit.

Was also kann man in Bauprojekten oder Logistikprojekten von den agilen Ideen übernehmen?

Man kann definieren, bis zu welchem Zeitpunkt es in welchen Bereichen Änderungen geben darf. Oder andersherum: Man kann definieren, welche Parameter zu welchem Zeitpunkt definiert sein müssen.

Vorteil:

Ich bleibe in meinem Projekt in einigen Punkten wesentlich länger flexibel und kann auf geänderte Anforderungen noch reagieren.

Das formal aufwändige und teure Änderungsmanagement kann man sich bezogen auf diese offenen Anforderungen sparen. Das spart neben Zeit auch Geld, verringert den Planungsaufwand und schont die Nerven aller Beteiligten.

Nachteil:

Es müssen neue Ansätze im Angebots-, Preis- und Bezahlverfahren gefunden werden. Ein umfassendes Festpreisangebot ist einfach nicht mehr möglich.

Agiles Vorgehen ist nach meiner Erfahrung in der „Nicht-IT“-Industrie neu und fremd. Bisher stoße ich auf große Widerstände mit solchen Ideen.

In der Software-Industrie hat es Jahre gedauert, bis Scrum akzepiert war. Vielleicht wäre eine Initiative der PM-Verbände sinnvoll, um agile Methoden in neuen Bereichen zu entwickeln. Wäre spannend!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.