Meist wird das Eintreten dieser Mängel mit einer unzureichend proffessionellen Anwendung der vorgegeben Prozesshäuser begründet. Aber ist das richtig ?
Willkommen in der VUCA – Welt
In einem zunehmend dynamischen und volatilen Wirtschaftsumfeld sind naturgemäß auch die Projektteams im Anlagebau ständig neuen Einflüssen, Veränderungsprozessen und Unsicherheiten ausgesetzt, auch wenn man von außen betrachtet dieses nicht immer wahrnimmt.
Alternativen
Diese Problematik wurde im Bereich der Softwareentwicklung schon in den 90ziger Jahren schmerzlich bemerkt, getrieben auch durch die nahezu unendliche Vielzahl der möglicher Lösungsvarianten immer komplexerer Anforderungen an die IT-Systeme. Oft wirkten sich Veränderungen von Rahmenbedingung im Zeitraum des Projektes dahingehend aus, dass die benötigten Funktionen des am Ende des Projektes übergebenen Produktes sich gegenüber dem zu Anfang angeforderten deutlich unterscheiden.
Basierend auf Konzepten, die erstmals im 2.Weltkrieg in der Entwicklung von Flugzeugen in den USA erprobt wurden, wurde Anfang dieses Jahrtausend ein neuer Fokus für die Herangehensweise in der Softwareentwicklungspraxis entwickelt. Dieser trägt der Erfahrung Rechnung, dass die zu entwickelnden Produkte zu Beginn des Projektes nicht vollständig durchdacht sind und meist auch nicht sein können. Damit sind sie weder vollständig beschreibbar und spezifizierbar. Um mit dieser Realität umzugehen wurden andere Prozesse und Abläufe notwendig, als die, die in der bisherigen Praxis anzuwendet wurden.
Die Grundgedanken dazu wurden im „Agilen Manifest“ beschrieben und werden heute in vielen Managementbereichen in Varianten angewandt.
Dennoch ist es auch im Bereich von Anlagen- und Bauprojekten eher der Regelfall als die Ausnahme, dass es trotz aller Proffesionalität zu Problemen mit den Qualitäts-, Kosten- oder Terminzielen kommt.
Warum ist das so ?
Das Wasserfallmodell kommt trotz professionellem Change- und Claim-Management schnell an seine Grenzen, wenn diese Veränderungen der Regelfall des Tagesgeschäftes werden und so der Planungsaufwand explodiert. Eine Vertrags- und Umgangskultur, die von Misstrauen, Konflikten und einer daraus resultierenden aggressiven Streitkultur geprägt ist, fördert die Schwierigkeiten. Wirtschaftsliberale Ansätze, die proklamieren, dass alle Unternehmen sich wirtschaftlich immer und in alle Richtungen optimieren wollen, lassen jeden Anpassungswunsch und jede Verzögerung schnell zum Objekt des Vertrags- und Claimmanagements werden.
Um eine Benachteiligung der eigenen Position zu vermeiden, leben wir also mehr eine Vertragskultur als eine Projektpartnerschaft. Der Versuch die Verträge durchzusetzen, ist das vermeintlich probate Mittel, das eigene Projektziel zu erreichen. Da aber jeder Teilnehmer am Projekt vertraglich in einer anderen Situation ist, wird auch sein Projektziel ein anderes sein.
Es stellt sich die Frage, ob die Summe des notwendigen Ressourceneinsatzes zur Rettung der eigenen Position im Sinne dieser Kultur, insbesondere auch im Angesicht des aktuellen Fachkräftemangels, sinnvoll ist, oder ob durch Einführung einer Kultur partnerschaftlicher Geschäftsbeziehungen sowohl eine Begrenzung der Kosten-, als auch der Terminüberschreitungen in Realität nicht besser erreichbar wäre.
Auch bleibt festzustellen, dass es auch im Anlagenbau kaum ein Projekt gibt (und das gilt wohl auch in vielen anderen Branchen, in denen Kundenprojekte abgewickelt werden), in dem alle Details der Realisierung und der Anlage bei Vertragsunterschrift spezifiziert sind. Die ungeplante aber notwendige Kernbohrung durch Wände und Ebenen des neuerichteten Betonbaus gehört zur Tagesordnung.
Im Regelfall erreichen wir diesen Spezifizierungsgrad nicht einmal mit dem ersten oder zweiten Design-Freeze. Erst die „As-Build“-Dokumentation kommt diesem Anspruch nach. Wesentlich sind nur die vom Kunden vorgegebenen essenteillen Requirements, die sicherstellen, dass die Anlage nach Übergabe auch ihren Kernzweck erfüllt. Der Weg bis zu dieser Anlage, sowie viele technische Details einer solchen Anlage werden erst im Rahmen des Engineerings festgelegt und abgestimmt. Das aber erinnert sehr stark an den agilen Ansatz.
Ein „Agiles Manifest“ für den Anlagenbau
So wie in die Bauausführung mit Lean-Construction bereits Modelle und Ansätze aus der Welt des Lean-Production hineinadaptiert wurden, bieten sich auch für das Engineering und die Planung Ansätze des agilen Managements an.
Agilität bedeutet Gewandtheit, Reaktionsvermögen, Flexibilität und Wendigkeit. Verständlich wird dieses Erfordernis, wenn man bestimmte Grundanahmen als Realität akzeptiert:
- Veränderungen sind der Regelfall, nicht die Ausnahme
- Im Zentrum von Leistungen stehen Menschen, nicht Prozesse oder Tools
- Führung muss dienen – sowohl den Mitarbeitern als auch dem Ziel
- erfolgreiche Entwicklung erfolgt iterativ und inkrementell
- Erfolge sind bewertbar, aber nicht vollumfänglich messbar
Betrachten wir diese Realitäten für die Anlagenplanung und die Bauausführungsplanung als den Kernbereich von Projekten im Anlagenbau und fokussieren auf zufriedene Kunden (also einem Kunden der aufgrund guter Erfahrungen gerne den nächsten Auftrag erteilt, anstatt aufgrund des Vermutung das kleinere Übel zu wählen), so sind die Parallelen zur Situation in der IT-Systementwicklung der 90ziger Jahren sichtbar. Mit der Fokussierung auf zufriedenen Kunden müsste also auch das agile Manifest als Grundidee übertragtbar sein.
Eine mögliche Adapation für den Anlagenbau, könnte wie folgt aussehen:
Individuen und deren Interaktionen | vor | Prozessen und Werkzeugen |
Funktionierende Technik | vor | umfassender (Detail-)Dokumentation |
Zusammenarbeit mit den Kunden | vor | Vertrags- und Claimverhandlungen |
Eingehen auf Veränderung | vor | der Befolgung von Plänen |
Schauen wir uns im folgenden die zugrundeliegenden fünf Annahmen an und was sie für den Anlagenbau bedeuten:
Annahmen
1.) Veränderungen als Regelfall akzeptieren
Auch der Anlagenbau agiert in einem zunehmend volatilen Umfeld, auf das immer mehr disruptive Ereignisse einwirken. Die typischen Märkte verändern sich, Anlagen werden heute in immer kürzeren Zyklen geplant, angepasst und modernisiert. Technische Entwicklungen erfolgen schneller und bewirken ebenso wie gesellschaftliche Veränderungen neue Anforderungen. Noch verfügen wir in Deutschland über ein stabiles politisches System, nichts desto trotz verändert sich aber die politische Lage in immer kürzeren Zyklen mit immer stärkerem Einfluß von Influenzern. Dieses hat Einfluss auf die Abwicklung von Projekten.
Zu akzeptieren, dass Veränderungen permanent und real eintreten, zwingt zu einem professionellen Umgang damit. In der klassischen Form der Projektabwicklung werden Veränderungen in erster Linie als Störungen empfunden und auch so behandelt. Der Projektleiter hat die Aufgabe die Störung abzuwehren, zu begrenzen oder zu kompensieren. Über das Vertragsmanagement wird mit viel Aufwand der Versuch gestartet, dieser Aufgabe nachzukommen und die Auswirkungen zu mindern bzw. über das Claim-Management Kompensationen zu erreichen.
Die agile Projektabwicklung versteht Veränderung nicht als Störung, sondern als gegeben (ggf. sogar als willkommen) an. Damit wird das Veränderungsmanagement integraler und wesentlicher Bestandteil der Abwicklung und nutzt kreative Methoden zur Lösungsfindung und Innovation. Das auf Abwehr und Kompensation ausgerichtete klassische Vertrag- und Claim-Management ist diesem Ziel nach- und untergeordnet. Es wird ergänzt bzw. ersetzt durch ein kreatives und kooperatives Changemanagement, das für die Veränderung gemeinsam mit dem Kunden oder Lieferanten eine Lösung sucht und findet, in denen selbstverständlich auch die kommerziellen und terminlichen Aspekte berücksichtigt sind.
2.) Die Menschen stehen im Zentrum der Leistungserbringung
Um Projekte im Anlagenbau zu realisieren ist die Zusammenarbeit verschiedenster Fachbereiche zwingend erforderlich. Üblicherweise werden die notwendigen Arbeiten in viele kleine separate Arbeitspakete mit jeweils nur einem fachlichen Schwerpunkt unterteilt, die von einzelnen Kollegen oder einem kleinen Team von Spezialisten realisiert werden können. Bei genauer Betrachtung wird jedoch deutlich, dass diese Arbeiten meist nur aufgrund von Informationen erfolgen können, die über eine Vielzahl von Schnittstellen durch andere bereitgestellt werden.
Um diese Informationen sicherzustellen wird die Kommunikation durch Strukturen und Schnittstellen vorgegeben, die den Informationsfluss sicherstellen sollen und die Arbeitspakete mit einander verzahnen. (Verzeichnisstrukturen, Dateinamenskonventionen, Kommunikationsmatrizen, Statusmeetings, Protokolltemplates, Abstimmungskonferenzen, Workflowdefinitionen, …)
Bertrachtet man gut laufende Projekten, so stellt man fest, dass die meist auf Mitarbeitern basieren, die sich als echtes Team verstehen und als solches agieren. In solchen erfolgt die benötigte Kommunikation überwiegend außerhalb von vorgegebenen Kommunikationsstrukturen. Diese werden zwar pro Forma zusätzlich genutzt, bedeuten aber nur einen geringen Gewinn an Qualität und Sicherheit. Benötigte Schnittstellen, Formate und Prozesse entwickeln die Mitarbeiter solcher Teams mit pragmatischen Ansätzen nach eigenem Bedarf selbst und lassen diese ggf. auch wieder sterben.
Wenn wir davon ausgehen, dass die Mitarbeiter in unseren Projekten gut ausgebildet sind und wissen was sie tun und brauchen, warum dann nicht die im Projekt arbeitenden Menschen mit Ihren Bedürfnissen in den Mittelpunkt stellen. Strukturen, Regeln, Vorgaben… soweit benötigt und akzeptiert ja, aber weniger fixierte Prozesse nutzen und statt dessen mehr Verstand. Spielräume für Selbstorganisation ermöglichen Flexibilität und erweisen sich als produktivitätssteigernd.
3.) Führung dient – sowohl den Mitarbeitern als auch dem Ziel
Studien über den Erfolg von Projekten und damit über den Erfolg des Projektmanagements weisen leider immer wieder erschreckend niedrige Erfolgsraten auf. Weniger als 20% der Projekte werden trotz umfangreicher PM-Prozesshandbücher, technischer Hilfsmittel und eines engen Controllings erfolgreich abgeschlossen, zumindest, wenn man die zu Beginn des Projektes festgelegten Ziele betrachtet.
Die in diesen Studien ermittelten Ursachen verweisen auf das immer noch fest verankerte Menschenbild aus der Frühzeit der industriellen Revolution, wie sie von F.W. Taylor Anfang des letzten Jahrhunderts für die Unternehmensorganisation beschrieben wurden. „Unten wird gemacht, oben wird gedacht!“
Durch konkrete Vorgaben für Verhalten, Aufgabe und Handlung wurde es auch weniger Qualifizierten ermöglicht, fachlich zwar begrenzte, aber dennoch produktive Arbeit zu leisten. Jedoch wird so die Flexibilität der Organisation eingeschränkt, da die Möglichkeit kreative Entscheidungen treffen auf wenige Vorgesetzte konzentriert wird, die in höheren Bereichen der Hierarchie angesiedelt sind. Diesen fehlt aber oft das Detailwissen zu den Problemen und zu deren Lösungsoptionen. Die in dieser Form getroffenen Entscheidungen sind für die betroffenen Mitarbeiter oft unverständlich. Die Annahme, dass es noch andere ihnen unbekannte Aspekte für diese Entscheidungen gibt, kasschiert dieses nur begrenzt. Schnell empfinden sie solche Entscheidungen als Sabotage an den von ihnen erbrachten Leistungen und als Ignoranz ihrer Kompetenz und ihres Engagements. Das führt zu Demotivation, zu Frustration und letztendlich zu Fluktuation.
Seit dem Ende des letzten Jahrtausends verändert sich das Menschenbild in der Wirtschaft wesentlich. Unsere Arbeitsmärkte sind heute überwiegend von hoch qualifizierten Mitarbeitern geprägt, die wir auch aufgrund der immer weiter zunehmenden Komplexität in Wirtschaft und Technik dringend brauchen. Diese Menschen sind meist intrinsisch motiviert und fordern, ihre Fähigkeiten, ihre Kompetenzen sowie ihre Kreativität selbstverantwortlich einbringen zu können. Diese Forderungen, eine akzeptable Vergütung und vor allem das Wahrnehmen ehrlicher Wertschätzung als Rückmeldung für ihre Leistung sind heute die wesentlichen Motivatoren.
Agile Führung fokussiert genau in diese Richtung. Grundlage ist ein Menschenbild, das diese intrinsische Motivation fördert und bewusst versucht zu leiten anstatt zu führen. Der Mitarbeiter wird als kompetent, kreativ und befähigt verstanden. Die Führung solcher Teams versteht sich daher mehr als dienende Führung (Servant Leadership). Diese gibt lediglich das Ziel und einen Rahmen für die Selbstorganisation des Teams vor und versucht Behinderungen für die Mitarbeiter und das Team zu beseitigen. Servant Leadership verzichtet auf die Nutzung eines erheblichen Teils der bisheriegen Weisungs- und Kontrollmechanismen der Vorgesetzten.
4.) Erfolgreiche Entwicklung erfolgt iterativ und inkrementell
Iterationen in Form von häufigen Feedbackschleifen prägen agile Prozesse. Im Rahmen dieser Schleifen werden Step-by-Step die Teile der Gesamtleistung inkrementell geklärt und geschaffen. Die Kunden bleiben in die Entwicklung eingebunden, so dass die generierten Werte über Reviews ständig bestätigt, verändert, optimiert, überarbeitet und erweitert werden können.
Ständige Qualitätskontrollen sind Teil dieses Prozesses. Der Kunde erlebt den den Fortschritt des Projektes mit und ist über das sich entwickelnde und entstehende Produkt und die Probleme gut informiert. Größere Differenzen zwischen den Vorstellungen des Kunden und dem realen Ergebnis werden auf diese Weise vermieden. Dieses betriff auch Rahmenparameter wie die Termin- und Kostensituation. Notwendige und gewünschte Anpassungen fliessen in den Prozess ein und werden lösungsorientiert betrachtet und bearbeitet. Gemeinsam mit dem Kunden und/oder Lieferanten wird versucht aus qualitativer, aus terminlicher und aus kommerzieller Sicht eine sinnvolle Lösung zu entwickeln.
Auch wenn im Anlagenbau das finale System genauer feststeht, als dieses beispielsweise in der IT oft der Fall ist, so sind doch viele Aspekte auf dem Weg dorthin erst im Rahmen der Entwicklung festzulegen. Nutze ich eine große, zwei mittlere oder drei kleine Pumpen, um eine bestimmte Menge Fluid zu bewegen? Was für Materialien nutze ich, um Rohrstrecken zu bauen? Steuere ich Ventile mit Luft, Hydraulik oder elektrisch an? Wie sieht das Brandschutzkonzept aus? ….. Hieraus ergeben sich Optionen und Fragen.
Entscheidungen führen ggf. zwar in technisch korrekte Lösungen, die seitens des Kunden aber nicht favorisiert werden. Durch kurze Iterationen kann schnell nachgesteuert und so der Aufwand für Fehlentwicklungen klein gehalten.
5.) Erfolge sind bewertbar, aber nicht exakt messbar
Klassische Projekte bewerten den Projekteerfolg als Vergleich zwischen dem Output und den ursprünglichen Plänen, die zu Projektbeginn festgelegt wurden (Meilensteine, Dokumentenlisten, Requirements, Kostenrahmen, Termine, sonstigen Anforderungen, … ).
Der zu realisierende Kundennutzen liegt damit allein in der Verantwortung des Auftraggebers, der diese Verantwortung in Form der von ihm erstellten, bzw. beigestellten Spezifikation als Vertragsbestandteil wahrnimmt. Sind in dieser Spezifikation aber Fehler vorhanden, oder ist diese unklar formuliert, so werden diese Fehler oder Missverständnisse im Zweifelsfall umgesetzt, was auch dazu führen kann, dass die Anlage nach Inbetriebsetzung nur eingeschränkt genutzt werden kann. Der Kunde erhält zwar genau das, was bestellt ist, ist aber mit dem Ergebnis unzufrieden.
In agil abgewickelten Projekten werden die Nützlichkeit und die Funktion der Anlage (bzw. des Produktes) in den Vordergrund gesetzt. Die konkrete Beschreibung der Anlage tritt dabei hinter dem Nutzen und der Funktion zurück.
Dieser Nutzen wird in der Spezifikation beschrieben, ist aber auch im Laufe des Projektes anpassbar. Wesentliches Projektziel ist der für den Kunden entstehenden funktionale Mehrwert aus Sicht des Kunden. Um dieses zu erreichen ist eine durchgehend enge Zusammenarbeit und intensive Kommunikation mit dem Kunden während der Umsetzung unverzichtbar. Änderungen werden von beiden Parteien nicht als Störung empfunden, sondern als Bestandteil des Prozesses. Dieses inkludiert aber auch eine offene und ehrliche Kommunikation über die Kosten der Veränderung und über die terminlichen Auswirkungen.
Der relativ exakt bestimmbare Vergleich zwischen Spezifikation und Output weicht also Bewertung der Zufriedenheit des Kunden mit dem Ergebnis anhand den in der Spezifikation festgelegten Zielen.
Implementierung in Projekten im Anlagenbau
Durch die ständigen Veränderungen und Unsicherheiten werden die Anforderungen an die Projektteams auch im Anlagebau immer größer. Den eher linearen Abwicklungsmodellen der klassischen Projektmanagement-Methoden werden immer mehr die Grenzen aufgezeigt. Die meist bis zum Ende der aktuellen Projektphasen (teilweise bis zum Projektende) durchgerechneten Planungen sind häufig nachzuführen und somit hochdynamisch. Dieses bedeutet einen erheblichen Aufwand. Und leider auch Frustration, da schon die Planungsanpassungsarbeit in dem Bewusstsein erfolgt, dass der Verlässlichkeitshorizont sehr begrenzt ist. Warum also viel Arbeit in etwas stecken, dass bereits Morgen, nächste Woche oder im nächsten Monat makulativ ist?Die Situation
Der Regelfall in Großprojekten sind erhebliche Kosten- und Terminüberschreitungen. Diese steigen statistisch sowohl mit der Laufzeit der Projekte als auch mit dem Einfluss öffentlicher Stakeholder. Die Kultur in solchen Projekten ist von Misstrauen zwischen den Vertragspartnern und darauf basierenden Konflikten geprägt. Hieraus resultieren viele Auseinandersetzungen. Im Managementteam solcher Projekte haben die Funktionen Vertragsmanagement, Claimmanagement und juristische Beratung oft die gleiche Personalstärke wie die der technischen Umsetzung. Dabei wächst der Arbeitsaufwand dieser Bereiche mit zunehmender Projektdauer aufgrund der entstehenden Historie überproportional. Anstatt im Laufe des Projektes ein Vertrauen mit Kunden oder Lieferanten aufzubauen, dass die Zusammenarbeit bei Folgeprojekten vereinfacht und den Folgeauftrag sichert, führt dieses dazu, dass die Wahrnehmung des Geschätspartner negativ vorbesetzt ist und nichts partnerschaftliches mehr hat. In der Folge müssen für jeden neuen Auftrag neue Kunden akquiriert und für jedes neue Projekt neue Lieferanten gefunden und bewertet werden. Ein hoher Aufwand sowohl für den Sales- als auch für den Procurement-Bereich.
Adaption von Methoden
Nun unterscheiden sich Software und Anlagenbau wesentlich, obwohl, wie ausgeführt auf abstrakter Ebene viele Ähnlichkeiten vorhanden sind. Um nun agile Methoden und Ansätze in den Anlagenbau zu adaptieren sind die Rahmenbedingungen zu betrachten. Aspekte sind zum Beispiel:- Anzahl der Stakeholder und Interessen
- Flexibilitätsbedarf (wie häufig sind Veränderungen)
- Komplexität der Lösung
- Länge möglicher Iterationszyklen
- Notwendige Reaktionsgeschwindigkeit
- Projektphase und Überlappungen
- Teamgröße
- Umgangskultur der Vertragspartner
Fazit
Wenn man auf einer abstrakten Ebene die Tätigkeiten, Anforderungen und Abläufe bei der Entwicklung von Softwaresystemen mit denen der Entwicklungsarbeiten im Anlagenbau vergleicht, so sind Ähnlichkeiten in der Komplexität erkennbar, jedoch auch Unterschiede. Hierbei fällt insbesondere auch der notwendige langfristige Vorausplanung bestimmter Arbeitssequenzen in der Realisierung ins Gewicht, die im Bereich der Softwareentwicklung die absolute Ausnahme sind. Auf der anderen Seite sind die sehr alten Paradigmen und Methoden in weiten Teilen dieser Branche zu sehen, die schnelle Veränderungen schwierig machen. Ein Umschalten in einen Anlagenbau „AgilePlantEngineering 4.0“ wird es also kurzfristig aufgrund der vorhandenen Strukturen und der etablierten Methoden nicht geben. Hybride Ansätze, in denen die klassischen Methoden durch agile Ideen ergänzt oder zum Teil ersetzt werden, sind aber durchaus hilfreich und können die bestehenden Abläufe an vielen Stellen entkrusten. Unternehmen, die diesen Weg gehen, sparen Ressourcen und werden flexibler. Beides sind Wettbewerbsvorteile.
Ich teile den Ansatz, agile Methoden nutzbar zu machen. Die Schilderung der Situation zum klassischen Ansatz teile ich nicht.
Auch hier geht es um Flexibilisierung und das Eingehen auf Veränderung bzw. den Erkenntnisgewinn während des Projektverlaufes. Nicht ohne Grund spricht man in der Abwicklung von unterschiedlichen Phasen, die auf Grund unterschiedlicher Gegebenheiten auch unterschiedliche Managementmethoden und unterschiedliche Führung benötigen. Eine Feasibility -Study oder das Basic-Engineering ist eben keine Fertigung oder Montage und bedarf einer anderen Organisation und Vorgehensweise. Das ist auch klassisch so!
Auch ist Vertrags- und Claims-Management zumindest international nicht gleichzusetzen mit Streitkultur und wird auch, wo es funktioniert, nicht so gelebt.
Die Sache erscheint mir also nicht so einfach zu sein und ein paar Kreativ-Workshops und Stand-up Meetings sind sicher nicht die Lösung. Ein agiler Mind-Set bedeutet, den Fokus auf die Fähigkeit zur permanenten Veränderung und Anpassung durch Selbstorganisation zu setzen. Deshalb stellt auch eine Dokumentation, die schnell überholt ist, keinen Mehrwert dar. Dennoch gibt es in vielen Bereichen gesetzlichen Notwendigkeiten für eine umfängliche Dokumentation (z.B. im Pharmaanlagenbau). So gilt es nicht nur hier, tragfähige Kompromisse und Ideen zu entwickeln. In dieser Richtung verstehe ich auch Deinen Ansatz zum Agilen Manifest im Anlagenbau.
Die Verhältnisse sind m.E. klarer zu fassen und den Paradigmenwechsel mit seinen Folgen und Möglichkeiten klarer und eindeutiger zu beschreiben. Gerade hier freue ich mich auf den weiteren Austausch.
Volker Engelke
Ich stimme Dir zu. Ziel ist es, das Überkommene und Bewährte aus Vergangenheit zu ergänzen und zu überprüfen, nicht aber es auszumerzen oder zu ersetzen. Gerade bei großen Projekten ist Organisationsstruktur und Dokumentation wesentlich, um das Ziel nicht aus den Augen zu verlieren und das ganze Team (was durchaus sehr groß werden kann) in die gleiche Richtung zu leiten. Und natürlich auch um gesetzlichen Regelungen nachzukommen.
Aber das genau ist das Thema: In vielen Projekten erscheint das einmal spezifizierte und festgeschriebene Ziel unveränderlich wie von Gott mit Blitzen in Granit gemeißelt und auf zwei Steinen zur Erde gesandt.
Aber genau das passt heute nicht mehr (Wahrscheinlich hat auch nie gepasst, aber die Einflüsse von außen sind heute stärker und vor allem schneller).
Als Beispiel nehme ich Projekte in der Rüstung: Entwicklungen, die in 50ziger, oder 60ziger Jahren gestartet wurden, führten zu Systemen, die für die Strategie meist noch passten, die Realität war, als die Systeme dann verfügbar waren und in die Truppe eingeführt wurden.
Das ist heute nicht mehr so. Die Entwicklungszeiträume blieben in etwa gleich (oder wurden sogar länger), jedoch ändert sich die geostrategische Lage so schnell, dass heutige Rüstungsprogramme oft für Strategien spezifiziert werden, die zum Zeitpunkt der Fertigstellung der Systeme oft schon 2-mal überholt sind.
Heute wirkt sich der Einfluss scheinbarer Minderheiten oft sehr plötzlich stark aus. Greta Thunberg konnte in kürzester Zeit Millionen von Menschen mobilisieren, denen sich Politik und Wirtschaft nicht verschließen kann und konnte.
Ohne Lösungen zu haben verändert sich der Weg in die Zukunft sich also sehr schnell. Projekte mit 5, 10 oder mehr Jahren Laufzeit werden in einem politischen oder wirtschaftlichen Umfeld fertig, dass möglicherweise ganz anders aussieht, als jenes, das man erwartet hat.
An diesen Stellen ist insbesondere das Management von Projekten im Anlagenbau gefordert: Es muss akzeptieren, dass das Erfüllen eines Vertrages nicht mehr ausreichend ist für den Erfolg des Projektes, sondern dass der Umgang mit den Veränderungen im Zeitraum des Projektes Teil des Projektmanagements ist. Dazu ist aber eine neue Kultur im Miteinander der Vertragspartner erforderlich.
Das ist der Ansatz des agilen Manifestes.
Beste Grüsse
Eike