Projektmanagement – eine Einführung

Noch ist es, vor allem in Deutschland und vor allem in der IT-Branche sehr selten, dass professionelles Projektmanagement eingesetzt wird. Viele Projekte werden sprichwörtlich in den Graben gefahren, Budgets werden nicht eingehalten, die Projekte werden zu teuer, erfüllen nicht die gewünschten Anforderungen und/oder benötigen viel mehr Zeit als geplant. Letztes großes Beispiel eines fehlgelaufenen Projekts (warum sei nun mal dahin gestellt) ist das vom Bund eingeführte Mautsystem für Lkw.

Viele Projekte werden falsch, zu wenig oder oft sogar gar nicht geplant. Es gibt keinen Projektplan (oft ist der Plan einige wenige zusammengeklickte Punkte in Microsoft Project), Stakeholder1 werden nicht eingebunden, es gibt keine Risikoabschätzungen, es werden meist keine Tools (bspw. zur Versionskontrolle wie SVN, Bug-Tracking Systeme wie Mantis oder ähnliches) eingesetzt und die Aufwände werden falsch geschätzt. Oft wird ein Projekt auch nicht richtig eingeleitet (gestartet) und meist gar nicht richtig abgeschlossen. Nachbesprechungen was es für Probleme/Fehler mit dem Projekt gab oder was man gelernt hat, abschließen von Dokumenten usw. wird oft völlig vernachlässigt. In den meisten Fällen wird das Projekt mit der Übergabe der Ergebnisse an den Kunden abgeschlossen. Dementsprechend sind auch fast alle Projekte in der IT-Branche (dort vor allem!) außerhalb des geplanten Bereichs, sowohl was das Budget als auch die Zeit betrifft.
Das muss nicht sein. Es gibt einige Projektmanagement-Methoden (CMMI, Prince oder PMBoK als Beispiel) die dem Projektleiter Methoden an die Hand geben, um ein Projekt ordentlich zu planen und durchzuführen.

Ich möchte in diesem Artikel eine kleine Einführung in einige wichtige (allgemeine) Aspekte des Projektmanagements geben, dabei beziehe ich mich auf die bewährten Praktiken von CMMI, muss jedoch dazu sagen, dass ich kein zertifizierter CMMI-Spezialist bin. Ich habe die entsprechenden Methodiken und Grundlagen an der Universtät gelernt und möchte anderen, vielleicht Projektleitern die seit Jahren nach demselben Schema arbeiten und sich verbessern wollen einen Einblick in die modernen Grundlagen geben. Das ist vielleicht ein Anreiz/Ansporn für andere sich näher mit dem Thema zu beschäftigen und bessere Projektleiter zu werden!

Ein paar Fakten

Wie oben erwähnt fahren viele Projekte gegen die Wand, weil die Planung nicht stimmt und auch die Probleme oft nicht oder zu spät erkannt werden. Prozesse sind nicht definiert, werden nicht eingehalten und dadurch Probleme nicht erkannt bzw. Aufgaben nicht richtig geplant / kontrolliert.
Die eigentliche Arbeit die zur Herstellung des Produkts dient (z. Bsp. Programmieraufwand), beträgt am Gesamtaufwand des Projekts oft nur ca. 20-30 %. Werden nun für ein Projekt hauptsächlich für die Arbeitspakete die Zeitaufwände berechnet plus einen Wert x (für Testen und andere Dinge) kann das Projekt nur schwer eingehalten werden. Hat nun der Projektleiter eine Schätzung von 5 Mann-Tagen2 vorliegen, so müsste er (um auf den 100% Aufwand zu kommen) den Wert mit ca. 4 multiplizieren. Das heißt es müsste das 4-fache an Aufwand eingeplant werden, als dem Projektleiter vorliegt. Bei 5 Mann-Tagen bedeutet das einen eigentlichen Aufwand von ca. 20 Tagen.

Treten dann noch unvorhergesehene Probleme auf, die der Projektleiter vorher nicht erkannt und dafür keine Lösung parat hat, erhöht sich der Aufwand oft soweit, dass das Projekt schnell rot ist. Ist das Projekt 10% über dem Budget, ist es vermutlich bereits tot. Gleiches gilt, wenn die Werte für die Arbeitspakete (Requirements) sehr ungenau geschätzt sind und das Projekt damit aus dem Rahmen gerät.
Im Nachfolgenden möchte ich einige Methoden und Grundsätze erklären, wie man gut Planen und Schätzen kann. Wie man mit einigen Methoden sein Projekt zum Erfolg und im Problemfall es wieder von gelb auf grün bringt.

