Der folgende Artikel hat nur 996 Worte und will dennoch das Thema Projektleitung und Projektmanagement auf den Punkt bringen (zur Begriffsverwendung Projektleitung). Ist das angesichts der kilometerlangen Regale mit PM Literatur und den im Widerstreit liegenden Projekt-Religionen ein aussichtsloses Unterfangen? Schaun mr mal.

“Sie kümmern sich jetzt um Projekt X”. Mit diesen Worten beginnen viele Leidensgeschichten. Die erste Diagnosefrage, die sich die/der Projektleiter(in) (PL) in spe stellen sollte lautet: “Ist X wirklich ein Projekt?” bzw. konkreter erfüllt “X” die folgenden Kriterien: Es gibt mindestens

• ein in Worten beschreibbares Ziel oder Arbeitsergebnis,
  das in dieser Form noch nicht existiert,
• eine klare Begründung warum das Projekt gemacht wird,
• einen Termin an dem mit den Arbeiten begonnen wird,
• einen Termin an dem das Arbeitsergebnis vorliegen soll,
• mindestens eine weitere Personen, die zum Arbeitsergebnis beiträgt,
• sowie mindestens eine weitere Person, an die das Arbeitsergebnis geliefert wird.

Wenn sich diese Punkte nicht klar beantworten lassen hat der / die Projektleiter In (PL) schon halb verloren. Dann bahnt sich vielleicht kein Projekt sondern eine Aufgaben-Zeit-Verschiebungsaktion oder eine halbherzige Umorganisation an. Lassen sich die grundlegenden Rollen (z.B. Empfänger des Ergebnisses) wirklich identifizieren und konkrete Ergebnisse formulieren? Bei neuen Aufgabenbereichen, die auf bestehende drauf gepackt werden, ist das oft nicht möglich auch wenn sie gerne Projekte genannt werden, das ist aber ein anderes Thema.

Gehen wir besser davon aus, dass das Ergebnis formuliert und verstanden ist. Dann steht die nächste Frage im Raum: “Wer macht mit?” Zur Erinnerung: Ein-Personen-Veranstaltungen sollten nicht Projekte genannt und mit Management überfrachtet werden. Im positiven Falle sind Mitarbeiter benannt, denen verfügbare Arbeitszeit eingeräumt wird im Projekt zu arbeiten und die zumindest in Ansätzen die notwendigen Qualifikationen mitbringen. Als ersten Schritt gilt es die Mitarbeiter(Innen) zu versammeln und sie über das Projekt ins Bild zu setzen. Als zweiten Schritt sollten sich alle Beteiligten zu einer Auftaktveranstaltung versammeln. In gutem Neudeutsch wird dies oft “Kickoff” genannt. Dieser Begriff aus dem “American Football” trifft es allerdings nicht ganz, er führt sogar ein wenig in die Irre. Bei der Auftaktveranstaltung müssen alle Beteiligten dabei sein. Dazu gehören Leitung, Auftraggeber, Team usw. Die entsprechende sportliche Metapher wäre das Treffen vor dem Spiel, bei dem der Vereinspräsident (Fußball Bundesliga) oder der Clubbesitzer (Basketball NBA) noch mal kurz vorbeischauen. Wenn der Ball zum ersten Mal gespielt wird ist das Team auf sich gestellt, der Auftraggeber sitzt dann schon auf der Tribüne. Ob der Projektleiter wie ein Trainer am Spielfeldrand oder als Spielertrainer bzw. Mannschaftskapitän agiert hängt dabei eher von Projektgröße und persönlichem Leitungsverständnis ab. Leider wird in vielen Projekten schon auf einen solchen Auftakt verzichtet. Für den/die PL der Auftakt eine erste Nagelprobe. Wenn jetzt schon Vorbehalte bzgl. der Verfügbarkeit von Mitarbeitern kommen, wie soll es dann werden wenn im Projekt wirklich gearbeitet werden soll.

Gehen wir weiter davon aus, dass der Auftakt stattgefunden hat. Damit sollten die folgenden Checklistenpunkte guten Gewissens mit “Ja” beantwortet werden können – falls nein “Gehe zurück zum Start”:

• Ist klar, warum was an wen geliefert werden soll und ist es allen bekannt?
• Sind die Projektziele (Anforderungen) zweifelsfrei definiert, klar und allen bekannt?
• Sind Termine definiert und allen bekannt?

