 Kleinere Anlageninvestitionen, mittelgroße Umbauprojekte bei Bestandsanlagen oder EPC - Großprojekte scheitern in projektorientierte Unternehmen - leider - erschreckend oft. Doch wie im Unternehmen mit dem "Untergang" der jeweiligen Projekt- "Titantic" umgehen? Post- mortem- ProjektanalyseJede Projektmanagementbibel kennt und beschreibt es - die post- mortem- Analyse: das Debriefing oder Lessons Learned nach der Projektumsetzung. Der positive und negative Erfahrungs- und Wissensschatz wird zusammengetragen, um für die Zukunft zu (ver)lernen. Bei erfolgreichen Projekten feiert man sich gegenseitig, bei Gescheiterten wird versucht alles bloß schnell zu vergessen, ggf. noch ein Schuldiger ausfindig zu machen und dann wieder sich dem daily project- business zu widmen. Doch ist ein Debriefing nach dem Projekt(miss)erfolg wirklich sinnvoll? Können oder wollen wir uns nach einem 1-jährigen Projektmartyrium an die Fehler, Missverständnisse, eingetretenen Risiken, Handlungsschwächen, uvm. wirklich erinnern? Liegt es überhaupt am Projektvorhaben selbst oder sind es die Projektmethoden und -prozesse, welche zum "Projekt-Herzinfarkt" geführt haben? Kennen wir überhaupt die Projekt- Todesursache? Oder ist es ein Multiorganversagen des gesamten Projektmanagement- Organismus? Würde man das tote Projekt am Operationstisch obduzieren und mit viel Aufwand die Todesursache klären - hätten wir wirklich soviel gewonnen? Oder ist der Zeitpunkt für eine Autopsie nach dem Projekt nicht doch schon falsch gewählt? Folgende Annahme und Fragstellung: Analysieren wir ein gescheiteres Projekt nach einem Jahr, haben wir vielleicht die genaue Projekt- Todesursache nach einem Jahr gefunden. Die Learnings fließen somit (mehr oder weniger) nach einem Jahr in das Unternehmen retour - und verbessern es (hoffentlich) für zukünftige Projektvorhaben. Frage: Wie viele Projekte mit z.B. den selben Projektstrukturen, den selben Abwicklungsprozessen, ähnlichen Projektbeteiligten, usw. werden parallel innerhalb eines Jahres im Unternehmen abgewickelt? Bei wie vielen Projekten könnten ähnliche Fehler, als wie beim gescheiterten Projekt, eintreten? Prä- mortem Projektanalyse Hier setzt die prä- mortem- Projektanalyse an: Vor Projektbeginn oder während der Umsetzungsphase führen Projektteams - mit Unterstützung einer externen Beratung - eine Projekt- "Autopsie" durch. Ziel liegt in der Statusaufnahme des Projekt-"Patienten":