Projekt planen

Ein Projektplan ist kein in Microsoft Project zusammengeklickter Plan. Das Programm kann ein sehr hilfreiches Programm sein, aber ist nur ein Teil der Arbeit.
Der Projektleiter muss Personen (allgemein Ressourcen genannt) einplanen. Um zu wissen welche Person er wo einsetzen kann ist es hilfreich sich eine Matrix der Fähigkeiten der Personen anzulegen. Das hilft beim idealen Einsatz der Personen.

Des Weiteren muss eine WBS angelegt werden. Diese resultiert direkt aus den vom Kunden durch das Lastenheft3 definierten Requirements. Diese werden runtergebrochen in Teilaufgaben. Dabei ist wichtig, dass die Arbeitspakete der WBS Ergebnisse sind und keine Aktivitäten (es sollte also geplant werden “Login-Modul” und nicht “Programmieren der Login-Klassen”). Diese Arbeitspakete müssen geschätzt werden vom Zeitaufwand (dazu später mehr). Es kann auch sinnvoll sein in die WBS einen Punkt Projektplanung, Projektabschluss usw. mit aufzunehmen. Ein Arbeitspaket sollte komplett geschätzt werden, inklusive Testen.
Wichtig zur WBS ist noch zu erwähnen, dass man hier auch die Abhängigkeiten verschiedener Pakete planen kann. Zum Beispiel kann ein Login-Modul für die User-Verwaltung und Anmeldung erst geschrieben und getestet werden, wenn die Datenbank fertig ist (Modell, Testdaten usw.). Man kann dann die verschiedenen Requirements als Pakete aufmalen und ihre Abhängigkeiten (zuerst muss A erledigt sein, dann kann B erledigt werden), um eine Struktur zu bekommen. Dann wird auch klar, welche Aufgaben zu erst erledigt werden müssen. Innerhalb eines solchen Netzplans kann dann der so genannte rote Pfad (oder auch kritischer Pfad) markiert werden. Der kritische Pfad ist der, welcher das Projektende nach hinten verschiebt, wenn ein Paket nicht (rechtzeitig) fertig wird. Das bezieht sich vor allem auf die zeitlichen Abhängigkeiten. Dafür kann man FAZ, FEZ, SEZ und SAZ berechnen. FAZ und FEZ ergeben sich aus der Berechnung der Zeiten von vorne nach hinten (Vorwärtsplanung). SAZ und SEZ ergeben sich dabei aus der Berechnung der Zeiten von hinten nach vorne (Rückwärtsplanung). Es gibt Pakete die parallel laufen können, aber es gibt Pakete von denen ist das Endergebnis direkt abhängig und verschieben es bei Problemen (s. roter Pfad in den Beispielbildern zum Netzplan).
Bei einem Netzplan ist auch zu beachten, dass kein Paket für sich alleine steht. Jedes Paket hat einen “Eingang” (quasi ein Vorgängerpaket) bis auf der Start und jedes Paket hat einen Nachfolger (wo die Ergebnisse verwendet werden) bis auf das Endpaket. Der Netzplan sollte also in sich abgeschlossen sein.
Eine ebenfalls schöne Darstellung (oft übersichtlicher, vor allem für kleine Projekte) ist das Gantt-Diagramm. Hierbei handelt es sich um ein Balkendiagramm welches die Pakete und ihren zeitlichen Verlauf visuell darstellt. Das Gantt-Diagramm ist oft eingängiger.
Auf einer Seite von Dr. Ulrich Holzbaur findet sich ein schönes Beispiel mit einem Netzplan und Gantt-Diagrammen. Am Ende in den Quellen noch einige andere Seiten.

Was sind Stakeholder? Stakeholder sind all diejenigen, die vom Projekt betroffen sind. Das sind sowohl die internen Mitarbeiter (andere Abteilungen oder Projektmitarbeiter), als auch externe Personen. Fragestellungen die hier wichtig sind können sein ob eine andere Person (oder Firma) ein Interesse an dem Projekt haben. Wenn man z. Bsp. ein großes Bauvorhaben durchführt, kann es sinnvoll sein Anwohner zu informieren. Muss man ggf. spezielle Maßnahmen treffen? Werden evtl. Gesetze verletzt die wiederum jemand anders zur Anzeige bringen kann?

