Broadcast, Top-Story: 04.05.2005

Knackpunkt Risikomanagement

Der Einsatz von IT ist in der TV-Produktion mittlerweile Realität. In den meisten Fällen fehlt jedoch ein funktionierendes Risikomanagement, das die mit der neuen Technik verbundenen Risiken bei Broadcast-IT-Projekten reduziert. Thomas Holzmann von der Managementberatung Flying Eye berichtet von seinen Erfahrungen und stellt ein erprobtes Konzept vor. (Um das PDF dieses Artikels zu laden, klicken Sie bitte auf die Dateibezeichnung am Textende.)

1995 veröffentlichte die Standish Group ihren ersten Chaos-Report, der unter anderem aufzeigt, dass nur 16% aller IT-Projekte erfolgreich ablaufen, also im vorgegebenen Budget- und Zeitrahmen bleiben und zu den erwarteten Ergebnissen führen. Leider hat sich dieser Wert in den vergangenen 10 Jahren nicht deutlich verändert: Jüngste Studien belegen, dass es bisher zu keiner signifikanten Verbesserung gekommen ist. Die Pannen bei Software-Projekten der öffentlichen Hand wie etwa bei »Herkules« oder »Arbeitsamt.de« zeigen ebenfalls, dass keine großen Fortschritte in dieser Richtung gemacht wurden.
Die Broadcast-Branche hinkt selbst einem leicht positiven Entwicklungstrend noch hinterher. Die nach wie vor starke Verbreitung von proprietären Hard- und Software-Lösungen in der Produktionstechnik zeigt, dass sich die integrierte IT-Nutzung noch in einem Anfangsstadium befindet.
Dass die Entwicklung hier nicht schneller voranschreitet, liegt an einem Dauer-Dilemma der technischen Investitionen dieser Branche: Einerseits werden enorme Anforderungen gestellt, wie etwa im Sendeablauf, andererseits stellen die Broadcaster keine ausreichenden Mittel zur Verfügung, die für die Entwicklung von zuverlässigen Hochverfügbarkeitssysteme notwendig wären. Die meisten Broadcast-IT-Projekte sind unterfinanziert: Der Anspruch an hohe Funktionalität zu geringen Kosten führt meist dazu, dass an den falschen Stellen gespart wird. In den zurück liegenden Jahrzehnten der IT-Nutzung wurden unzählige solcher Systeme entwickelt – und mit ihnen ganz unterschiedliche Methoden des Projekt-Managements. Dabei wurde das Risikomanagement als Teil des Projektmanagements, dass in diesem Szenario eine besonders hohe Bedeutung haben sollte, regelmäßig vernachlässigt und spielt nur bei den wenigsten Projekten auch tatsächlich eine große Rolle.
Im Folgenden soll zunächst auf die speziellen Risiken der Broadcast-Branche eingegangen werden, bevor eine auf sie abgestimmte Methode des Projektmanagements vorgestellt wird.

Spezielle Risiken der Broadcast-Branche
Der Broadcast-Branche mit ihren speziellen Problemstellungen mangelt es noch an Erfahrung mit der Integration von IT. Sie kann jedoch von den langjährigen Erkenntnissen anderer Anwender profitieren. Schon die Standish-Studie beschreibt allgemeine Risikofaktoren für IT-Projekte:
3,1%: Unklare Definition der Anforderungen
12,4%: Keine Einbeziehung der Nutzer
10,6%: Geringe/keine Ressourcen
9,9%: Unrealistische Erwartungen
9,3%: Keine Unterstützung durchs Management
8,7%: Wachsende Anforderungen, andere Spezifikationen
8,1%: Keine Planung
7,5%: Keine Notwendigkeit mehr fürs Projekt
6,2%: Mangel an IT-Management
4,3%: Unkenntnis der Technologie
9,9%: Andere
Generell treffen diese Faktoren auch für Broadcast-IT-Projekte zu, allerdings mit einer leicht veränderten Gewichtung.

