BrennerCongress 2014 Durchgängiges Kosten- und Risikomanagement bei Großprojekten im Infrastrukturbereich Innsbruck, 20.02.2014

Grundlagen Kostenstruktur & Kostencontrolling Risiko-Analyse Projekt-Review Zusammenfassung

Grundlagen

Für was steht durchgängiges Kosten- und Risikomanagement? Vergleichbarkeit der Daten von der ersten Kostenermittlung über das operative Projektkostencontrolling bis zu einem abschließenden Projektreview.  Sicherstellen von Vergleichbarkeit und Verfügbarkeit der Daten Berücksichtigung und Darstellung von Unsicherheiten  Zielführende und durchdachte Methoden einsetzen, um somit den Informationsgehalt der Prognosen für Kosten und Risiken zu erhöhen. Großprojekte haben einen starken individuellen Charakter  Anpassung des Kostenmanagementsystems die Gegebenheiten bzw. Voraussetzungen des Projekts.  Ganzheitliches Denken gefordert. Eingesetzte Software wird an das Projekt angepasst und nicht das Projekt an die Limitierungen der Software.  Gewährleistung der obigen Punkte

Unsicherheiten – Unterscheidung zwischen Basiselementen und Risiken Unsicherheit Prognose Basiselemente (Kosten, Zeit, etc.) Risiko Treten immer auf (zB Elemente in einer Kostenschätzung) Der exakte Preis bzw. die exakte Zeit ist unsicher Der Eintritt ist möglich Die Auswirkungen (Kosten, Zeit, etc.) sind unsicher Definition Risiko in der ISO 31000:2010 und ONR 49000:2010

Unsicherheiten bei einer 14-Tage Wetter Vorhersage Beispiel Temperaturen Vorhersage (ARD): Zunehmende Abweichung Beispiel Risiko: keine Bauarbeiten unter 2°C möglich Zusätzliche Eintrittswahrscheinlich-keit

Kostenstruktur & Kostencontrolling

Kostenbestandteile nach ÖGG Richtlinie Kostenermittlung Planungsphase Gesamtkosten (BGRV) Vorausvalorisierung (V) Prognostizierte Teuerung über die Projektlaufzeit Risiken (R) Reserven zur Deckung sich realisierender Risiken Basiskosten (B) Projektkosten ohne Risiken zu einer festen Preisbasis

Beispiel Kostenbestandteile in der Kostenermittlung

Ausführung: Nachtragsmanagement in RM integrieren – dynamische Darstellung

Kostencontrollingstruktur und EDV-Umsetzung am Beispiel des AdVLR Basiskosten (B) Nicht vergebene Leistungen Bestellungen Zusätzliche Kosten Erw. Mehr- oder Minderkosten Mehrkosten-anmeldungen Mehrkosten-forderungen Mengenab-weichungen Zusatzaufträge Hauptaufträge

Beispiel Wasserkraftwerk – Übersicht über die Kostenbestandteile der Kostenstruktur Zuweisung der Kostenbestandteile durch „Labels“ Komplette Controlling-Informationen auf jeder Ebene abgebildet

Mittelabfluss und Visualisierung

Risiko-Analyse

Risikomanagement-Prozess - Überblick Establish / Ablauf aktualisieren Risiko Management Prozess Überwachung Risikoidentifikation Risiko Analyse Bewertung Auswertung Behandlung Methoden Methods Risk Fact Sheet Vorklassifikation Qualitative Analyse Qualitative Analysis Quantitative Analyse

Qualitative Bewertungssysteme – Beispiele und Problemstellung hoch mittel gering häufig möglich selten sehr selten unwahr-scheinlich unbedeu-tend gering spürbar kritisch bestands-gefährdend Eintrittswahrscheinlichkeit Auswirkung „Copy & Paste“ Matrizen – gelten als Standard, daher wird der Nutzen selten hinterfragt. Matrizen mit ungerader Anzahl von Feldern (3x3, 5x5) verleiten den Anwender bei wenig Informationen zum Risiko die Mitte zu wählen. Vorgegebene Farben bestimmen pauschal ob Aktion notwendig, oder nicht. Beschriftung der Kategorien (Felder) oft für den Anwender nicht klar abgrenzbar – wird dann nicht genutzt.

Trugschlüsse durch Quantifizierungsversuche von qualitativen Bewertungssystemen häufig möglich selten sehr unwahr-scheinlich unbedeu-tend gering spürbar kritisch bestands-gefährdend Gleichsetzen von komplett unterschiedlichen Ereignissen Vermischung der unabhängigen Größen Eintrittswahrscheinlichkeit und Auswirkung Addition der Ergebnisse wird als Entscheidungsgrundlage herangezogen 5 5 Reifenpanne 4 3 2 Variante 1: 9 + 5 + 6 + 5 + 4 + 6 + 8 + 4 = 47 5 1 TBM Brand Variante 2: 20 + 10 + 15 = 45 1 2 3 4 5 Beispiel monetäre Bewertung: Reifenpanne Muldenfahrzeuge: 80% x 10.000 € = 8.000 € TBM Brand: (1/500) x 4.000.000 € = 8.000 € AKW Unfall: (1/10.000.000) x 80.000.000.000 € = 8.000 €

Verwendung von einfachen aber exakten Bewertungssystemen - Preliminary Hazard Analysis (PHA) Die Preliminary Hazard Analysis (PHA) ist eine anerkannte Methode (s. auch IEC/ISO 31010), die sich besonders gut zur Präklassifikation von Risiken in frühen Phasen eignet. Ziel ist es die relevanten Risiken und die weniger relevanten Risiken zu identifizieren. Auf Basis der Ergebnisse können dann gezielt Ressourcen und weiterführende Analysemethoden auf die wichtigsten Risiken angewandt werden.

Beispiel für eine Einzelrisikobewertung in einer probabilistischen Risiko-Analyse Risiko-Beschreibung, Eintrittswahrscheinlichkeit und Basisinformationen Ergebnis als Verteilungsfunktion zeigt Unsicherheiten Best- bis Worst-Case Evaluierung der Auswirkungen mittels 3-Punkt-Schätzung

Projektreview

Ziele des Projektreviews Durch eine rückblickende Analyse mit Focus auf die Nachtragsursachen des Projektes, können folgende Ziele verfolgt werden: Welche Risiken sind eingetreten  welche Zusatzaufträge; In wie fern sind die Prognosen aus der Risiko-Analyse zutreffend gewesen. Untersuchung der Leistungsverzeichnisse. Erhebung, wie und in welchem Umfang Positionen zur Risikoabdeckung bereits über den Hauptauftrag beauftragt und abgerechnet wurden. Erfahrungen aus solchen Analysen helfen bei zukünftigen Projekten, den Focus früher auf die wesentlichen Themen zu lenken.

Projektreview Beispiel Baulos H5 Unterinntaltrasse

Zusammenfassung Vergleichbarkeit der Daten von der ersten Kostenermittlung über das operative Projektkostencontrolling bis zu einem abschließenden Projektreview.  Sicherstellen von Vergleichbarkeit und Verfügbarkeit der Daten Berücksichtigung und Darstellung von Unsicherheiten  Zielführende und durchdachte Methoden einsetzen, um somit den Informationsgehalt der Prognosen für Kosten und Risiken zu erhöhen. Großprojekte haben einen starken individuellen Charakter  Anpassung des Kostenmanagementsystems die Gegebenheiten bzw. Voraussetzungen des Projekts.  Ganzheitliches Denken gefordert. Eingesetzte Software wird an das Projekt angepasst und nicht das Projekt an die Limitierungen der Software.  Gewährleistung der obigen Punkte