Das Projekt beginnt und alles geht seinen Gang. Die Anforderungen werden in Arbeitspaketen in Aufgaben umgesetzt (wie auch immer) und abgearbeitet. Jetzt gibt es nur noch das eine oder andere Risiko das im Weg steht. Hier hilft eine einfache Liste, die wöchentlich bearbeitet und ggf. aktualisiert wird. Risiken haben noch mehr als Projektziele die Eigenschaft sich laufend zu verändern. Für die Aktualisierung der Liste helfen die folgenden Punkte:

• Sind die (aktuell am) größten Risiken bekannt?
• Hat jeder im Team das aus seiner Sicht größte Risiko benannt?
• Welche Risiken sind in der letzten Woche hinzugekommen?
• Welche Risiken wurden bisher entschärft?

Wenn alle diese Punkte mit gutem Gewissen beantwortet und abgehakt werden können ist das Projekt auf einem guten Weg. Aufgabe des / der PL ist es dafür zu sorgen, dass alle (!) Häkchen erhalten bleiben auch wenn sich im Laufe des Projektes die Rahmenbedingungen, Anforderungen oder was auch immer ändern. Wenn ein Projekt in Schieflage gerät ist meistens eines der Häkchen klammheimlich verschwunden. Der kritische Blick welches der Häkchen genau verschwunden ist hilft bei der Einleitung wirkungsvoller Maßnahmen.

Nochmal zurück zum Sport. Von der Tribüne lässt sich das Spiel gut verfolgen. Im Projektgeschäft läuft das ein wenig anders, hier ist der/die PL gefragt. Der Blick von der Tribüne wird durch das Berichtswesen im Projekt ersetzt. Ein pragmatisches Berichtswesen habe ich hier schon beschrieben – Das Schweizer Taschenmesser des Projektberichtwesens – (zugegeben das sind nochmal ein paar Worte zusätzlich). Die Projektberichte müssen immer auch die Risiken enthalten. Wenn Risiken verschwiegen werden (egal in welche Richtung) ist die destruktive Saat des schon Misstrauens gelegt.

Das ist eigentlich schon alles. Damit gelingt sicher nicht jedes Projekt automatisch und es gibt noch manche Details zu beachten wenn diese Punkte nicht erfüllt sind kann man sich alles andere sparen. Und “Hand auf Herz” in manchen Projekten, in denen gigantischer Management-Aufwand verbraten wird, lassen sich diese einfachen Punkte nicht einmal beantworten. Kann z.B. irgendjemand im Milliarden Projekt “Gesundheitskarte”, mit wenigen Worten das Ziel beschreiben. Das ist letztendlich genauso fatal wie das Miniprojekt einer kleinen Firma “Ich will eine neue Software, weiß aber nicht wozu”.

EPILOG: Ich habe bis jetzt kein Wort über konkrete PM Vorgehensweisen, Frameworks, Methoden, Vorgehensmodelle oder sonst etwas geschrieben. Es ist auch unerheblich ob es in dem gewählten Ansatz den Begriff des PL überhaupt gibt. Das hat einen guten Grund: “Es ist aus meiner Sicht weitgehend egal”. Nahezu jeder Ansatz, der verantwortungsbewusst eingesetzt wird, liefert positive Antworten auf obige Fragen. Es ist egal ob ein Scrum-Master die im “daily scrum” aufgetauchten “impediments” beseitigt oder ein klassisches Risikomanagement im Rahmen eines PMP gemacht wird. Das Ergebnis ist dasselbe. Ein Scrum-Master, der die “impediments” nicht beseitigt ist gleich schädlich wie ein Placebo-Risikomanagement, das die Rückmeldungen der Mitarbeiter nicht aufnimmt. Was letztendlich zählt und zum Erfolg führt ist das Vertrauen in die Menschen. Alle Methoden sind nur Hilfsmittel, die den Menschen helfen sollen.

Dieser Text ist unter Creative Commons BY NC ND (Namensnennung – Nicht Kommerziell – Keine Bearbeitung) lizenziert. Er ist Teil des Buchprojekts “Menschen im Projekt”. Er gehört zum Abschnitt 3, siehe Mindmap zu Inhalt und Struktur.