Unklare Definition der Anforderungen
Das Hauptrisiko für IT-Projekte ist laut Standish-Studie mit 13,1% der Faktor unvollständige Anforderungen. Die Beschreibung von Anforderungen, meist Ausschreibungs- und später Vertragsbestandteil, wird häufig nicht ausreichend bzw. präzise ausgeführt. Heute verfügbare, standardisierte Beschreibungsmethoden wie etwa die Unified Modelling Language (UML), werden bei Projekten der Broadcast-Branche allenfalls sporadisch eingesetzt.
Anbieter haben aufgrund kurzer Angebotsfristen in vielen Fällen weder die Zeit noch die finanziellen Ressourcen, um sich intensiv mit den Anforderungen auseinander zu setzen und vor der Angebotsabgabe eine Risiko-Analyse durchzuführen. Eine besondere Rolle spielt auch der Gebrauch einer unterschiedlichen Semantik: Sie führt zu Problemen in der Definition der Anforderungen. Beispielsweise kann der Begriff »Metadaten« im IT-Umfeld etwas ganz anderes bedeuten als im Broadcast-Bereich.

Unrealistische Erwartungen
Der Standish-Chaos-Report nennt unrealistische Erwartungen mit 9,9% als weiteren wichtigen Grund für das Scheitern von IT-Projekten. Bei Projekten im Medienumfeld gibt es hier eine Besonderheit: Unrealistische Erwartungen gibt es auf der Anbieter- wie der Nachfrageseite. Ein plakatives Beispiel aus der Broadcast-Branche, das diese Problematik verdeutlicht, bietet der Archivar, der sich mit dem Material mehrerer Bandgenerationen, analog wie digital, herumschlagen muss. Die materialbegleitenden Metadaten sind zum Teil noch in Karteikästen, teilweise in Mainframe-Datenbanken und teilweise in einer selbst entworfenen Access-Datenbanklösung erfasst. Trifft der Archivar in dieser Situation auf ein IT-Projektteam aus Software-Entwickler und -Verkäufer, die natürlich an ihrem Verkaufserfolg gemessen werden, kann eine verhängnisvolle Mischung von unrealistischen Erwartungshaltungen auf beiden Seiten entstehen: Der Archivar hofft, durch eine ausgefeilte Datenbank endlich eine einheitliche, durchgängige Ordnung in seinem Archiv zu erhalten. Der Software-Entwickler sieht ein Problem n-ter Ordnung, das nur mittels einer sehr großen Anzahl von Rollen, Klassen, Attributen und Relationen zu lösen ist. Der Verkäufer hat mit einer kurzen Überschlagrechnung herausgefunden, dass allein die Provision aus den Hardware-Verkäufen für die Digitalisierung leicht seiner Umsatz-Zielvorgabe bis zur Rente entspricht.
Dem Nutzer fehlt es in dieser Situation meist an Know-how, um die Möglichkeiten und vor allem den Aufwand, der sich hinter der Konzeption einer IT-Lösung verbirgt, richtig einzuschätzen. Er wünscht sich, dass seine Probleme im üblichen Tagesgeschäft gelöst werden und überfordert damit selbst die besten IT-Systeme. Dabei setzt er beim Anbieter des Systems voraus, dass dieser die vorhandenen Probleme a priori kennt, erkennt und lösen kann.
Der oft mit der Branche des Kunden wenig vertraute Software-Entwickler weiß aber tatsächlich nur wenig von den täglichen Problemen und Anforderungen der Anwender. Schon aus diesem Grund kann er das Ziel wahrscheinlich nur zum Teil erreichen. Mangelnde bis völlig fehlende Kommunikation verschärft dieses Problem: Eine Prüfung und ein Abgleich der Erwartungen des Kunden gegen die Möglichkeiten des Entwicklers und beider Sichtweisen gegen die Realität, findet nicht statt.
Dem Verkäufer fehlt meist das notwendige detaillierte Know-how und oft auch das Interesse, sich mit den Prozessen auf der Kunden- und der Entwicklerseite zu befassen. Im Glauben, die Digitalisierung des gesamten Archivs sei wirtschaftlich tragfähig, kommt es häufig zu Fehlkalkulationen. Das Ergebnis eines solchen Projektes ist unschwer zu ermessen. Unrealistische Erwartungshaltungen aufgrund fehlenden Know-hows bergen somit erhebliche Projekt-Risiken.