Zur Planung des Projekts gehört ebenfalls die Risikenbewertung. Gibt es bei der Umsetzung der Aufgabe spezielle Flaschenhälse die evtl. dazu führen könnten, dass das gesamte Projekt stehen bleibt oder gar gefährdet ist? Ist man auf Liefertermine angewiesen und diese könnten evtl. nicht eingehalten werden? Was sind entsprechende Gegenmaßnahmen die ich mir überlegen kann, um eine ggf. auftretende Situation zu verhindern oder abzumildern? Der Projektleiter sollte sich solche Szenarien überlegen. Klar ist jedoch auch, dass niemals im Voraus alle Risiken abgeschätzt und entsprechende Lösungen bestimmt werden können. Aber ein Teil möglicher Risiken lässt sich bestimmen.
Bei Programmierprojekten könnte das bspw. auch ein besonders schwieriges Paket sein. Ein Flaschenhals, der evtl. (bei bestimmter Konstellation) das Projektende gefährdet. Oder ist das Projekt von einer bestimmten Person so abhängig, dass wenn diese krank wird das Projekt ein Problem hat?

Alle diese Punkte zusammengenommen, inklusive der geschätzten Dauer, die Planung, die Mitarbeiter, Ressourcen, Dokumentation, Stakeholder, Milestones usw. usf. ergeben als Ganzes den Projektplan. Auch ein aus der WBS hervorgehendes Pflichtenheft kann zur Kommunikation mit dem Kunden dienen und Teil des Projektplans sein. Für diesen sollte sich der Projektleiter von seinen Mitarbeitern die Zustimmung holen. Dies kann durch verschiedene art geschenen (unterschreiben, durchlesen und mündliche zustimmen). Umso besser die Zustimmung der Mitarbeiter ist, umso mehr identifizieren sich auch die Mitarbeiter mit dem Projekt. Hier ist es auch wieder wichtig, wie weiter unten bei Psychologie erwähnt wird, dass sich der Projektleiter des Wissens seiner Projektmitarbeiter bedient. Für jeden Bereich gibt es Spezialisten, jeder hat seine Meinung und der Projekt leiter sollte auf seine Mitarbeiter hören, dieses Wissen sinnvoll und zielgerichtet einsetzen können, um das Gesamtprojekt mit der Gesamtheit des Wissens seiner Mitarbeiter zum Ziel zu führen. Es kann also durchaus beim Projektplan von einer ganzheitlichen Betrachtung des Projekts und seiner Planung gesprochen werden.

Aufwände und Schätzen

Für die oben genannte WBS muss für die dort aufgeschlüsselten Arbeitspakete der Zeitaufwand geschätzt werden. Hier gibt es in vielen Firmen die Experten-Methode, wo eine Person (oft auch die, die es letztlich programmieren soll) einen Aufwand schätzt und dieser wird aufgeschrieben. Das Problem bei dieser Methode ist, dass nicht jede Person immer alle wichtigen Aufgaben berücksichtigt oder von einer einfachen Möglichkeit (bspw. wiederverwenden von vorhandenem) nichts weiß und dadurch zuviel Aufwand schätzt. Ein Mehr-Augen-Prinzip wäre also sinnvoller. Außerdem birgt diese Methode die Gefahr, dass die Person einfach nicht gut schätzen kann und sich deswegen schlicht verschätzt.

Um das Risiko zu minimieren gibt es eine schöne Methode namens Planning Poker. Diese Methode arbeitet nicht mit fixen Werten und gibt eine feste Werteskala vor, da es nicht so sehr darauf ankommt (im ganzen) ob man nun 6 oder 8 schätzt. Wichtig bei dieser Methode ist: es wird nicht fix geschätzt. Also keine Stunden oder Tage. Es wird relativ zu einem vorher festgelegten Wert geschätzt und das ganze nur in abstrakten “Aufwandspunkten”. Wie man dann zu fixen Zahlen kommt wird nachfolgend beschrieben.
Für diese Methode gibt es sogar extra “Kartenspiele”. Diese kann man sich der Einfachheit halber auch selbst aufmalen. Jeder Schätzer benötigt Karten mit folgenden Werten: Fragezeichen (für “keine Ahnung”), 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 und eine Kaffeetasse (für “Pause”). Wer sich in Mathematik etwas auskennt wird sofort sehen, dass diese Menge die Fibonacci-Zahlen von 1 bis 13 enthält. Bevor man beginnt, sollte auch von jedem Mitschätzer die Bestätigung der WBS eingeholt worden sein. Die Leute müssen wissen was sich hinter den einzelnen Aufgaben verbirgt und die Struktur auch anerkennen, um sinnvoll mitarbeiten zu können.