Ähnliche Beiträge:

1. Projektmanagement-Checklisten: Die Erste Stefan Hagen hat heute in seinem Blog einen Beitrag geschrieben, der (Projekt)management sehr klar auf den Punkt bringt. Die...
2. Projektmanagement-Checklisten: Die Zweite Ich hatte im voran gegangenen Beitrag ein Bild eines der Merkkärtchen gezeigt. Wer genau hingeschaut hat, hat bemerkt, dass...
3. Zusammenfassung Projektmanagement – Checklisten Zum Wochenende möchte ich die vorangegangenen Beiträge zu den Projektmanagement-Checklisten zusammenfassen. Hinter den 7 Checklisten steckt natürlich ein gedanklicher...

Nach einem kurzen Exkurs in die Kommunikationstheorie komme ich zurück zu den Projektmanagement-Checklisten. Kommunikation ist der Nährboden auf dem erfolgreiche Projekte wachsen. Ob es um die Klärung von Anforderungen, die Aufgabenverteilung im Team oder die Lösung von Konflikten geht – immer wieder muss aufs Neue mit wechselnden Partnern kommuniziert werden. Die Leitfragen zur Kommunikation zielen dabei nicht auf Gesprächsvorbereitungen im Sinne einer Tagesordnung oder Kommunikationsmatrizen mit denen notwendige Informationsflüsse dokumentiert werden. Diese Aspekte setze ich gewissermaßen voraus. Es geht um das Gelingen eines Gesprächs, es soll verhindert werden, dass aneinander vorbei geredet wird. Die Fragen lauten:

- Bin ich bereit zur Kommunikation?
- Bin ich mir über meine Ziele im klaren?
- Habe ich mich klar ausgedrückt?
- Wurde ich verstanden?
- Verstehe ich mein Gegenüber?
- Denke ich an die “4 Seiten”?

Bin ich bereit zur Kommunikation? Salopp formuliert: Vor wichtigen Gesprächen sollte man auch in Gesprächslaune sein. Ein Gespräch steht unter einem schlechten Stern, wenn ich gerade lieber alleine arbeiten möchte. Das soll keine Aufforderung sein Besprechungen abzusagen, wenn man keine Lust hat. Mit etwas Selbstbeobachtung der Tagesform(en) und vorausschauender Planung lässt sich hier schon viel erreichen. Die Frage hat noch einen weiteren Fokus, nicht immer liegen schon alle Informationen vor, die für ein Gespräch benötigt werden. Wer kennt nicht die Meetings in denen lange diskutiert wird um am Ende festzustellen, dass eine Information fehlt um zu einer Entscheidung zu kommen. In manchen Fällen hätte man sich sogar die Diskussion sparen können, wenn die entscheidende Information zu Verfügung gestanden wäre.

Projektarbeit ist immer zielgerichtet und der Projektleiter ist für das Erreichen der Ziele verantwortlich. Dies spiegelt sich in der zweiten Frage. Für jedes Gespräch sollte man sich vorher über die Ziele im Klaren sein. Egal bb es ein kurzes stand-up-meeting, eine Konfliktlösung oder ein langer Workshop zur Ideenfindung ist – ohne ein klar formulierbares Ziel wird Zeit verschwendet und Frustration bei den Kommunikationspartnern erzeugt.

In jeder konkreten Kommunikationssituation sollte man sich fragen ob man sich klar ausgedrückt hat und ob der Gesprächspartner das gesagte verstanden hat. Die gleiche Frage sollte man sich selbst auch für die erhaltene Rückmeldung stellen. Hintergrund dieser drei Fragen sind unterschiedliche Bedeutungen verwendeter Begriffe, sprachlich-regionale und kulturelle Sprachunterschiede oder gar eine schwerwiegende interkulturelle Miss-Kommunikation.

Die letzte Frage schließt den Kreis und macht alles noch komplizierter, die 4 Seiten einer Botschaft spielen immer eine Rolle.

In diesem Sinne “vor dem Reden kurz Nachdenken” – es lohnt sich.

Ähnliche Beiträge:

1. Projektmanagement-Checklisten: Die Erste Stefan Hagen hat heute in seinem Blog einen Beitrag geschrieben, der (Projekt)management sehr klar auf den Punkt bringt. Die...
2. Kein Projekt ohne Konflikt: Checklisten die Siebte Projekte sind komplex und schaffen etwas Neues. Wenn dem nicht so ist hat das Vorhaben den Namen Projekt nicht...
3. Zusammenfassung Projektmanagement – Checklisten Zum Wochenende möchte ich die vorangegangenen Beiträge zu den Projektmanagement-Checklisten zusammenfassen. Hinter den 7 Checklisten steckt natürlich ein gedanklicher...

In den letzten Wochen habe ich viel über Teams und agiles Projektmanagement geschrieben. Agilität und ein selbstorganisierende Team sind zwar wichtig aber bei weitem nicht allein entscheidend für den Erfolg des Projektes oder die Qualität der produzierten Software. Neben der Beachtung der Teams lohnt sich aber auch ein gründlicher Blick auf die Arbeitsweise von erfolgreichen Entwicklungsteams. Wie wird gute Software denn tatsächlich entwickelt? Ist die eigene Vorgehensweise gut oder schlecht? Anstatt viele Bücher zu wälzen und langwierige Evaluierungen durchzuführen können die Rahmenbedingungen auch mit einem kurzen Test innerhalb von 5 Minuten geprüft werden.

Ein berühmter Test stammt von Joel Spolsky. Er hat zwölf Punkte formuliert, die den Weg zu besserem Code weisen. The Joel Test: 12 Steps to Better Code.

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. …

Ich möchte den Joel Test hier nicht in ganzer Länge zitieren. Er stellt jedoch eine wichtige Grundlage für meinen eigenen 15 Punkte Test dar. Dieser ist an einigen Stellen allgemeiner an anderen Stellen etwas detaillierter formuliert. Es sind jeweils 5 Fragen zu den Bereichen Spezifikation, Vorgehensweise und Rahmenbedingungen bzw. Management. 15 Fragen, für jede 20 Sekunden Zeit um sie mit “Ja” oder “Nein” zu beantworten:

• Haben Sie eine fachliche Spezifikation?
• Haben Sie eine technische Spezifikation?
• Haben Sie dokumentierte Testfälle?
• Haben Sie Tester?
• Haben Sie Tester außerhalb des Entwicklungs- oder Projektteams?

• Verwenden Sie eine Versionsverwaltung?
• Ist Ihr Build-Prozess automatisiert?
• Machen Sie einen täglichen Build?
• Verwenden Sie ein Bugtracking-System?
• Beheben Sie Fehler bevor Sie neuen Code schreiben?

• Kann sich das Entwicklungsteam den Arbeitsplatz selbst gestalten?
• Können die EntwicklerInnen ungestört arbeiten?
• Stehen die besten (Wunsch)-Werkzeuge zur Verfügung?
• Gibt es einen aktuellen und validen Zeitplan?
• Werden Zeit-Schätzungen grundsätzlich von mehr als einer Person gemacht?

15 mal JA: Es gibt kaum noch etwas zu verbessern. Es bleibt höchstens die Frage ob die Fragen wahrheitsgemäß und nicht nur dem Wortlaut nach beantwortet wurden. Es wäre dann z.B. nachzufragen ob die vorhandenen Tester wirklich testen oder nur auf dem Papier vorhanden sind.

weniger als 3 mal JA: Dann haben Sie möglicherweise ein Problem und viel Verbesserungspotential.

Ziel des Tests ist es nicht auf Gedeih und Verderb die volle Punktzahl zu erreichen. Er soll in kürzest möglicher Zeit einen kritischen Blick auf ein konkretes Software-Entwicklungs-Projekt werfen. Die Fragen decken hierbei wichtige Grundsätze der Softwareentwicklung und des Projektmanagements ab, die in der Mindmap nochmals im Zusammenhang dargestellt sind:

Die Mindmap gibt es auch als PDF zum Download: 15 Punkte für gute Software – (Projekte). Und hier die Fragen als ausfüllbare Checkliste: Checkliste 15 Punkte für gute Software.

Ähnliche Beiträge:

1. Agile Methoden erfolgreicher als klassische !? Dass Projekte, die agile Methoden einsezten eine höhere Erfolgsquote haben, hatte ich gestern schon berichtet. In der gleichen Untersuchung...
2. Die WEH Fragen des Projektmanagements Nachdem im vorangegangenen Artikel1 schon die Begriffe “was” und ” wie” im Zusammenhang mit fachlicher und technischer Spezifikation gefallen...
3. Und immer noch mehr Anforderungen / Projektmanagement-Checklisten: die Fünfte Über die manchmal wundersame Vermehrung von Projektzielen oder Anforderungen habe ich hier schon geschrieben. Angesichts der Wichtigkeit des Themas...

Zum Wochenende möchte ich die vorangegangenen Beiträge zu den Projektmanagement-Checklisten zusammenfassen. Hinter den 7 Checklisten steckt natürlich ein gedanklicher Zusammenhang. Ausgehend von der Definition eines Projektes als neuartiges, komplexes und zielorientiertes Vorhaben, das in begrenzter Zeit durchgeführt werden muss, ergeben sich folgende Eigenschaften eines Projektes:

• Die Komplexität erfordert die Mitarbeit von Menschen mit unterschiedlichen Fähigkeiten und Qualifikationen.
• Die Menschen sollten möglichst reibungsfrei zusammenarbeiten können. Das ist leider nicht immer der Fall.
• Die Neuartigkeit und die Komplexität verhindern, dass alle Eventualitäten vorab geplant werden können. Das Auftreten von Problemen gehört damit zum Alltag.
• Angesichts dieser Unwägbarkeiten sollte das Ziel so gut wie möglich im Auge behalten werden.
• Die unterschiedlichen Beteiligten im und außerhalb des Teams müssen kommunizieren können. Die Pflege der Kommunikation macht einen großen Teil des Projektmanagements aus.

In drei Sätzen zusammengefasst:

• Gute Kommunikation ist die Grundlage.
• Risiken in Projekten sind normal.
• Ein Projekt braucht klare Ziele und ein funktionierendes Team.

Die drei größten Risiken, die zwangsläufig in jedem Projekt auftreten, sind unklare Ziele, ein nicht funktionierendes Team sowie schlechte Kommunikation. All dies ist in der nachstehenden Mindmap zusammengefasst:

Die blau umrandeten Zahlen markieren die Ansatzpunkte der 7 Checklisten und die Links zu den Beiträgen der letzten Tage:

• 1. Projektorganisation und Plan
• 2. Projektspezifische Risiken
• 3. Team
• 4. Anforderungen und Ziele
• 5. noch mehr Anforderungen und Ziele
• 6. Kommunikation
• 7. Konfliktlösung

P.S. Diese Check- und Fragelisten sind auf Kärtchen in Visitenkartengröße gedruckt. Auf der Vorderseite ein Bild zum Thema, auf der Rückseite die Fragen. Teilnehmer unserer Seminare erhalten diese Kärtchen umsonst.

Ähnliche Beiträge:

1. Projektmanagement-Checklisten: Die Erste Stefan Hagen hat heute in seinem Blog einen Beitrag geschrieben, der (Projekt)management sehr klar auf den Punkt bringt. Die...
2. Projektmanagement und Kommunikation: Checklisten die sechste Nach einem kurzen Exkurs in die Kommunikationstheorie komme ich zurück zu den Projektmanagement-Checklisten. Kommunikation ist der Nährboden auf dem...
3. Projektmanagement-Checklisten: Die Zweite Ich hatte im voran gegangenen Beitrag ein Bild eines der Merkkärtchen gezeigt. Wer genau hingeschaut hat, hat bemerkt, dass...

Projekte sind komplex und schaffen etwas Neues. Wenn dem nicht so ist hat das Vorhaben den Namen Projekt nicht verdient. Alleine die Neuartigkeit des Ergebnisses sorgt schon dafür, dass es in Projekten zu Konflikten kommen kann. Darüberhinaus sind die Randbedingungen von Projekten ergiebige Konfliktquellen. In Projekten, die nicht optimal laufen, d.h. in den meisten wird es daher immer eine Reihe von Konflikten geben. Gelegentlich kommt es zusätzlich zu einer Überlagerung und Vermischung von Konflikten. Letztendlich muss jeder Konflikt individuell gelöst werden, dennoch lässt sich mit einer guten vorbereiteten Lösungsstrategie viel erreichen. Hier setzten die Fragen der Checkliste an:

- Handelt es sich wirklich um einen Konflikt?
- Gefährdet der Konflikt den Termin?
- Worauf bezieht sich der Konflikt?
- Was sind meine Anteile im Konflikt?
- Suche mehrere Lösungsmöglichkeiten!

