Durchgängiges Kosten- und Risikomanagement bei Großprojekten im Infrastrukturbereich

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

2. Grundlagen • Kostenstruktur & Kostencontrolling • Risiko-Analyse • Projekt-Review • Zusammenfassung

3. Grundlagen

4. 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 Methodeneinsetzen, 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 Softwarewird an das Projekt angepasst und nicht das Projekt an die Limitierungen der Software. Gewährleistung der obigen Punkte

5. Unsicherheiten – Unterscheidung zwischen Basiselementen und Risiken 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:2010und ONR 49000:2010

6. Unsicherheitenbeieiner 14-Tage Wetter Vorhersage BeispielTemperaturenVorhersage (ARD): Zunehmende Abweichung Beispiel Risiko:keine Bauarbeitenunter 2°C möglich • Zusätzliche Eintrittswahrscheinlich-keit

7. Kostenstruktur & Kostencontrolling

8. 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

9. Beispiel Kostenbestandteile in der Kostenermittlung

10. Ausführung: Nachtragsmanagement in RM integrieren – dynamische Darstellung

11. 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

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

13. Mittelabfluss und Visualisierung

14. Risiko-Analyse

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

16. Qualitative Bewertungssysteme – Beispiele und Problemstellung 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.

17. Trugschlüsse durch Quantifizierungsversuche von qualitativen Bewertungssystemen • 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 TBM Brand Variante 2: 20 + 10 + 15 = 45 1 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 €

18. Verwendung von einfachen aber exakten Bewertungssystemen - PreliminaryHazard Analysis (PHA) Die PreliminaryHazard 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.

19. Beispiel für eine Einzelrisikobewertung in einer probabilistischen Risiko-Analyse Risiko-Beschreibung, Eintrittswahrscheinlichkeitund Basisinformationen Ergebnis als Verteilungsfunktionzeigt Unsicherheiten Best- bis Worst-Case Evaluierung der Auswirkungen mittels 3-Punkt-Schätzung

20. Projektreview

21. 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.

22. Projektreview Beispiel Baulos H5 Unterinntaltrasse

23. 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 Methodeneinsetzen, 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 Softwarewird an das Projekt angepasst und nicht das Projekt an die Limitierungen der Software. Gewährleistung der obigen Punkte