Guerilla Projektmanagement

IT Projekte und Zeuch

Poker und Projektmanagement

„Tut mir leid, Guerilla-Projektleiter, ich kann dir nicht sagen, wann deine Anforderungen umgesetzt werden. Es gibt bei der Softwareentwicklung einfach zuviel unabsehbare Dinge“. Unfug, Unfug, Unfug!

Klar, wenn man sich nicht mit Risikomanagement beschäftigt, wird man später böse überrascht. Es ist aber eine schlechte Ausrede, sich mit solchen Überraschungen herauszureden – denn damit kommen andere Leute super zurecht.

Das Zauberwort nennt sich „Wahrscheinlichkeiten“.

Beispiel 1: Ein Vertriebler macht seine Umsatzplanung. Er hat die Projekte 1-10 für 1 Mio. EUR und Projekt 11 für 10 Mio. EUR welche noch nicht abgeschlossen sind. Projekt 1 hat eine Eintrittswahrscheinlichkeit von 50%, Projekt 2-10 haben 10% und Projekt 11 hat 25%. Er rechnet: 1*0,5+9*0,1+10*0,25 = 0,5+0,9+4 = 5,4.
Ergebnis: Er plant einen Umsatz von 5,4 Mio EUR.

Beispiel 2: Poker ist ein Glücksspiel (um auf die Überschrift zu kommen). Trotzdem gibt es Profis, welche damit sehr viel Geld verdienen. Viele Profis sind Mathematiker oder Schachgroßmeister. Warum? Poker ist ein Spiel mit Wahrscheinlichkeiten. Wenn man sich daran hält, gibt es zwar keine Garantie das nächste Spiel zu gewinnen, aber auf lange Sicht gewinnt man. Wie geht das?
Angenommen, man hat ein Blatt auf der Hand hat welches eine Siegeswahrscheinlichkeit von 10% hat. im Pott liegen 120 Chips und man muss 10 Chips einsetzen um weiterspielen zu können. Ergebnis: Man setzt die 10 Chips, da man ja in einem von 10 Spielen (bzw. eher in 100 von 1000 Spielen – siehe Gesetz der großen Zahlen) gewinnen würde. Dies wird oft missverstanden. Wenn 10Mal Rot kommt, ist die Wahrscheinlichkeit für Schwarz immer noch 50%, auch wenn es sehr unwahrscheinlich ist, dass 11Mal Rot hintereinander kommt. Aber „On the long run, there is no luck“.

So, was hat das nun mit Projektmanagement zu tun? Sehr viel!

Auch bei Projekten gibt es Risiken mit denen ich Leben muss. Ein Entwickler wird krank, ein anderer Entwickler schreibt oft schlechten Code, Anforderungen sind schlecht formuliert usw. usw. Aus der Erfahrung der Vergangenheit kann ich aber z.B. sehen, dass dieser Entwickler pro Jahr 10 Tage krank ist. Also kenne ich die Wahrscheinlichkeit, dass er auch diesmal krank wird. Oder globaler: Wenn ein Team bei 80% seiner Abschätzungen um 20% der Zeit daneben lag, ist das eine Information welche ich nutzen kann, um die nächste Abschätzung dieses Teams bewerten zu können und einen entsprechenden Buffer einzuplanen.

Wenn ich also in einem Projekt jede meiner geplanten Funktionen nicht nur mit einer Aufwandsabschätzung, sondern auch mit einer Risikoabschätzung versehe, kann ich daraus wunderbar einen Projektplan erstellen, der sehr viel genauer wird.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.