Beim Worst- Case-Szenario stellen sich die Teammitglieder bspw. die Überschrift eines Zeitungsartikels vor, die vom grandiosen Scheitern des Projektes berichtet. Auf Basis dieser fiktiven Annahme werden mögliche Ansätze für das Herzversagen des Projektes untersucht. hört sich theoretisch und fiktiv an. Jedoch hat schon vor 30 Jahren eine Studie der Cornell University folgendes gezeigt: Stellen sich Menschen ein reales zukünftiges "Worst-Case-"Ereignis vor, erhöht sich die Fähigkeit, Ursachen für dieses fiktive Szenario herauszufinden, um 30%. Dies führt unausweichlich zum Gedankengang " Wie hätte es nur bloß soweit kommen können?". Je gründlicher die prä-mortem- Projektanalyse ausfällt, desto besser beugt sie dem Tod des Projekt(managements) im Unternehmen vor - und die post- mortem- Projektanalyse ist weniger schmerzhaft. Autor: Dr. David Kronawettleitner
Wenn Projektteams, Projektleiter oder PMO-Leiter vom Projektcontrolling sprechen, rückt leider zu oft das Wort " Kontrolle" in den Vordergrund. Viele Projektbeteiligte gehen dann in der Annahme, dass es sich hier rein um die Kontrolle der Aufgaben oder Arbeitsergebnisse dreht. Wem wird denn auch schon gerne auf die Finger geschaut? Denken Sie rein an Polizeikontrollen oder an die Zollabfertigung am Flughafen. Projektcontrolling hat zu unrecht ein negatives Image - und ein russischer Revolutionär hatte hierbei einen wesentlichen Anteil daran. Vor einiger Zeit bin ich wieder auf einen schweizer Artikel mit nachfolgendem Titel gestoßen: Was haben Projektcontroller und Lenin gemeinsam?
Im ersten Moment würde man sagen, dass in dem Leitsatz genügend Wahrheit steckt - da man Menschen kontrollieren sollte, um wirklich sicher zu sein, dass die geforderten Arbeiten in dem vorgegebenen Zeitrahmen ausgeführt werden. Manche Projektcontroller und Projektleiter haben diese Aussage zur innersten Doktrin für sich gemacht - und Kontrollieren auf "Teufel- komm- raus". Empowerment als Projekt-Leitbild Aber muss man denn wirklich in Echtzeit die Aufgaben und (Teil-)Ergebnisse der Projektmitarbeiter kontrollieren, um sicher zu gehen, dass das Projekt nicht in Schieflage gerät? Würde man ein Projekt wie eine autokratische Diktatur führen, macht ein Projekt-"Polizeistaat" sicherlich Sinn. Doch diese Verhaltensweise trifft nur mehr bedingt in projektorientierten Unternehmen zu. Der englische Begriff "Empowerment" (dt. Selbstverantwortung und Selbstbestimmung) und der Ansatz der Eigenkontrolle von Mitarbeitern schreitet in langsamen Schritten in den Projekten voran. Vertrauen durch Kontrolle? Aber wie steht es nun mit dem Kontrollieren in den Projekten? Schwebt im Hinterkopf noch der Leitsatz "Vertrauen ist gut, Kontrolle ist besser"? Nehmen wir eine Situation her: Ihr 5-jähriger Sohn möchte mit seinen Freunden nach draußen um Fussball zu spielen. Als Elternteil, bitten Sie Ihren Sohn jedoch vorher sein Zimmer noch aufzuräumen. Nachdem Ihr Sohn alles weggeräumt hat, kontrollieren Sie dies natürlich - ob alles am richtigen Ort verstaut wurde. Danach bekommt er das GO. Wenn es immer wieder der Fall ist, dass Ihr Sohn mit den Freunden Fussballspielen möchte und vorher aber alles wegräumen muss - Kontrollieren Sie das Ergebnis wirklich immer? Wahrscheinlich wird von Ihnen irgendwann die Frage kommen, ob er schon alles weggeräumt hat, bevor er raus geht. Wenn die Antwort Ja wäre, darf er auch spielen gehen - Ohne dass Sie das Ergebnis kontrollieren. Wieso? - Weil Sie nach der Zeit ein Vertrauen in die Aussage Ihres Sohnes haben. Kontrolle schafft Vertrauen Umgelegt auf die Projektwelt merken Projektbeteiligte, wenn Ihr Projektleiter Ihnen vertraut oder doch lieber kontrolliert, um sicher zu sein, dass alles OK ist. Herrscht eine Vertrauensbasis in Projektteams, nehmen Projektmitarbeiter die Überprüfung von Arbeitsergebnissen nur mehr bedingt als Kontrolle wahr. Kontrolle in angemessener Form ist ein einfaches und wirksames mit Mittel, um den Projektstatus zu einem Zeitpunkt zu erfassen. Das Projektcontrolling - oder besser "die Überwachung des Projektstatus" - dient als Dialog zwischen Projekleiter und Projektmitglied, um Problemen, Abweichungen und Schwierigkeiten zu erkennen. Kontrolle ohne Vertrauen = Projekt-"Polizeistaat" Ohne einem Vertrauen, besteht die "Angst" der Projektbeteiligten vor den potentiellen Konsequenzen bei Projektabweichungen. Offenheit, Vertrauen und die Bereitschaft von individueller Lösungsfindung führt zu einem modernen Controlling-Ansatz. Müsste man die Projektbeteiligten immer kontrollieren, wäre dies der erste Vertrauensbruch. Durch das Empowerment der Projektbeteiligten ist eine Flexibilität in der Erreichung der individuellen Arbeitsergebnisse unumgänglich. Vertrauen ohne Kontrolle = Blindes Vertrauen Jegliche Kontrolle ohne einer Vertrauensbasis ist jedoch sinnlos. Ein Mitarbeiter wird nur volle Leistung und Engagement bringen, wenn er das Vertrauen des Projektleiters "genießt" und immer die Möglichkeit von Unterstützung besteht. Aber wie würde man dann das Projekcontrolling anlegen- ohne dass es als Kontrolle angesehen wird? Management by Wanderung- Around Die sinnvollste Echtzeit-Überwachungsmethode im Projektcontrolling ist die "Stichprobenkontrolle". In einem vordefinierten Controllingintervall (z.B. 1x monatlich) erfolgt ein offizielles Projekt-Reporting mittels standardisierten Project Progress Reports. Zwischen den Controllinintervallen ist stichprobenartige Überwachung (mittels einem Management by Wanderung Around-Ansatz) seitens des Projektleiters angesagt. Selbstständigkeit und das Empowerment der Projektbeteiligten muss hierbei unangetastet bleiben um modernes Projektcontrolling zu ermöglichen. Autor: Dr. David Kronawettleitner
Bereits seit einigen Jahren ist der Begriff "Agilität" in Unternehmen in aller Munde. Eine Horde von Unternehmensberatern, Consultants und selbsterkorenen Besserwissern sind auf dem Zug der agilen Unternehmens-"Bekehrung" aufgesprungen und predigen, dass agiles Projektmanagement DAS Allheilmittel für Projekte sein soll. Agile Bekehrung als reine Berater- "Panikmache" Eine Vielzahl von Consultants werfen mit Begriffen, Konzepten und "selbst-"bewährten Methoden rund um das agile (Projekt-)Management um sich. Im guten Glauben an diese Consultants vertrauen Unternehmen dem Rat und den Meinungen dieser "Spezialisten" und krämpeln Ihr Projektmanagement dementsprechend um. Aber haben die Unternehmer die Standpunkte und Philosophien hinsichtlich agilem (Projekt-)Management hinterfragt? Geht wirklich gar nichts mehr, wenn man agile Grundsätze nicht beachtet? Oder ist das doch einfach nur ein gängiges Berater- Bla-Bla, garniert mit einem Zuckerguss Blödsinn? Nach meiner Einschätzung trifft Berater-"Bullshit" eher dafür zu - aber wieso?  Als verkaufsfördernde Wirkung bringen agile Prediger folgende Argumente zum agile Projektmanagement ins Feld:
Alles was von den Beratern als NEU, MODERN, RADIKAL und EXTREM angepriesen wird, verkauft sich natürlich auch besser als (Alt-)Bewährtes. Konservative Branchen, wie der Maschinen- & Industrianlagenbau sowie die Bauindustrie lassen sich schon etwas von dem agilen Allheilmittel verzaubern - gerade auch wenn Consultants erzählen, dass man auf den agilen Zug jetzt aufspringen muss, andernfalls kann man heutzutage keine Großprojekte mehr abwickeln und der Wettbewerb ergattert die zukünftigen Aufträge. "Agilität" lässt die Kassen klingeln - da die konservativen Unternehmen im guten Glauben sind, neue und moderne Grundsätze bringen eine schnellere Projektabwicklung, weniger Projektaufwand, effizienteres Handeln und somit mehr Deckungsbeitrag. Die Kombination von klassichen Projektmanagement-Methoden wird von diesen Consultants als Wirr-Warr und gar Teufelswerk angesehen - es gilt nur das "Entweder-Oder-Prinzip". Aber woher kommt das agile Management eigentlich? Die Idee des agilen Projektmanagement entstand aus der IT-Branche mit den vielfach katastrophalen IT-Projekten, welche neu Methoden suchten, um Projekte endlich erfolgreich abzuwickeln (z.B. siehe Chaos-Report der Standish Group von 30.000 untersuchten IT-Projekten; Ergebnis: Durchschnittliche Terminüberschreitung: 222%; Durchschnittliche Kostenüberschreitung: 189 % bei IT-Projekten). Das die IT-Branche neue Wege benötigte, um Projekte erfolgreich abzuhandeln liegt wohl auf der Hand. Die bekanntesten agilen Methoden wie SCRUM und Kanban entstanden und wurden/werden in der IT eingesetzte und als bewährtes "Medikament" verkauft. Doch die SCRUM- und Kanban-Anwender haben heute erkannt, dass eine Kombination von klassischen und agilem Projektmanagement zielführend ist - abhängig vom Projekt, der Situation, den Mitarbeitern, dem Markt und dem Unternehmen. Agilität vs. Dynamik Das Projektgeschäft verändert sich - keine Fragen. Es wird schneller durch die kürzeren Gesamtlaufzeiten, komplexer infolge der auftraggeberseitig gewünschten Rund-um-Sorglos-Pakete (GU-Projekte) und monetär enger, aufgrund der geringeren Deckungsbeiträge. Aber bring agiles Management wirklich eine Verbesserung? Gehen wir in den Grundsatz was "Agilität" für Projektbeteiligte bedeutet. Agilität ist die Fähigkeit...
Im Kern zielt agiles Projektmanagement auf dem Umgang mit Änderungen, mit einem geringen bürokratischen Aufwand und wenigen Regeln ab. Aber machen dies Projektleiter denn nicht ohnehin schon (ohne agile Methoden)? Projektleiter von (Groß-)Projekten und speziell im Generalunternehmerbereich wissen nur zu gut, dass Änderungen im Projektgeschehen einen normalen Sachverhalt darstellen. Aufgrund der Vielzahl an Fremdgewerken, Sublieferanten und Schnittstellen ist das Handling von Änderungen (bspw. aufgrund konstruktiver Erfordernissen, statischen Berechnungen, bautechnischen Gegebenheiten, etc.) als Generalunternehmer ein "Daily-Business". Diese Änderungen können in Realisierungsprojekte aber nur bis zu einem gewissen Grad und Projektstadium (aufgrund Umsetzbarkeit, vertraglichen Pflichten und pönalisierten Terminen) umgesetzt werden. Die Projektleiter kennen die Dynamik der Projektänderungen und wissen auch damit gekonnt umzugeben. Ist also der Umgang mit dieser Projektdynamik also automatisch "agil"? Agil vs. Project Change Management Im klassichen Projektmanagement gibt es das Änderungsmanagement (Change Request oder Project Change Management) wo mit Änderungswünschen in einem geordneten Weg umgegangen wird. Unternehmen der konservativen Branchen sind aufgrund der Regularien, Unternehmensstrukturen "gezwungen" klassisches Projektmanagement einzusetzen. Funktioniert dieses klassiche Projektmanagement - kann auch das Änderungsmanagement sauber funktionieren - und da benötigt man die Methoden des agilen Projektmanagements nur bedingt bis gar nicht. Natürlich kann man das klassiche Projektmanagement um diese agilen Methoden ergänzen, aber notwendig ist es nicht - auch wenn Ihnen die Beraterbranche dies weiß machen will. Agiles Projektmanagement macht Projekte zwangsläufig nich schneller oder besser. Wenn auf Änderungen in Bau- & Industrieanlagenprojekten nur bedingt eingegangen wird, werden die Methoden des agilen Projektmanagements eine bedingte oder keine Besserung bringen. Klassisches Projektmanagement bietet das Fundament für eine strukturierte prozessuale Abwicklung von Projekten. Ein sauberes Project Change Management ist ein probates Mittel, um mit der Dynamik im Projektgeschehen umgehen zu können. Somit lassen Sie sich nicht von der agilen Bekehrung blenden. Es ist KEIN Allheilmittel, sondern wird von so manchen Dienstleistern als das Must-Have verkauft - und fällt dann unter die Kategorie "Berater-Bullshit". Autor: Dr. David Kronawettleitner
Wie auch heutige Projektleiter stand vor fast 240 Jahren der preußische General Carl von Clausewitz vor denselben Herausforderungen. Beide beschäftigten sich mit komplexen Systemen sowie der Dynamik von Plänen. Plan vs. Realität Komplexität und Unsicherheiten in industriellen Großprojekten sind keine neuzeitlichen Phänomene des digitalen Zeitalters. Der Begriff der "Friktion" spielt hierbei eine zentrale Rolle. General Carl von Clausewitz verglich (1832) das physikalische Prinzip der Reibung (Friktion) mit der Kriegsführung. Hierbei verstand er die Friktion als jene Schwierigkeit, welche das Geplante von dem Realen unterscheidet und dies das Ergebnis wesentlich beeinflusst. Von Clausewitz betrachtete die Soldaten als Individuen, welche Ihrer eigenen Friktion unterliegen. Durch die Dauer des komplexen Vorhabens (Kriegshandlungen), wächst die Friktion, infolge der nicht vorhersehbaren Ereignisse. Diese Friktion wirkt somit wesentlich auf den ursprünglichen Schlachtplan ein. Accept changes  Sind Parallelen zum modernen Projektmanagement erkennbar? Ja, eindeutig. Realisierte Projekte unterscheiden sich immer wieder wie Sie ursprünglich am Papier geplant wurden. Gründe sind die zahlreichen mehr oder weniger beeinflussbaren Faktoren, welche im Zuge der Projektumsetzung auftreten. Ob fehlerhafte Komponentenauslegungen, Lieferverzögerungen während der Beschaffungsphase oder der Kunkurs von Sublieferanten führt zu unvorhersehbaren Projekt-"Zufällen". Doch was nun tun? Für von Clausewitz war klar, dass Abweichungen und Unwägbarkeiten während einer Schlacht zu akzeptieren sind und diese zum Vorteil für sich zu nutzen sind. Im agilen Manifest von SCRUM lautet das 4. Prinzip auch "Reagieren auf Veränderungen ist wichtiger als Befolgung eines Plans". Reagieren Sie agil Aber wer würde schon auf eine Änderung nicht Reagieren? Jeder (gute) Projektleiter weiß, dass Abweichungen zu Projekteinwirkung führen und somit eine Folgewirkung auf Kosten, Termin oder die Qualität des Liefer- & Leistungsumfangs hat. Jedoch gibt es in so manchen Projekten "statische Projektpläne" - wo man auf die ursprünglich erstellten Kosten- oder Terminpläne beharrt. Planungen sind speziell bei GU-Projekten mit der Vielzahl an Schnittstellenthemen immens wichtig - keine Frage. Doch muss auf veränderte Projektbedingungen die Notwendigkeit von Anpassungen folgen. Projektleiter sind gefordert auf diese Dynamik im Projektgeschehen flexibel zu (re)agieren. Ein Terminplan ist kein Papier, dass einmal erstellt und dann an die Bürowand geklebt wird - sondern ein Plan, bei welchem sukzessive Anpassungen erforderlich sind. Agiles Handeln als Normalzustand Das flexible und dynamische Handeln in sich verändernden Umständen ist heute genauso wichtig, wo sie zu Zeiten von General von Clausewitz waren. Infolge der immer komplexer werdenden Großprojekte, des stetig steigenden Zeit- und Kostendrucks ist davon auszugehen, das Agilität im Projektgeschehen für zukünftige Projektleiter unerlässlich ist. Da stellt sich dann natürlich die Frage, wieso denn Projekte noch planorientiert und nicht vollkommen agil (mittels SCRUM) realisiert werden. Die Frage kann klar beantwortet werden: "Weil vollkommen agiles Handeln in manchen Vorhaben einfach nicht funktioniert". Stellen Sie sich vor der General von Clausewitz wäre mit seinen Truppen einfach vor ein Schlachtfeld getreten und hätte dann Schachzug für Schachzug umgesetzt - ohne jedoch einen gesamtheitlichen Plan und Zielvorstellung zu haben. Hybrides Handeln = Das Beste aus 2 Welten Hybrides Handeln in komplexen Vorhaben ist das Zauberwort. Kombinieren Sie flexibel und situationsbezogen die klassischen Projektmethoden mit den neuen agilen Ansätzen (SCRUM, Kanban). Kombinieren Sie beide Welten in den Rahmenbedingungen, welche vorgegeben sind. Am Schlachtfeld als auch im Projekt sind durchdachte Pläne und dynamisches Handeln gefragt, um ambitionierte Ziele zu erreichen. Autor: Dr. David Kronawttlitner
 Modetrends gibts es viele - sie kommen und gehen. Viele veraltete Trends - werden nach Jahren wieder aus der Kiste herausgeholt und zu DEM neuen Trend und zum Must-Have auserkoren. Doch sollte man wirklich auch jeden Blödsinn in der Mode mitmachen? Aktuell sind helle oder weiße Sportschuhe - zumeist mit gewebten Muster - für den "Casual -Freizeit Look" ein Muss, speziell für den angesagten Trendsetter. Man muss es einfach tragen, um on vogue zu sein. Die "weißen Sportschuhe" in projektorientierten Unternehmen heißen gerade "agil". Agilität ist angesagt. Überall hört man, was nicht andere Unternehmen alles agil machen. Kein Wunder - ist ja auch zu verlockend, was da (von so manchen Beratungsunternehmen) versprochen wird: Alles wird um vieles schneller, weniger Bürokratie, weniger Papierkram, keine störenden Prozesse und man kann so viel in der Projektrealisierung an Zeit einsparen - wobei man ändern kann was und wie man will. Nein, man soll sogar ändern und den Kunden in der Realisierung einbinden, dass er sich wünschen und ändern kann was er will - zu jedem Zeitpunkt. Wir sind ja so agil und flexibel und können auf alle Wünsche zu jederzeit eingehen - ist ja kein Problem. Überspitzt trichten uns Alle ein: "Nimm eine Prise Agilität2236 und alles in deinen Projekten wird gut." Die Arbeitsweise ist nun auf einm Backlog, Story und Velocity. Und wir machen kein Meeting mehr, sondern haben ein Daily. Jeder schwimmt schon auf der Welle des agilen Modetrends und versucht sich seine "weißen Sportschuhe" möglichst schnell anzuziehen, um vor den anderen Unternehmen anzugeben. Leider zeigt die Realität, dass viele der agilen Gehversuche bedingt oder nicht gut funktionieren. Man könnte sagen, dass die neuen weißen Sportschuhe quasi nicht passen. Als Grund kann man überspitzt zwei Grundrichtungen ausmachen: Die Chaoten Diese Gruppen verwechseln "agil" mit "chaotisch" und erteilen jeder Art von aufgebauter Ordnung und Struktur eine Absage. Alles wird irgendwie angefangen, aber nichts mehr wird fertig bzw. abgeschlossen. Jede noch so dumme Idee bekommt auf einmal eine Chance - schließlich sind ja altbewährte Business Pläne nur mehr old school. Am Ende steht die Erkenntnis, dass agil nicht funktioniert, weil alles im Chaos versinkt. Den Chaoten sei gesagt: Agiles Arbeiten hat Regeln. Jede Freiheit hat ebenfalls Regeln. Wenn man in einem Tierpark die einzelnen Käfige aufgibt und einen großen und offenen Tierpark baut, sind da noch immer Mauern - welche die Tiere drinnen hält. Die Mauern stehen halt woanders. Der Controlletis Sieht aus wie agil, riecht wie agil - ist aber nicht agil. Die Controlletis trauen dem neuen Allheilmittel und Frieden nicht und wollen agil die Stunden messen und kontrollieren. Standardfrage: "Wie agil waren wir heute unterwegs?" "Können sie eine Übersicht aller geplanten und detailliert beschriebenen User Stories der nächsten 6 Monate, mit geplanten Ressourcen aller Sprints, für das nächste Managementmeeting bereit stellen?" Am Ende steht die Erkenntnis, dass agil nicht funktioniert, weil sich ja gar nichts geändert hat. Den Controlletis sei gesagt: Halbherzig ist schlecht, habt vertrauen in euer Projektteam. Genaue Planung ist ein Märchen, egal ob agil oder nicht. Agiles Arbeiten für beschränkte Projekte und Projekphasen kann funktionieren. Es gilt aber die "agile Essenz" zu erkennen, und nicht einfach einen Oldtimer zu einen Sportwagen umzurüsten. Agil ist eine Reise. Wenn es nicht gleich funktioniert, ist Anpassung erwünscht und erforderlich - auch wenn agiles Arbeiten nicht gleich funktioniert. Es ist ein Teil PDCA-Prinzips und übrigens so alt wie völlig aus der Mode gekommenen Cowboy-Stiefel. Nur weil "alle" Anderen weiße Sportschuhe im Büro tragen, ist es nicht unbedingt sinnvoll, dass man mit zu kleinen weißen Schuhe Fussball spielt. Danach wird man keine modischen Trendschuhe haben - sondern mit den bewährten Fussballschuhe tribbeln. Autor: Dr. David Kronawettleitner
