<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>projekt (B)LOG &#187; Risikomanagement</title>
	<atom:link href="http://www.pentaeder.de/projekte/tag/risikomanagement/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pentaeder.de</link>
	<description>über teamorientierte Projektleitung und Projektmanagement</description>
	<lastBuildDate>Mon, 30 Jan 2012 04:40:59 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Aus den Apollo-Missionen für Projekte lernen</title>
		<link>http://www.pentaeder.de/projekte/2010/09/16/aus-den-apollo-missionen-fur-projekte-lernen/</link>
		<comments>http://www.pentaeder.de/projekte/2010/09/16/aus-den-apollo-missionen-fur-projekte-lernen/#comments</comments>
		<pubDate>Thu, 16 Sep 2010 03:58:37 +0000</pubDate>
		<dc:creator>Dr. Eberhard Huber</dc:creator>
				<category><![CDATA[Projektmanagement]]></category>
		<category><![CDATA[Erfolgsfaktoren]]></category>
		<category><![CDATA[Risikomanagement]]></category>
		<category><![CDATA[Teamarbeit]]></category>
		<category><![CDATA[Vision]]></category>

		<guid isPermaLink="false">http://www.pentaeder.de/?p=1462</guid>
		<description><![CDATA[Die erste Mondlandung liegt 40 Jahre zurück. Der erste Mann auf dem Mond Neil Armstrong hat kürzlich seinen 80. Geburtstag gefeiert. Die Nasa stellt die Mission-Reports im Internet zum Download bereit. Das ist nochmal eine Gelegenheit die Apollo Missionen unter dem Projekt-Gesichtspunkt zu betrachten. Das Apollo-Programm war ein riesiges Projekt, 40000 Mitarbeiter, Milliardenbudget, mehr als [...]]]></description>
			<content:encoded><![CDATA[<p>Die erste Mondlandung liegt 40 Jahre zurück. Der erste Mann auf dem Mond Neil Armstrong hat kürzlich seinen <a href="http://www.tagesschau.de/ausland/armstrong178.html" target="_blank">80. Geburtstag gefeiert</a>. Die Nasa stellt die <a href="http://www.hq.nasa.gov/alsj/alsj-mrs.html" target="_blank">Mission-Reports</a> im Internet zum Download bereit. Das ist nochmal eine Gelegenheit die Apollo Missionen unter dem Projekt-Gesichtspunkt zu betrachten. Das Apollo-Programm war ein riesiges Projekt, 40000 Mitarbeiter, Milliardenbudget, mehr als 10 Jahre Laufzeit, haufenweise technologische Herausforderungen und ein immenses Risikopotential. Ein Projekt, das eigentlich kaum zu managen war aber dennoch zum Erfolg führte. Woran lag es? Was können wir für ganz normale Projekte daraus lernen. Es war die Vision, das Ziel des Projektes. Dieses Ziel war unglaublich groß, herausfordernd fast furchteinflößend und dennoch in einem Satz zu formulieren. Lassen wir John F. Kennedy zu Wort kommen:</p>
<blockquote><p>
    … to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth.
</p></blockquote>
<p>Eine Vision von bestechender Klarheit. Jede(n) der 40000 MitarbeiterInnen hätte man fragen können “Warum macht ihr das?” und jede(r) hätte geantwortet. Unsere Jungs sollen zum Mond fliegen, landen und wieder heil zurückkommen. Die Klarheit der Vision ist der erste Schritt zum Erfolg. Obwohl in normalen Projekten immer auf die Klarheit der Vision und Ziele gepocht wird sieht die Realität oft anders aus. In vielen Projekten ist es die Regel auf die Frage nach dem “Warum” eine Multiple Choice Antwort zu erhalten.</p>
<p>Mit Apollo 11 wurde die von Kennedy formulierte Vision erfüllt. Aus den nachfolgenden Apollo-Missionen lässt sich noch mehr für die Projektarbeit lernen. Apollo 13 liefert Erkenntnisse über Risiken und die kollektive Intelligenz eines Teams. Die Explosion im Apollo 13 Raumschiff entstand aus der Wechselwirkung mehrerer Ursachen mit einer möglicherweise nicht kommunizierten Spezifikationsänderung. Das ist kein Witz. Tausenden von Ingenieuren und Wissenschaftlern war entgangen, dass zwar die Spezifikation der Thermoschalter in den Sauerstofftanks von 28 auf 65 Volt geändert wurde, die Schalter aber nicht ausgetauscht wurden. Einer der Schalter schmolz aufgrund der hohen Spannung bei der Flugvorbereitung durch und verursachte dann an Bord die Explosion mit den bekannten Folgen, dass Strom und Sauerstoff an Bord knapp wurden. Es lohnt sich zwei Gedanken aus diesem Ereignis mitzunehmen:</p>
<ul>
<li>Es gibt immer etwas was man übersehen hat.</li>
<li>Selbst wenn es sich um eine Kleinigkeit handelt kann die Auswirkung riesig sein.</li>
</ul>
<p>Und was hat das mit einem Team und kollektiver Intelligenz zu tun? Eine der wichtigsten Ideen bei der Rettung der Crew war es die Sauerstoffaufbereitung (Kohlendioxid-Filter) des Landers und des Mutterschiffs zu koppeln. Eine einfach umzusetzende Idee, wenn die Filteranschlüsse kompatibel gewesen wären. Die Einen waren dreieckig, die Anderen viereckig, ein Adapter war natürlich nicht an Bord. Hier drängt sich der Gedanke auf, dass bei der Spezifikation der Systeme vielleicht nicht ausreichend kommuniziert wurde <img src='http://www.pentaeder.de/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' />  Nun aber zur Lösung des Problems. Das Problem wurde zuerst exemplarisch auf dem Boden gelöst. Dieses Meeting von technischen Spezialisten der Apollo Mission ist die Mutter aller Teamübungen – bei Teamentwicklungsmaßnahmen spricht man heute noch von einer NASA-Übung. Dieses Meeting zeichnet sich wiederum durch glasklare Ziele sowie eine materielle und zeitlich Begrenzung aus:</p>
<ul>
<li>Wir müssen innerhalb weniger Stunden, diese zwei Anschlüsse verbinden.</li>
<li>An Material steht nur das zur Verfügung was auf dem Tisch liegt.</li>
</ul>
<p>Auf dem Tisch lagen die losen und entbehrlichen Teile, die in einer Apollokapsel zur Verfügung standen. Mit zerschnittenen Plastikteilen, der Kunststofffolie des Bordbuch-Einbandes und Klebeband entstand der Adapter, der das Überleben der Crew ermöglichte. Das zusammengewürfelte Team hatte Erfolg. Die Ideen der einzelnen vereinten sich konstruktiv zu einer Lösung, die im ersten Moment nicht für möglich gehalten wurde.</p>
<p>Eine klare Aufgabe ist immer der Einstieg in eine konstruktive und lösungsorientierte Teamarbeit. Auch in ganz normalen Projekten können Krisen kreativ gelöst werden. Manchmal ist Projektmanagement nur eine Aneinanderreihung vieler NASA-Übungen.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.pentaeder.de/projekte/2010/09/16/aus-den-apollo-missionen-fur-projekte-lernen/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Das Schweizer Taschenmesser des Projekt-Berichtswesen</title>
		<link>http://www.pentaeder.de/projekte/2010/07/05/das-schweizer-taschenmesser-des-projekt-berichtswesen/</link>
		<comments>http://www.pentaeder.de/projekte/2010/07/05/das-schweizer-taschenmesser-des-projekt-berichtswesen/#comments</comments>
		<pubDate>Mon, 05 Jul 2010 03:35:06 +0000</pubDate>
		<dc:creator>Dr. Eberhard Huber</dc:creator>
				<category><![CDATA[Projektmanagement]]></category>
		<category><![CDATA[Risikomanagement]]></category>
		<category><![CDATA[Werkzeuge]]></category>

		<guid isPermaLink="false">http://www.pentaeder.de/?p=1339</guid>
		<description><![CDATA[Berichtswesen im Projektmanagement, das ist so etwas wie eine Hassliebe. Als freiberuflicher Projektleiter bin ich nahezu in jedem Projekt mit anderen Vorlagen oder Formularen konfrontiert. Über die Unsinnigkeit mancher Berichte möchte ich heute nicht viele Worte verlieren. Ich möchte nur ein negatives Beispiel kurz anreißen: Ein  Bericht, der nur die verbrauchten Stunden erfasst die [...]]]></description>
			<content:encoded><![CDATA[<p>Berichtswesen im Projektmanagement, das ist so etwas wie eine Hassliebe. Als freiberuflicher Projektleiter bin ich nahezu in jedem Projekt mit anderen Vorlagen oder Formularen konfrontiert. Über die Unsinnigkeit mancher Berichte möchte ich heute nicht viele Worte verlieren. Ich möchte nur ein negatives Beispiel kurz anreißen: Ein  Bericht, der nur die verbrauchten Stunden erfasst die Erledigung der Aufgaben jedoch außen vor lässt, nützt niemandem. Der so ermittelte Ampelstatus ist sogar mehr als überflüssig, weil er Probleme eher verschleiert als aufzeigt. Anstelle weitere schlechte oder gute Bespiele anzuführen möchte ich eine Form des Berichtes vorstellen, die ich selbst in sehr vielen Projekten verwende. Es handelt sich um ein Projekttagebuch oder Projektjournal. Wie der Name nahelegt, wird das Journal sehr regelmäßig geführt. Regelmäßig &#8211; das heißt mindestens einmal die Woche. Inhaltlich liefert es Antworten auf folgende Fragen:</p>
<ul>
<li>Was wurde in der vergangenen Woche erledigt?</li>
<li>Was soll in der kommenden Woche erledigt werden?</li>
<li>Welche Risiken sind hinzugekommen, welche haben sich verändert?</li>
<li>Wie sieht der gefühlte Gesamtstatus des Projektes aus?</li>
<li>Gibt es Entscheidungs- und Eskalationsbedarf? </li>
</ul>
<p><span id="more-1339"></span></p>
<p><a rel="lightbox" href="http://www.pentaeder.de/wp-content/uploads/projektjournal.png"><img src="http://www.pentaeder.de/wp-content/uploads/projektjournal-150x107.png" alt="Screenshot Beispiel Projektjournal" title="Beispiel Projektjournal" width="150" height="107" class="alignleft size-thumbnail wp-image-1340" /></a>Die konkrete Form kann natürlich variieren. In einem agilen Projekt wird das Journal ggf. durch das Taskboard und das tägliche Meeting ersetzt. In klassischeren Projekten setze ich häufig eine tabellarische Form ein (siehe Abbildung, Download der Vorlage am Ende des Beitrages). Dabei entspricht jede Zeile einer Projektwoche. In der ersten Spalte sind die abgeschlossenen Aktivitäten der vergangenen Woche notiert, die für die kommende Woche vorgesehenen Aktivitäten stehen in der zweiten Spalte. Die dritte Spalte ist den Risiken vorbehalten. Diese werden in Ampelfarben markiert. Die letzen beiden Spalten sind für eine einfache Gesamtbewertung des Projektstandes (farbige Smileys) bzw. (falls notwendig) zur Dokumentation von Entscheidungs- bzw. Eskalationsbedarf vorbehalten. Die Verteilung erfolgt meist per Mail und zwar an alle: Projektteam, Lenkungsgremien, Auftraggeber, Dienstleister. Wenn es das Format der Mail zulässt, enthält sie bereits die erste (aktuelle) Zeile des Journals, im Anhang befindet sich zusätzlich das vollständige Journal mit allen zurückliegenden Wochen. Die Regelmäßigkeit und der vollständige Verteiler liefern den Nutzen des Journals:</p>
<ul>
<li>Alle haben zeitgleich einen aktuellen Informationsstand.</li>
<li>Der Stand des Projektes ist mit wenigen Blicken erfassbar.</li>
<li>Der &#8220;Ampelstatus&#8221; des Projektes ist nicht &#8220;willkürlich errechnet&#8221;, sondern für jeden aus den Aufgaben und Risiken nachvollziehbar.</li>
<li>Erledigte Aufgaben nochmals zu erwähnen macht ein gutes Gefühl : &#8220;Wir haben etwas geschafft&#8221;.</li>
<li>Schieflagen werden schneller transparent.</li>
</ul>
<p>Ob man den letzten Punkt wirklich als Vorteil oder als Nachteil betrachtet sei dahingestellt. Als Verschleierungsdokument taugt das Projektjournal jedenfalls nicht, hier sind Ehrlichkeit und Transparenz angesagt. Durch die regelmäßige Aktualisierung kann jede(r) sehr leicht nachvollziehen ob Inkonsistenzen vorhanden sind. Zu guter Letzt lässt sich aus dem Journal jeder andere ggf. offiziell erwünschte Bericht leicht erstellen. In kleinen Projekten kann das Journal als Kombination von Bericht und Risikoverfolgung ggf. alle anderen Berichte ersetzen.</p>
<p>Download: <a href='http://www.pentaeder.de/wp-content/uploads/Projektjournal.docx'><br />
Vorlage Projektjournal: Word Format 2007</a><br /><a href='http://www.pentaeder.de/wp-content/uploads/Projektjournal.doc'>Vorlage Projektjournal: Word Format 2003</a><br /><a href='http://www.pentaeder.de/wp-content/uploads/Projektjournal.odt'>Vorlage Projektjournal: Open Office Format</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.pentaeder.de/projekte/2010/07/05/das-schweizer-taschenmesser-des-projekt-berichtswesen/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>von verstopften Rohren, Engpässen und höheren Gewalten</title>
		<link>http://www.pentaeder.de/projekte/2010/04/16/von-verstopften-rohren-engpassen-und-hoheren-gewalten/</link>
		<comments>http://www.pentaeder.de/projekte/2010/04/16/von-verstopften-rohren-engpassen-und-hoheren-gewalten/#comments</comments>
		<pubDate>Fri, 16 Apr 2010 05:40:05 +0000</pubDate>
		<dc:creator>Dr. Eberhard Huber</dc:creator>
				<category><![CDATA[Projektmanagement]]></category>
		<category><![CDATA[Planung]]></category>
		<category><![CDATA[Risikomanagement]]></category>

		<guid isPermaLink="false">http://www.pentaeder.de/?p=1265</guid>
		<description><![CDATA[Vielleicht sollte ich die Worte der Überschrift etwas erläutern. Das verstopfte Rohr ist ein aktuelles und reales Problem im Hause. Nichts was sich nicht durch etwas Arbeit und die Hilfe eines Rohrreinigungs-Service wieder lösen ließe, aber es kostet unvorhergesehen Zeit, Nerven und Geld. Anstatt wichtige Dinge zu erledigen, stehe ich in Gummistiefeln auf dem Hof [...]]]></description>
			<content:encoded><![CDATA[<p>Vielleicht sollte ich die Worte der Überschrift etwas erläutern. Das verstopfte Rohr ist ein aktuelles und reales Problem im Hause. Nichts was sich nicht durch etwas Arbeit und die Hilfe eines Rohrreinigungs-Service wieder lösen ließe, aber es kostet unvorhergesehen Zeit, Nerven und Geld. Anstatt wichtige Dinge zu erledigen, stehe ich in Gummistiefeln auf dem Hof und versuche den Engpass im Abflussrohr zu beseitigen. </p>
<p>Mit der Projektleiterbrille sehe ich das Ganze als eine unvorhergesehene Störung, einen plötzlich auftretenden Zeitengpass, die zu einer Planabweichung des eigentlichen Projektes führen wird. Ein Stück weit ist das verstopfte Rohr höhere Gewalt. Auch die Wolke aus Vulkanasche, die heute über Deutschland hinweg zieht und Flughäfen lahm legt, ist höhere Gewalt. Weder das verstopfte Rohr noch der Vulkanausbruch sind in einem Projektplan als mögliches Zeitverlust-Risiko enthalten. Ich stelle mir gerade vor in einem Projektantrag würde stehen &#8220;Puffer, für unvorhergesehene Ereignisse wie &#8220;verstopfte Rohre&#8221; oder &#8220;Vulkanausbrüche&#8221;. Eine solche Formulierung würde im günstigsten Fall für Heiterkeit sorgen. </p>
<p>Vorhersehen und präventiv einplanen lassen sich solche Ereignisse also nicht. Das ändert aber nichts daran, dass sie eintreten. Letztendlich lässt sich dieses Problem auch nicht lösen. Es geht mehr darum eine innere Einstellung zu finden um stressreduziert mit solchen Störungen umzugehen. Ich habe mir dazu drei Dinge hinter die Ohren geschrieben:</p>
<ul>
<li>Akzeptiere, dass es Störungen gibt, und freue Dich über jeden Tag, der ohne Störung verläuft.</li>
<li>Eine Störung ist nur eine kurzzeitige Verschiebung der Prioritäten.</li>
<li>Eine gründlich beseitigte Störung kommt nicht so schnell wieder, und schafft neuen Freiraum.</li>
</ul>
<p>und jetzt ziehe ich meine Gummistiefel an <img src='http://www.pentaeder.de/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
]]></content:encoded>
			<wfw:commentRss>http://www.pentaeder.de/projekte/2010/04/16/von-verstopften-rohren-engpassen-und-hoheren-gewalten/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Von Projekten, Risiken und Seereisen (reload)</title>
		<link>http://www.pentaeder.de/projekte/2010/03/31/von-projekten-risiken-und-seereisen-reload/</link>
		<comments>http://www.pentaeder.de/projekte/2010/03/31/von-projekten-risiken-und-seereisen-reload/#comments</comments>
		<pubDate>Wed, 31 Mar 2010 06:43:58 +0000</pubDate>
		<dc:creator>Dr. Eberhard Huber</dc:creator>
				<category><![CDATA[Projektmanagement]]></category>
		<category><![CDATA[Buch: Mensch im Projekt]]></category>
		<category><![CDATA[Risikomanagement]]></category>

		<guid isPermaLink="false">http://www.pentaeder.de/?p=1249</guid>
		<description><![CDATA[Erstens: Sie sind nicht immer lustig. Zweitens: Eine Seereise liefert schöne Analogien zum Risikomanagement  
Die Neuartigkeit eines Projekts enthält zwangsläufig unbekannte Faktoren, die sich zu Risiken entwickeln können. Ein zu Beginn des Projekts erstellter Plan kann die Risiken des Projektes nie vollständig berücksichtigen. Risikomanagement ist daher unerlässlich. Risikomanagement ist eine eigene Disziplin und kann [...]]]></description>
			<content:encoded><![CDATA[<p>Erstens: Sie sind nicht immer lustig. Zweitens: Eine Seereise liefert schöne Analogien zum Risikomanagement <img src='http://www.pentaeder.de/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>Die Neuartigkeit eines Projekts enthält zwangsläufig unbekannte Faktoren, die sich zu Risiken entwickeln können. Ein zu Beginn des Projekts erstellter Plan kann die Risiken des Projektes nie vollständig berücksichtigen. Risikomanagement ist daher unerlässlich. Risikomanagement ist eine eigene Disziplin und kann sehr aufwändig gestaltet werden. Ich möchte bewusst einen einfachen Ansatz dagegen halten. </p>
<p class="wichtig">
Es ist besser ein einfaches Risikomanagement anzuwenden als ein aufwändiges zu vernachlässigen.
</p>
<p>Anstelle einer Definition beginne ich mit einem einfachen Vergleich. Es ist nicht ganz klar woher das Wort Risiko stammt. Eine Erklärung führt es auf das griechische Wort rhizikon („Klippe“) zurück. Die Bedeutung Klippe, die umschifft werden muss um nicht zu scheitern, liefert mit den bildlichen Vergleich. Ein Projekt ist wie eine Seereise zu einem weit entfernten Wunsch-Ziel durch unbekanntes Gewässer. Die Vorräte an Bord des Schiffes sind begrenzt d.h. das Ziel sollte möglichst in der geplanten Zeit erreicht werden. Auf der Reise müssen unter Umständen viele Klippen umschifft und andere Hindernisse überwunden werden.</p>
<p>Die Hauptaufgaben des Risikomanagements</p>
<ul>
<li>Risiken erkennen</li>
<li>Risiken bewerten</li>
<li>Gegenmaßnahmen planen</li>
</ul>
<p>werden mit dem Vergleich greifbar. Zuerst müssen möglichst viele der Klippen und Schwierigkeiten auf dem Weg erkannt werden. Schön wäre natürlich eine Seekarte auf der alle Klippen und Untiefen verzeichnet sind. Dann kommt noch eine Karte der Meeresströmungen, eine Wetterkarte usw. hinzu. Da solche Karten bei der Fahrt in wirklich unbekannte Gewässer in der Regel nicht existieren ist man überwiegend auf Vermutungen angewiesen und muss sich seine Karten selbst zeichnen. Selbst wenn bereits Karten vorhanden sind stellt sich immer noch die Frage nach der Verlässlichkeit des Kartenmaterials.</p>
<p>Wenn man glaubt die meisten Klippen und Untiefen zu kennen, muss im nächsten Schritt geprüft werden wie gefährlich jedes Hindernis wirklich ist. Wie tief ist eine Untiefe wirklich, wie dicht liegen Untiefen und Klippen neben einander, wie sehen die Meeresströmungen an dieser Stelle aus, wie gut lässt sich manövrieren.</p>
<p>Nimmt man ein Schiff mit weniger Tiefgang (wannenförmiger Rumpf = Mississippi Dampfer) lässt sich vielleicht die eine oder andere Untiefe einfach überfahren. Liegen viele Klippen dicht beieinander ist wiederum ein wendiges manövrierfähiges Schiff von Vorteil. Das wendige Schiff hat dafür aber wieder mehr Tiefgang als ein Schiff mit wannenförmigem Rumpf. Liegen Klippen und Untiefen im Weg sind vielleicht mehrere kleine, wendige Schiffe gegenüber einem großen im Vorteil.</p>
<p>Mit mehreren kleinen Schiffen wäre ein Kompromiss zwischen Wendigkeit und geringem Tiefgang gefunden. Hinzu kommt jetzt die Schwierigkeit die Schiffe zu koordinieren um die Flotte z.B. bei Nebel zusammenzuhalten.</p>
<p>Es wird deutlich, dass aus einer gründlichen Betrachtung der Risiken sich meist auch Ansätze für Gegenmaßnahmen zur Beherrschung oder Vermeidung derselben ergeben. Auch die Rückwirkung auf den Plan und die Projektorganisation ergeben sich relativ leicht (z.B. bedeuten mehrere Schiffe mehrere Kapitäne + einen Commodore). Dennoch wird in vielen Projekten systematisches Risikomanagement sträflich vernachlässigt. Meist steht der Aspekt Ressourcen &#8211; Planung zu stark im Vordergrund. Im Bild der Schiffsreise gesprochen wird oft zu viel Zeit auf die Katalogisierung der Ladung und die Mannschaftsliste verschwendet und dabei der Blick auf die Seekarte vergessen. Der Aufwand für Risikomanagement wird gerne eingespart. Wie kann  ein pragmatisches und schlankes Risikomanagement in einem Projekt aussehen? Mit einer Liste und 4 Fragen, die sich die Projektleitung regelmäßig stellen sollte kommt mann/frau schon sehr weit:</p>
<ul>
<li>Sind die drei größten Risiken bekannt?</li>
<li>Was sind heute die drei größten Risiken?</li>
<li>Hat jeder im Team sein größtes Risiko benannt?</li>
<li>Welche Risiken sind in der letzten Woche hinzugekommen?</li>
</ul>
<p>Aus der Formulierung der Fragen lässt sich schon erahnen, dass sie regelmäßig, das heißt jede Woche oder sogar täglich neu gestellt und beantwortet werden müssen.</p>
<p>Sind die drei größten Risiken bekannt? Selbst wenn im Projekt ein ausgewiesenes Risikomanagement betrieben wird, heißt das noch lange nicht, dass die größten Risiken bekannt sind. In der Formulierung “groß” steckt eine intuitive Mischung der Faktoren Eintrittswahrscheinlichkeit und Auswirkung. Diese sind leider nicht konstant und müssen ständig neu bewertet werden. Bevor man sich in seitenlangen Abwägungen und Wahrscheinlichkeitsrechnungen verheddert, ist es besser sich regelmäßig die zweite Frage nach dem heutigen Risiko zu stellen – getreu dem Motto: “Wo drückt der Projektschuh jetzt in diesem Moment?”</p>
<p>Bei der dritten Frage wird es heikel. Keine Projektleitung kann alle Risiken finden. Sie letztendlich darauf angewiesen, dass alle im Team mit der Sprache rausrücken und das größte Risiko von dem sie wissen benennen. Die simple Frage “Weiß noch jemand was?” hilft hier nicht viel weiter. Es ist wichtig, dass im Team nicht ein Klima der Angst vorherrscht. Wenn die Angst regiert wird niemand gerne über Risiken sprechen. Die letzte Frage greift das Problem der unvollständigen Risikolisten nochmals in anderer Form auf.</p>
<p>Ich schließe mit einer provokanten Aussage und einer Wiederholung:</p>
<ul class="wichtig">
<li>Es ist besser ein einfaches Risikomanagement anzuwenden als ein aufwändiges zu vernachlässigen.</li>
<li>Projektarbeit ohne Risikomanagement ist grob fahrlässig.</li>
</ul>
<p>Dieser Text ist unter <a href="http://creativecommons.org/licenses/by-nc-nd/3.0/de/" target="_blank">Creative Commons BY NC ND</a> (Namensnennung &#8211; Nicht Kommerziell &#8211; Keine Bearbeitung) lizenziert. Er ist Teil des <a href="http://www.pentaeder.de/projekte/2009/09/16/wir-schreiben-ein-buch-uber-projektmanagement/" target="_blank">Buchprojekts &#8220;Menschen im Projekt&#8221;.</a> Er gehört zum Abschnitt X, siehe <a href="http://www.pentaeder.de/projekte/2009/10/11/mensch-im-projekt-inhalt-und-struktur-des-buches/">Mindmap zu Inhalt und Struktur</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.pentaeder.de/projekte/2010/03/31/von-projekten-risiken-und-seereisen-reload/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Projektmanagement-Checklisten: Die Zweite</title>
		<link>http://www.pentaeder.de/projekte/2009/02/20/projektmanagementchecklisten-die-zweite/</link>
		<comments>http://www.pentaeder.de/projekte/2009/02/20/projektmanagementchecklisten-die-zweite/#comments</comments>
		<pubDate>Fri, 20 Feb 2009 11:24:22 +0000</pubDate>
		<dc:creator>Dr. Eberhard Huber</dc:creator>
				<category><![CDATA[Projektmanagement]]></category>
		<category><![CDATA[Checkliste]]></category>
		<category><![CDATA[Risikomanagement]]></category>

		<guid isPermaLink="false">http://www.pentaeder.de/?p=361</guid>
		<description><![CDATA[Ich hatte im voran gegangenen Beitrag ein Bild eines der Merkkärtchen gezeigt. Wer genau hingeschaut hat, hat bemerkt, dass auf dem Bild die Fragen zum Risikomanagement zu sehen sind &#8211; um diese solle es heute gehen. Hier zuerst einmal die 4 kurzen und pragmatischen Fragen:
- Sind die drei größten Risiken bekannt?
- Was sind heute die [...]]]></description>
			<content:encoded><![CDATA[<p>Ich hatte im <a href="http://www.pentaeder.de/projekte/2009/02/19/projektmanagement-checklisten-die-erste/" target="_blank">voran gegangenen Beitrag</a> ein Bild eines der Merkkärtchen gezeigt. Wer genau hingeschaut hat, hat bemerkt, dass auf dem Bild die Fragen zum Risikomanagement zu sehen sind &#8211; um diese solle es heute gehen. Hier zuerst einmal die 4 kurzen und pragmatischen Fragen:</p>
<p>- Sind die drei größten Risiken bekannt?<br />
- Was sind heute die drei größten Risiken?<br />
- Hat jeder im Team sein größtes Risisko benannt?<br />
- Welche Risiken sind in der letzten Woche hinzugekommen?</p>
<p><span id="more-361"></span></p>
<p>Aus der Formulierung der Fragen lässt sich schon erahnen, dass man sich diese Fragen regelmäßig, das heißt jede Woche oder sogar täglich neu stellen muss.</p>
<p><strong>Sind die drei größten Risiken bekannt?</strong> Selbst wenn im Projekt ein ausgewiesenes Risikomanagment betrieben wird, heißt das noch lange nicht, dass die größten Risiken bekannt sind. In der Formulierung &#8220;<strong>groß</strong>&#8221; steckt eine intuitive Mischung der Faktoren Eintrittswahrscheinlichkeit und Auswirkung. Diese sind leider nicht konstant und müssen ständig neu bewertet werden. Bevor man sich in seitenlangen Abwägungen und Wahrscheinlichkeitsrechnungen verheddert, ist es besser sich regelmäßig die zweite Frage nach dem <strong>heutigen Risiko</strong> zu stellen &#8211; getreu dem Motto: &#8220;Wo drückt der Projektschuh jetzt in diesem Moment?&#8221;</p>
<p>Bei der dritten Frage wird es heikel. Kein Projektmanager kann alle Risiken finden. Er ist letztendlich darauf angewiesen, dass <strong>alle im Team mit der Sprache rausrücken</strong> und  das größte Risiko von dem sie wissen benennen. Die simple Frage &#8220;Weiß noch jemand was?&#8221; hilft hier nicht viel weiter. Es komt darauf an, dass das Klima und die Atmosphäre im Team stimmt, dass sich jede(r) traut ein Risiko zu benennen. Die Schaffung dieses Klimas ist jedoch ein anderes Thema.</p>
<p>Die letzte Frage kümmert sich um das leidige Thema, dass Risikolisten nie vollständig sind und immer neue Risiken hinzukommen. Risiken, die sich erledigt haben und noch auf der Liste stehen, stören niemanden. Risiken, die man nicht erkennt, werden irgendwann zum Problem.</p>
<p>Und zu guter letzt fehlt noch eines. Für jedes Risiko sollte  <strong>ein Plan B</strong> in der Schublade liegen. </p>
]]></content:encoded>
			<wfw:commentRss>http://www.pentaeder.de/projekte/2009/02/20/projektmanagementchecklisten-die-zweite/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>