Widersprüchliche Rahmenbedingungen sind etwas anderes als ein Konflikt. So sind Auseinandersetzungen über Budgets naturgemäß schwierig und von den gegensätzlichen Wünschen von Auftraggeber und Auftragnehmer geprägt, dennoch handelt es sich hier (noch) nicht um einen Konflikt im engeren Sinne. Ein Konflikt hat immer etwas mit Kommunikation und den beteiligten Menschen zu tun, oft spielen auch Missverständnisse oder Machtkämpfe eine Rolle. In einer echten Konfliktsituation geht der konstruktive Aspekt verloren, das gemeinsame Ziel gerät außer Sicht, Begriffe wie “Gewinnen” oder “Verlieren” werden wichtiger als der der “Lösung”.
Konflikte stellen gerade durch den Verlust des gemeinsamen Ziels eine große Gefahr für das Projekt dar und sollte daher schnellst möglich gelöst werden. Wenn mehrere Konflikte im Raum stehen ist der am dringendsten, der unmittelbare Auswirkungen auf den Termin hat.
Konfliktsituationen sind unübersichtlich, das ist eine Eigenschaft eines Konflikts. Es ist daher sehr wichtig vor Beginn eines Lösungsversuchs so genau wie möglich zu identifizieren “worum es eigentlich geht”. Im Erkennen des echten Konfliktgegenstands liegt die Lösung.
Je neutraler der konfliktlösende Moderator ist desto besser. In den meisten Fällen wird jedoch der oder die Projektleiter(in) den Konflikt moderierend lösen müssen. Eine Projektleitung kann aufgrund ihrer Rolle und den verschiedenen Verantwortungen jedoch nicht neutral sein. Entsprechend ist es wichtig sich die möglichen eigenen Anteile im jeweiligen Konflikt klar zu machen.

Zum Schluss ein guter Tipp: Mehre Lösungsmöglichkeiten im Hinterkopf erleichtern eine Konfliktmoderation erheblich. Es geht nicht einmal darum eine der ausgedachten Lösungen durchzusetzen. Im Gespräch können sich durchaus noch weitere Lösungen ergeben. Das Bewusstsein eine oder mehrere Lösungen zu kennen gibt aber das notwendige Gefühl der Sicherheit.

Ähnliche Beiträge:

1. Projektmanagement und Kommunikation: Checklisten die sechste Nach einem kurzen Exkurs in die Kommunikationstheorie komme ich zurück zu den Projektmanagement-Checklisten. Kommunikation ist der Nährboden auf dem...
2. Zusammenfassung Projektmanagement – Checklisten Zum Wochenende möchte ich die vorangegangenen Beiträge zu den Projektmanagement-Checklisten zusammenfassen. Hinter den 7 Checklisten steckt natürlich ein gedanklicher...
3. Wann ist ein Projekt (k)ein Projekt Diese Frage taucht sehr häufig in der Auswertung der Suchbegriffe aus, sie scheint nicht nur mich immer wieder aufs...

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 – 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 drei größten Risiken?
- Hat jeder im Team sein größtes Risisko benannt?
- Welche Risiken sind in der letzten Woche hinzugekommen?

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.

Sind die drei größten Risiken bekannt? 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 “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?”

Bei der dritten Frage wird es heikel. Kein Projektmanager kann alle Risiken finden. Er ist 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 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.

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.

Und zu guter letzt fehlt noch eines. Für jedes Risiko sollte ein Plan B in der Schublade liegen.

Ähnliche Beiträge:

1. Von Projekten, Risiken und Seereisen (reload) Erstens: Sie sind nicht immer lustig. Zweitens: Eine Seereise liefert schöne Analogien zum Risikomanagement Die Neuartigkeit eines Projekts enthält...
2. Das Schweizer Taschenmesser des Projekt-Berichtswesen Berichtswesen im Projektmanagement, das ist so etwas wie eine Hassliebe. Als freiberuflicher Projektleiter bin ich nahezu in jedem Projekt...
3. Projektmanagement-Checklisten: Die Erste Stefan Hagen hat heute in seinem Blog einen Beitrag geschrieben, der (Projekt)management sehr klar auf den Punkt bringt. Die...