Alle Risiken sind schlecht, da Sie Gefahren darstellen. In der deutschen Sprache wird der Begriff "Risiko" mit einem negativen Ereignis verbunden. Im angloamerikanischen Raum assoziert man "threat" bzw. "risk" jedoch mit einer Bedrohung, als auch mit einer Chance. Warum? Wenn potentielle Risiken nicht eintreten werden in Unternehmen Kosten gespart. Denken wir nur an den Generalunternehmer-Zuschlag. Dieser Zuschlag deckt zum Teil das Schnittstellenrisikozwischen Generalunternehmer und Sublieferanten ab. Wenn es jedoch keine Schnittstellenthemen gibt - dann stellt der Zuschlagssatz einen Gewinn dar - somit eine Chance. Risikomanagement ist reine Zeitverschwendung. Der Aufwand um über potentielle Projektrisiken nachzudenken, diese zu analysieren, (Gegen-)Maßnahmen zu definieren und danach umzusetzen - kostet Zeit und Geld. Wenn man jedoch den Kopf in den Sand steckt und lieber auf den Zug wartet, von welchen man womöglich mit Volldampf überrollt wird, kostet dies deutlich mehr Geld. Wesentlicher Grundsatz: Pragmatische Ansätze in Relation zum Nutzen - Keine philosophischen Abhandlungen. Nur nicht über die Risiken nachdenken. Wenn Risiken nicht erkannt wurden, können diese nicht präventiv beeinflusst werden. Die Kosten für die Behebung von Fehlern steigt mit zunehmender Realisierungszeit potentiell an. Fehlerhafte Berechnungen in der Planungsphase könnten mit einigen Arbeitsstunden korrigiert werden. Würde man jedoch nichts tun (da man vom Risiko ja nichts weiß) und während der Montage den Fehler erkennt - kostet die Behebung um ein Vielfaches mehr. Wir brauchen uns nicht um Risiken kümmern Jede im Projekt involvierte Person sollte/muss über potentielle Risiken in seinem Aufgabenbereich nachdenken. Somit wäre jeder im Projekt ein Art "Risikomanager". Ein offizieller Risikomanager dient als Zweigstelle, Informationsdrehscheibe und Moderator, um das Handling von allen Risiken in geführte Prozedere zu koordinieren. Alle Risiken müssen vermieden werden Ein Irrglaube, dass man jedes Risiko verhindern kann. Manche Risiken sind einfach nicht beeinflussbar oder aber viel zu teuer im Vergleich zum Nutzen. Daher stellt der sinnhafte Umgang mit Risiken (Risiken übertragen, minimieren oder akzeptieren) einen wichtigen Bestandteil des Risikomanagements dar. In unserem Projekt gibt es kein Risiko. Risiken sind Bestandteil von Projekten. Wenn Sie glauben, dass es kein Risiko in Ihrem Projekt gibt - dann wissen Sie es einfach noch nicht. Auch wenn Unternehmen von den berühmten "Standard"-Projekten sprechen, treten gerade bei diesen Vorhaben unbekannte Risiken ein (welche in den vorherigen Standard-Projekten nicht eingetreten sind). Risikomanagement benötigt Zahlen Quantitative Risikoanalysen sind mächtig und werden bei größeren Anlagenbauunternehmen und speziell im angloamerikanischen Raum gefordert. Jedoch lassen sich manche Risiken nicht mit Zahlen quantifizieren. Der Fokus besteht primär in der Identifikation von Risiken und in der Ableitung von Maßnahmen - nicht in der genauen zahlenmäßigen Einschätzung von Risiken. Besser mehr Zeit in die Identifikation stecken und nur eine rein qualitative Risikoanalyse durchführen als mit vielen großen Zahlen jonglieren. Risikovorsorgen oder Reserven für Unvorhergesehenes brauchen wir nicht. Ein Budget für Risikoreserven einzuplanen zeugt von Weitblick. Die Projekleiter werden ohnehin mit unvorhergesehenen Situationen konfrontiert, wo Geld benötigt wird. Nur weil in offiziellen Vertriebskalkulationen kein Risikopot ausgewiesen ist heißt nicht, dass es ihn nicht versteckt gibt. Risikomanagement funktioniert nicht, da identifizierte Risiken nie eintraten - auch ohne Gegenmaßnahmen. Risiken treten auch nicht ein, weil Projektbeteiligte sich im Vorhinein damit schon beschäftigt haben und im Unterbewusstsein dies verhindern - auch ohne Gegenmaßnahmen. Dies trägt automatisch zur Verhinderung bei. Author: Dr. David Kronawettleitner
|
RSS-Feed
|
Über uns
Als Beratungsagentur unterstützt inergy consulting Unternehmen in der produzierenden Industrie, sowie im Maschinen- & Anlagenbau beim effektiven Aufbau & Professionalisierung von Geschäfts- & Projektprozessen.
|
Schwerpunkte
|
Leistungen
|
Get Social
inergy consulting e.U. Schalbachstraße 31a
4632 Pichl bei Wels (AT) +43 (0)681 20 30 9883 [email protected] |