Wachsende Anforderungen im Projekt
Werden andere Nutzergruppen auf das Projekt aufmerksam, wird teilweise versucht, länger bestehende Probleme einzubringen und im Rahmen des Projekts zu lösen. Hier noch »eine kleine Schnittstelle«, da noch »eine kleine Eingabemaske«, »Das könnt ihr doch nebenbei mitmachen« – im Laufe der Zeit entsteht so ein unübersichtliches Geflecht von Anforderungen, deren Management den Blick auf das Wesentliche des Projektes verstellt.
Besonderes Augenmerk verdienen dabei Anforderungen, die von einer Partei als Klarstellung gesehen werden, frei nach der Devise: »Das war schon immer so gemeint!«. Von der anderen Partei wird derartiges oft als Anforderungserweiterung betrachtet. Solche Vorgänge müssen dokumentiert und möglichst unmittelbar entschieden werden. Eine Verschleppung führt zu einer Kumulation vieler Einzelthemen, die sich dann oft nicht mehr auflösen lassen.
Bereits am Anfang eines Projektes sollte daher ausreichend Zeit darauf verwendet werden, auf beiden Seiten Klarheit über die funktionalen und non-funktionalen Anforderungen zu erhalten.

Änderung der technischen Orientierung
In der Broadcast-Branche ist die Planung der technischen Systeme bisher größtenteils vertikal orientiert. Systeme wurden durchgängig von der Nutzer-Schnittstelle, der Bedienung, bis zur Hardware-Steuerung erstellt. Die Schnittstellen zu anderen Systemen wurden dann mittels einfachem, meist uni-direktionalem Datei-Transfer realisiert – oft genug auch mit einer manuellen Schnittstelle.
Moderne IT-Systeme sind im Unterschied dazu horizontal orientiert. Sie folgen dem Drei-Schichten-Modell: Es enthält die Mensch-Maschine-Schnittstelle als Ebene der Präsentationsschicht, die Ebene der Middleware zur Abbildung der Business-Logik und die Persistenzschicht für die langfristige Datenhaltung, dem physikalischen Layer zur Steuerung der Hardware.
Während sich in den Fernsehanstalten vor allem kaufmännische und rein datenverarbeitende Systeme, wie etwa Redaktionssysteme oder Archivsysteme, bereits weitgehend an dieser Architektur orientieren, ist die Produktionstechnik an vielen Stellen noch vertikal konzipiert. Eine Ausprägung dieser vertikalen Orientierung stellen vor allem die schon angesprochenen proprietären Systeme einzelner Hersteller dar.
Durch die Mischung vertikaler und horizontaler Design-Ansätze entstehen erhebliche Schnittstellen- und Integrationsprobleme. Aus diesen ergeben sich wiederum Risiken, die besonderer Beachtung bedürfen. Durch die horizontale Architektur werden die Geschäftsprozesse immer weiter miteinander verzahnt. Eine wichtige Rolle spielt hierbei auch das so genannte Asset-Management. Den Begriff »Asset-Management« fasst Flying Eye dabei wesentlich weiter, als er von den internationalen Broadcast-Gremien definiert wurde: Assets sind in diesem Zusammenhang nicht nur Essenzen und Metadaten, sondern auch Ressourcen wie Geräte und Personal. Bei dieser Betrachtungsweise macht das Asset-Management als zentrales System alle Informationen so verfügbar, dass Programme auf die Business-Logik-Ebene zugreifen und dadurch die Geschäftsprozesse integrativ unterstützen können.

Kürzere Produktlebenszyklen
Produktlebenszyklus ist ein Begriff aus der Marketingsprache der Produkthersteller und bezeichnet den Zeitraum von der Markteinführung bis zu Abkündigung des Supports eines Produktes. Er ist deutlich von dem Begriff der Nutzungsdauer abzugrenzen.
Aus praktischer Erfahrung mit großen IT-Projekten kann sich die Nutzungsdauer bei IT-Produkten zwischen 7 bis 9 Jahren bewegen, ist damit also vergleichbar mit der Nutzungsdauer der bisher eingesetzten Technik.
Große Projekte bedingen einen längeren Planungszeitraum. Manche Projektmanager gehen dabei sogar davon aus, dass es sich nicht um einen linearen Zusammenhang handelt. Dauert die Planungsphase aber länger als der Produktlebenszyklus der im System eingeplanten Produkte, muss man die Planung in bestimmten Bereichen wiederholen oder aktualisieren.
Die Produktlebenszyklen verkürzen sich jedoch immer mehr. Eine zentrale Erkenntnis lautet daher: Je größer die Projekte werden, desto höher ist die Gefahr, dass das Projekt von der Technik überholt wird. Und dies hat erheblichen Einfluss auf die Planung der Projekte. Nimmt man einen Produktlebenszyklus von drei Jahren für IT-Produkte an, die in einem System geplant werden sollen, und nimmt man weiterhin an, dass nie alle Produkte am Anfang, sondern eher in der Mitte ihres Lebenszyklus beschafft werden, dann folgt daraus, dass bei IT-Projekten mit einer Laufzeit von mehr als 18 Monaten mit einem erheblichen Aufwand an revolvierender Planung zu rechnen ist.
Vermeiden lässt sich dies aus der Sicht von Flying Eye nur durch Modularisierung mit einem klaren Schnittstellen-Management. Dabei wird angestrebt, IT-Projekte möglichst klein und zeitlich kurz zu gestalten.