Der Ablauf funktioniert wie folgt: der “Moderator” (der sich komplett aus der Schätzung bzw. Argumentation zurückzieht) liest ein Arbeitspaket vor. Das erste Arbeitspaket ist ein Referenzpaket, das jedem klar und schnell überschaubar sein sollte. Ein Paket für das man schnell und leicht die Stunden schätzen kann. Dieses Paket belegt man mit dem Wert 5.
Der Moderator liest dann ein Arbeitspaket vor, die Schätzer überlegen und legen dann verdeckt ihren Schätzwert relativ zum Referenzpaket vor. Wenn also das aktuelle Paket schätzungsweise doppelt soviel Aufwand hat wie das Referenzpaket, legt man den Wert 8 (oder 13) hin. Wichtig hierbei ist auch, dass vermieden werden sollte umzurechnen. Der Schätzer sollte nicht in Stunden oder Tage umrechnen und dann vergleichen! Sonst funktioniert das System nicht.
Die Schätzer decken nun alle ihre Karten auf. Der Moderator schaut und die Personen mit besonders niedrigen oder hohen Werten, sollen nun kurz erläutern wieso sie so geschätzt haben. Das führt zum aktiven Austausch in der Gruppe, da eine Person evtl. etwas übersehen hat (eine Vereinfachung oder ein Problem). Dabei ist auch zu beachten, dass das Paket komplett, also Aufwand inklusive Testen und sonstigen Arbeiten (evtl. Planung) geschätzt werden soll. Nach der geschätzten Dauer soll das entsprechende Arbeitspaket vollständig fertig sein.
Wenn die Werte unterschiedlich waren, wird noch einmal geschätzt. Solange bis die Mehrheit der Schätzer denselben Wert hat. Haben bspw. beim zweiten Durchgang zwei Leute den Wert 13 und 4 den Wert 8, dann wird 8 hinter das Paket geschrieben. Sind die Werte zu unterschiedlich, tauscht man sich wieder aus und schätzt noch einmal.

So schätzt man alle Pakete relativ zum Referenzpaket durch. Ist die Gruppe fertig, wird für das leicht überschaubare Referenzpaket ein fixer Wert (z. Bsp. in Stunden oder Mann-Tagen) bestimmt. Zum Beispiel ein Tag (=8 Stunden). Das heißt, 5 Schätzpunkte entsprechen 8 Stunden, damit entspricht ein Aufwandspunkt gleich 1,6 Stunden.
Nun kann mit diesem Wert der Stundenbedarf für alle anderen Arbeitspakete ausgerechnet werden.

Diese Methode bedarf etwas Übung, bis die Gruppe sicher und schnell schätzen kann. Außerdem sollten alle Arbeitspakete die mit Aufwandspunkten beim Schätzen von 20 und mehr geschätzt werden in kleinere Pakete zerlegt (also in diesem Fall die WBS angepasst ) werden. Kein Paket sollte also am Ende mit relativen 20 Punkten oder mehr geschätzt sein!

Milestones

Wie bei dem Gantt-Diagramm (siehe Link oben) zu sehen war, hat das Diagramm bereits einen Milestone-Charakter. Man kann also aus diesem Balkendiagramm Milestones ableiten. Damit erhalten die Projektmitarbeiter auch ein Gefühl dafür, wie weit sie sind.
Milestones sollten bei ihrem Erreichen zu einem Zwischen-Release führen, so dass man eine fertige Arbeitsbasis (in CMMI auch Baseline genannt) hat, zum Weiterarbeiten. Milestones sind also eine gute Methode um den Zustand bzw. Fortschritt des Projekts zu sehen und können dann auch dazu dienen zu entscheiden ob das Projekt denn noch halbwegs im Rahmen läuft.

Psychologische Aspekte und Besprechungen

Die psychologischen Aspekte bei der Projektarbeit werden oft unterschätzt. Die Motivation, die Absichten und das Engagement der Projektmitarbeiter ist von höchster Bedeutung für den Erfolg des Projekts. Dabei ist der Projektleiter derjenige, der dafür verantwortlich ist, dass die Mitarbeiter sich wohl fühlen, den Kopf zum Arbeiten frei haben und motiviert sind. So sollte bspw. auch aus diesem Grund (und weil der Projektleiter die entsprechende Übersicht hat) die Kommunikationskette eingehalten werden. Zum Beispiel sollte der Kunde beim Projektleiter anrufen, nicht beim Mitarbeiter. So kann der Mitarbeiter sich auf sein Arbeitspaket konzentrieren und braucht sich keine Gedanken darüber zu machen ob dem Change Request des Kunden entsprochen werden kann.