IT-Einsatz und redaktionelle Kreativität
Der Einsatz moderner Informationstechnologie erfordert diszipliniertes Arbeiten. Der Nutzen eines EDV-Systems geht gegen Null, wenn die Datenqualität nicht stimmt. Üblicherweise ist die Datenqualität umso besser, je früher die Daten im Prozess erfasst werden.
Oft stehen in der Broadcast-Branche aber kreative Kräfte in den Redaktionen am Anfang des Prozesses. Von vielen redaktionellen Mitarbeitern wird die Pflege der Daten als bürokratisch und kreativitätsfeindlich abgelehnt. Als Konsequenz muss dann in den nachfolgenden Prozessschritten ein hoher Aufwand zur Verbesserung der Datenqualität aufgebracht werden.
Für IT-Projekte im redaktionellen Umfeld besteht also permanent das Risiko, dass die Datenqualität nicht den Anforderungen an ein integriertes System entspricht und das IT-System dadurch nicht so arbeiten kann, wie es konzipiert wurde.

Volatilität der Lieferanten
Die beschränkte Größe des Marktes und die Spezialität der Anforderungen führen dazu, dass sich die großen, solventen Anbieter nicht oder nur begrenzt in diesem Markt engagieren. Die kleinen, branchenkompetenten Spezialanbieter bergen aber naturgemäß das Risiko der Diskontinuität. Damit ist nicht nur das Überleben einer Firma in einem schwierigen Marktumfeld gemeint, sondern auch die Kontinuität der Produktlinien. Fehlende Abwärtskompatibilität, das Abkündigen ganzer Produktlinien mit sehr geringen Vorwarnzeiten bis hin zur Insolvenz der Lieferanten sind Ereignisse, von denen viele Anwender aus der Broadcast-Branche berichten können.

Risiko Management
Natürlich sind die hier aufgeführten Risiken nicht die einzigen, die in IT-Projekten im Medienumfeld auftreten können, aus praktischer Erfahrung von Flying Eye sind sie jedoch immer wiederkehrend und signifikant.
Hinter dem Begriff Risiko verbirgt sich »ein Ereignis, von dem nicht sicher bekannt ist, ob es eintreten wird und/oder in welcher genauen Höhe es einen Schaden verursachen wird.« (Schnorrenberg 1997: Risikomanagement in Projekten. Braunschweig)
Ein Risiko ist also ein Faktor, der sich aus der Eintrittwahrscheinlichkeit und der negativen Wirkung auf das Projekt definiert. Ein gutes Risikomanagementsystem muss sich deshalb bei der Bewertung von Risiken immer mit beiden Aspekten befassen und nicht erst bei den Kosten ansetzen, die anfallen würden, wenn das Risiko zum Problem geworden ist.
Das Risikomanagement bei IT-Projekten sollte alle Maßnahmen beinhalten, um potenzielle Risiken im Projektumfeld zu erkennen, ihre Eintrittswahrscheinlichkeit und Auswirkungen zu beurteilen und bei Bedarf geeignete Maßnahmen zur Risikobehandlung zu initiieren (vgl. Gaulke 2002: Risikomanagement bei IT-Projekten. München, Wien, Oldenburg)
Trotz dieser mehr als einleuchtenden Theorie hapert es mit einer konsequenten Umsetzung in der Praxis. Aus der Sicht von Flying Eye liegt ein Grund in dem schlechten Ansehen des Themas Risikomanagement, von dem es heißt, es sei ein Thema der ewigen Nörgler.
Risikomanagement ist keine Methode, um das Scheitern eines Projektes zu suggerieren, sondern ein Werkzeug, um Stolpersteine zu erkennen, diese aus dem Weg zu räumen oder zu umgehen – und so Projekte zum Erfolg zu führen.
Eine konsequente Einführung von Risikomanagement führt zu einer Sensibilisierung der Projektbeteiligten und verhindert das Scheitern eines Projektes. Dabei ist es nicht ausgeschlossen, dass Risikomanagement auch zum Abbruch eines Projektes führen kann. Durch Risikomanagement werden untragbare Risiken früher erkannt, letztlich nicht realisierbare Projekte möglicherweise früher abgebrochen, was in der Regel erhebliche Kosten erspart.

Zirkel des Risikomanagements
Die Abbildung beschreibt das System des Risikomanagements als Zirkel. Er ist in dieser oder ähnlicher Form in fast allen Veröffentlichungen zu finden. Wesentlich ist hier nicht die komplexe Darstellung, sondern der Hinweis darauf, dass dieser Zirkel während eines Projektes immer wieder durchlaufen werden sollte. In der Literatur werden folgende Funktionen des Risikomanagementsystems beschrieben:
– Risiko-Erkennung
– Risiko-Bewertung
– Festlegung von Maßnahmen
– Überwachung der Risiken und Maßnahmen
– Risiko-Kommunikation
Es ist sinnvoll, diesen Zirkel mit seinen Funktionen organisatorisch einem regelmäßigen Turnus zu unterwerfen und ihn folgerichtig den Aufgaben des Projekt-Controllings zuzuordnen.

Risiko Erkennung
Nur Risiken, die erkannt werden, kann man managen. Da es sich bei Risiken um Ereignisse handelt, die möglicherweise in der Zukunft eintreten, ist guter Rat teuer.
Die Kunst des Risikomanagements besteht darin, Risiko-Potenziale zu erfassen. Oft ist ein solches Potenzial nur als latente Ahnung eines erfahrenen Projektleiters oder Projektmitarbeiters vorhanden, oder es wird in der Kaffee-Ecke vom Projektteam heftig diskutiert. Um ein Risiko zu benennen und zu erfassen, gibt es zwei wesentliche Vorgehensweisen, die sich bei näherer Betrachtung auf ein und dieselbe Grundlage stützen: Erfahrung.
Die Erfahrung ergibt sich aus ähnlichen Projekten der Vergangenheit und ist zum Teil nur in den Köpfen der Projektteam-Mitglieder vorhanden. Es ist daher wichtig, diese Erfahrungen allgemein zugänglich zu machen. Reife Organisationen tun dies üblicherweise mittels Risiko-Checklisten, in die die Erfahrungen aus vielen Projekten eingeflossen sind. Auch in der Literatur finden sich solche Listen, die allerdings oftmals den spezifischen Fokus auf Branche oder Anwendung vermissen lassen. Flying Eye hat daher für Projektmanagement-Aufträge Checklisten entwickelt, die spezifisch auf die Themen der Medien-Industrie zugeschnitten sind. Diese Checklisten adressieren verschiedene Inhalte, aber auch verschiedene Phasen des Projektes. So gibt es beispielsweise auch Checklisten vor Angebotsabgabe, mit denen sich die Risiken einer Angebotsabgabe abschätzen lassen können.
Die zweite Vorgehensweise, um Risiken zu erkennen, basiert auf Kreativitätstechniken wie zum Beispiel Brainstorming oder der Delphi-Methode. Die Analyse von Projektdokumenten, moderierte Risiko-Workshops und Experten-Befragungen, die in Form von Fragebogen oder Interviews durchgeführt werden können, sind in diesem Zusammenhang ebenfalls zu erwähnen.