Nichtsdestotrotz sollte jedoch der Mitarbeiter genau wissen wo er im Projekt steht. Für die Motivation ist es unerlässlich ein Ziel vor Augen zu haben. Sprich: Jeder Projektmitarbeiter sollte wissen wohin das Projekt läuft, eine Vision haben von dem, was das Endprodukt ist oder wie es sein wird. Ein Maler der ein Motiv auf Leinwand verewigt, schafft eine bessere Arbeit, wenn er eine Vision von seinem Endprodukt hat, wenn er die Szene im Kopf und damit ein Gefühl dafür hat, wohin seine Arbeit geht. Ein Lehrling der drauf los malt, jedoch nicht weiß, wie das fertige Bild aussehen soll, wird es nicht schaffen, eine schöne Szene auf Leinwand zu bannen.
Die Projektmitarbeiter sollten auch durchaus darüber informiert werden (bspw. bei regelmäßigen Besprechungen) was andere tun und welchen Stand andere Arbeitspakete haben. Unter Umständen hat bspw. ein Mitarbeiter eine Abhängigkeit zu seinem Paket entdeckt, die vorher nicht gesehen wurde. So kann er diese in regelmäßigen Besprechungen vortragen und sich mit den Kollegen austauschen.

Projektbesprechungen sollten also regelmäßig mit den Projektmitglieder durchgeführt werden. Bei großen Projekten kann es sinnvoll sein, wenn für Teilgebiete Teilbereichsleiter benannt werden. Dann kann der Projektleiter mit diesen kommunizieren und sich einen Überblick verschaffen. Mitarbeiter aus anderen Teilgebieten können sich dann in eine Besprechung des Teilgebiets dazu setzen und sich so einen stillen Überblick verschaffen. Der Projektleiter sollte auch durchaus zu einzelnen Mitarbeitern gehen, Präsenz zeigen, nachfragen wie das Projekt läuft und sich Rückmeldung der Mitarbeiter einholen.

Grundsätzlich gilt, dass Kommunikation das Mittel der Wahl ist. Es heißt nicht umsonst “wer spricht, dem kann geholfen werden”!
Außerdem ist für den Projektleiter die Besprechung ein Mittel um den Status des Projekts zu erfahren. Schließlich ist er derjenige, der am Ende ausrechnen muss ob die Zeit reicht, muss ggf. den Projektplan anpassen, mit dem Management (Chefs) kommunizieren, ggf. Zahlen, Budget und Fortschritt vorlegen und erklären. Auch er ist derjenige, der entsprechenden Ärger vom Management erhält, falls das Projekt aus dem Ruder läuft oder gar scheitert.
Der Projektleiter sollte also nicht und kann auch gar nicht alles selbst durchdenken oder erarbeiten. Er sollte wissen wo in seinem Team die Kompetenzen liegen und wer was kann und sollte diese Kompetenzen und das Wissen sinnvoll nutzen. Ein Projektleiter der sich als Spezialist in allen Bereichen sieht und lieber alles selbst plant und vorschreibt, als seine Mitarbeiter zu führen und ihnen Verantwortung zu übertragen, handelt nicht sinnvoll!

Quellen und weiterführende Informationen (ohne Anspruch auf Vollständigkeit)

Projektmagazin zum Thema Visualisierung von Projektplänen
CMMI-Browser
CMMI-Prozess-Poster
Agile and CMMI: Better Together @ scrumalliance.org
Linksammlung mit interessanten CMMI-Artikeln
Zusammenstellung von freien und interessnaten Projekt-/Zeit-Management Tools
Artikel über freie Projekt Management Software
Planning-Poker
Karte der Veränderung
Freies Gantt-Diagramm-Tool
Klassenarbeit mit Netzplan, FAZ, FEZ, SAZ und SEZ

Fußnoten

  1. vom Projekt irgendwie betroffene – sowohl die Mitarbeiter als auch externe []
  2. ein Mann-Tag entspricht einem 8 Stunden Werktag []
  3. eine detaillierte Erläuterung was das Produkt am Ende können soll []

2 Responses to “Projektmanagement – eine Einführung”


Leave a Reply

*

Januar 2009
M D M D F S S
« Dez   Feb »
 1234
567891011
12131415161718
19202122232425
262728293031  

Beste Bewertung

QR Code

qr code

QR code created by QR code Widget


Wikio - Top Blog
Blogverzeichnis - Blog Verzeichnis bloggerei.de
blogoscoop
BlogPingR.de - Blog Ping-Dienst, Blogmonitor
Creative Commons Lizenzvertrag