Risiken bewerten
Gefahr erkannt, Gefahr gebannt? Noch nicht ganz: Wie bereits in der Risikodefinition gesehen, setzt sich ein Risiko aus der Eintrittswahrscheinlichkeit und den möglichen Auswirkungen auf das Projekt zusammen. Insbesondere die Eintrittswahrscheinlichkeit ist dabei eine höchst subjektive Größe, da sie ein Ereignis betrifft, das in der Zukunft liegt. Die Einschätzung dieser Eintrittswahrscheinlichkeit basiert damit letztlich wieder auf der Erfahrung Einzelner.
Natürlich gibt es aufwändige Verfahren, solche Wahrscheinlichkeiten zu bestimmen, letztlich laufen sie jedoch darauf hinaus, subjektive Einschätzungen mehrerer Personen zu objektivieren. Flying Eye hat sehr gute Erfahrungen damit gemacht, solche Abschätzungen im Kreise des aus Kunden und Lieferanten bestehenden Projektteams durchzuführen. Wichtig ist aus der Sicht von Flying Eye, dass auch Befürchtungen Einzelner als Minderheitenquorum berücksichtigt werden.
Die Abbildung oben zeigt ein von Flying Eye entwickeltes Verfahren zum Risiko-Management. Die Eintrittswahrscheinlichkeit wird darin in Prozent, die Auswirkungen in Form einer Bewertung von 1-5 angegeben. Das Produkt aus beiden Werten ergibt ein Maß für die Höhe des Risikos innerhalb eines Projektes. Ein Ampel-System (rot-gelb-grün) erleichtert die visuelle Einordnung des Risikos.
Dieses Verfahren wurde bewusst sehr einfach gehalten. Eine komplexe Methode zum Einsatz zu bringen, die nicht nachvollziehbar ist und deshalb von den Projektbeteiligten als reine administrative Last empfunden wird, führt in aller Regel zu mangelhaften Ergebnissen. Darum ist es wichtiger, ein Risikomanagement neben den vielen anderen Aufgaben des Projektmanagements überhaupt erst erfolgreich zu installieren.

Maßnahmen ergreifen
Grundsätzlich gibt es verschiedene Möglichkeiten mit Risiken umzugehen:
– Risiko vermeiden
– Risiko verringern
– Risiko überwälzen
– Risiko tragen
Risiken zu vermeiden, bedeutet in der Regel, völlig andere Lösungswege zu beschreiten. Verringern lässt sich ein Lieferanten-Risiko beispielsweise durch Second-Sourcing. Das Überwälzen eines Risikos ist ein beliebtes Spiel mit Generalunternehmern, auf die man das finanzielle Risiko von kleineren Sub-Lieferanten abwälzt.
Bei der Festlegung der Maßnahmen nimmt vor allem die Smart-Regel eine wichtige Rolle ein. Nach dieser Regel sollten alle Maßnahmen die nachfolgenden Kriterien erfüllen:
– Spezifisch korrekt
– Messbar
– Aktiv beeinflussbar
– Realistisch
– Terminiert
Es scheint fast überflüssig, aber es sei dennoch erwähnt, dass natürlich ein Verantwortlicher als »Task-Owner« benannt werden muss, der die Maßnahme und deren Umsetzung betreibt.

Risiken überwachen und kommunizieren
Nach der Initialphase, die sich vor allem auf die Erkennung der Risiken konzentriert, folgt in der Phase der Projektrealisierung die Überwachung. Schwerpunkt ist dabei die Kontrolle darüber, ob die Maßnahmen auch wirklich greifen. In dem oben vorgestellten Report wird dies dadurch erreicht, dass in jedem Berichtzyklus die der Zirkel des Risikomanagements durchläuft, die Bewertung der Risiken fortgeschrieben wird. Auf der linken Seite des Reports entsteht so eine farblich visualisierte Historie, die eine schnelle Einordnung der Risiken und den zeitlichen Verlauf der Risikoabschätzung erlaubt. Wie bereits angedeutet, ist es in dieser Phase wichtig, dass auch hier immer wieder versucht wird, neu aufgetretene oder noch nicht erkannte Risiken aufzudecken und in den Zyklus des Risikomanagements zu integrieren.

Risikomanagement als Teil des erfolgreichen Projektmanagements
Obwohl viele IT-Projekte scheitern oder erheblich belastet werden, ist das Thema Risikomanagement noch nicht zur Selbstverständlichkeit geworden. Vor allem in der Broadcast-Industrie treten einige spezielle Risiken auf, die ein erfolgreiches Risikomanagement notwendig machen. Unrealistische Erwartungen, unklare und während des Projektes ausufernde Anforderungen sowie eine Vielzahl technischer Schnittstellen führen letztlich dazu, dass Projekte groß, unübersichtlich und langfristig werden. Aufgrund der kürzer werdenden Produktlebenszyklen der im System eingeplanten Produkte und ohne den gezielten Einsatz methodischer Herangehensweisen sind sie nicht mehr plan- und steuerbar. Risikomanagement ist ein effizientes Werkzeug, um Risiken zu erkennen, zu bewerten und auszuräumen. Es sollte deshalb ein selbstverständlicher Teil des Projektmanagements sein – auch und gerade bei Broadcast-Projekten.

Downloads zum Artikel:

T_0505_Risikomanagement.pdf