Projektmanagement und
Produktqualität

Risikomanagement im Projekt

Der zentrale Punkt zur erfolgreiche Beendigung eines Software-Projektes ist ein gutes Projektmanagement. Gutes Projektmanagement bedeutet im wesentlichen die fünf universellen Managementfunktionen - Planung, Organisation, Staffing, Leitung, Kontrolle - so effizient einzusetzen, das die Projektziele in "time & money"erreicht werden.
Es ist nicht möglich, auf alle Aspekte einzugehen, ohne ein mehrere hundert Seiten starkes Buch zu schreiben. Die Session beschäftigt sich daher im wesentlichen mit dem "Risikomanagement" eines Projektes.

Warum scheitern Softwareprojekte ?

Einer Statistik zufolge, die 1995 von der Standish Group veröffentlicht wurde, sind nur

• 9 % aller größeren und 16%-28% aller kleinen bis mittleren Softwareprojekte in "time & money" abgewickelt worden.
  

• 53% aller Projekte hatten nach Beendigung eine Budgetüberschreitung von über 50%
  

• 31% aller Softwareprojekte wurden ohne verwertbares Ergebnis abgebrochen

1995 haben allein die amerikanischen Unternehmen 81 Milliarden Dollar in nicht beendete Softwareprojekte investiert

Es existiert eine wohl endlose Liste von Gründen, die direkt oder indirekt für das Scheitern oder ‚beinahe' Scheitern eines Softwareprojektes verantwortlich sind - jeder Projektleiter kann wahrscheinlich Bücher damit füllen. Meistens lassen sich allerdings die projektspezifischen Gründe wie folgt generalisieren :

1. unklare Anforderungen
   

2. Mitarbeitereinflüsse wurden falsch bewertet
   

3. Top-10-Metriken für industrielle Softwareentwicklung wurden nicht beachtet
   

4. fehlendes Prozessmodell
   

5. hohe Dokumentenorientierung
   

6. "Late design Breakage" (zu späte Integration)
   

7.  mangelhafte Kommunikation
   

8. fehlende Qualitätssicherung

Insbesondere bei kleineren bis mittleren Projekten existieren die Ursachen für das Scheitern eines Projektes schon vor der Auftragsannahme, insbesondere indem man, durch den Auftrag verleitet, die Projekt - Risiken bewusst oder unbewusst falsch bewertet.

Software-Projekt = Hausbau ?

Häufig wird das Management eines Softwareprojektes mit z.B. der Bauleitung eines Einfamilienhauses verglichen - ein größeres Projekt würde man dann beispielsweise mit der Oberbauleitung am "Frankfurter Flughafen" vergleichen.
Diese Vergleiche stimmen nicht, denn Softwareprojekte unterscheiden sich von reinen Produktionsprozessen wie folgt :

1. Niedriger Grad an Normierung mit gleichzeitig hohem Grad an Abstraktion ( Sneed 87 ) 
   

2. Der PM ist fast ausschliesslich auf die Aussagen seiner Mitarbeiter angewiesen, denn es fehlen einfache Kontrollmittel
   

3. Erkenntnisse während der Projektphasen haben auch Auswirkungen auf bereits ‚fertige' Ergebnisse
   

4. der Softwareentwicklung liegen keine Naturgesetze zugrunde
   

5. Projektmanagement in der Softwareindustrie hat keine ‚gewachsene' Historie
   

6. Begrenzte Austauschbarkeit der Mitarbeiter ( Sneed 87 )

Ist ein Projektmanager von Managementideen geprägt, die aus Produktionsprozessen stammen, trägt er meist den Besonderheiten eine Softwareprojektes nicht Rechnung.

Prozessmodelle

Das Prozessmodell ist das einem Projekt zugrunde liegende Konzept. Fehlt dieses, so ist das gesamte Vorgehen planlos und risikoreich. Um in der überstrapazierten ( und falschen ) Analogie zum Hausbau zu bleiben, ist das so, als würde man ein Einfamilienhausbau ohne Plan, ohne Konzept und mit zeitnaher kurzfristiger Planung etc. betreiben. Während jeder die Notwendigkeit eines Konzepts, Plans, Bauleiters bei dem eigenen Hausbau einsieht ist, das im Softwarebusiness leider immer noch nicht selbstverständlich.
Ein Prozeßmodell wird auch als Vorgehensmodell bezeichnet, es steckt einen organisatorischen Rahmen fest. Das Grundmodell aus den Anfangsjahren hatte ausschliesslich zwei Schritte ( Boehm 88 ):

1. Implementation

2. Fehlererkennung und -beseitigung

Ausgehend von diesem im Laufe der Zeit als unzureichend erkannten Grundmodell ergaben sich u.a. folgende Modelle:

1. Wasserfallmodell
   

2. V-Modell
   

3. Spiralmodell
   

4. Prototypenmodell
   

5. Rational - unified - Process
   

6. Evolutionäres/inkrementelles Modell
   

7. nebenläufiges Modell
   

8. ...

Keiner käme auf die Idee, ein Prozessmodell zur Implementation einer "FOR ... TO" Schleife aufzusetzten. Auch in einem sehr kleinen Projekt kann die Einführung eines Prozessmodells eher kontraproduktiv sein.

Es kann im Einzelfall durchaus sinnvoll sein, einzelne Prozeß-Modelle miteinander zu kombinieren.
Risikomanagement

Die Risikoliste ist ein effizientes Mittel zur Messung eines Projektes. Je weiter das Projekt bisher gekommen ist, um so weniger Risiken sollten auf Ihrer Liste zu finden sein.
Leider erkennen viele Manager nicht, wo die Risiken in ihrem Projekt liegen, daher werden häufig Ressourcen auf ‚Nebenkriegsschauplätzten' gebunden, oder man versucht, Folgen und nicht Ursachen zu beheben.
Risiken müssen daher in einem Projekt erkannt werden, bevor sie zu einem Problem werden. Einigen Untersuchungen zufolge wird im sog. ‚rework' das meiste Geld ausgegeben. Das Risikomanagement besteht aus 6 Schritten (Boehm 91):

1. Risikoidentifizierung
   

2. Risikoanalyse
   

3. Risikopriorisierung
   

4. Risikomanagement
   

5. Risikoüberwindung
   

6. Risikoüberwachung

Risikoidentifizierung

Betrachtet man die Risiken im Einzelnen, so identifiziert man folgende Hauptgruppen :

1. technische Risiken
   

2. fachliche Risiken
   

3. Ressourcen - Risiken

Für welche Risiken Sie verantwortlich sind, bestimmt wesentlich der Projektvertrag. Hierbei ist es notwendig, dass Sie nur von Ihrer Firma "abwägbare" Risiken übernehmen ( am besten natürlich gar keine ). Jeder Kunde erstrebt letztendlich, die Projektrisiken auf Fremdunternehmen "abzuwälzen", häufig geht der Auftragnehmer, z.B. weil er den Auftrag "braucht", bewusst auf dieses Spiel ein und schafft damit ein unübersehbares Risiko für sich und seine Firma.
Unabhängig davon, wer für die Risiken "juristisch" verantwortlich ist, müssen diese in einem Projekt verwaltet und "gemanaged" werden. Dies erfolgt in der Rolle des "Risikomanagers". Projektmanager und Risikomanager sollten sich konstruktiv ergänzen, was bedeutet, dass ein Projektmanager mit technischen Stärken einen Risikomanager mit eher fachlichen Qualitäten neben sich haben sollte. In größeren Projekten sollten die Rollen nie in Personalunion besetzt sein. 
Dem Risikomanager stehen im wesentlichen folgende Strategien zur Verfügung :

1. Risikoakzeptierung
   

2. Risikovermeidung
   

3. Risikoübertragung

In der Praxis findet man meist eine Kombination aus den oben genannten Strategien.

Risikoanalyse

Die Risikoanalyse ordnet ein identifiziertes Risiko im Gesamtzusammenhang mit anderen Risiken ein und bewertet die Risiken nach Risikoeintrittswahrscheinlichkeit und Risikoschwere.
Risikoschwere und Risikoeintrittswahrscheinlichkeit können nicht objektiv gemessen werden, sie obliegen der Einschätzung der Projektbeteiligten. Da Sie nicht empirisch messbar sind, macht nur eine grobe Einstufung in max. 5-6 "Schweregrade" Sinn. Hierzu ein Beispiel :
Risikoschwere : 1-6, wobei 6 für Projektabbruch steht.
Risikoeintrittswahrscheinlichkeit : 1-6, wobei 6 für außerordentlich wahrscheinlich steht.
Manche Einstufungen können nicht genau vorgenommen werden. Dies ist beispielsweise in einem frühen Projektstadium häufiger der Fall, sodass auch Einstufungen 1-3, 1-2, 5-6 etc. möglich sind. 
Aus Risikoschwere und Risikoeintrittswahrscheinlichkeit ermittelt man den "Risikofaktor" durch Multiplikation. Dieser spiegelt den Schweregrad des Risikos wieder. 
Sollte in der sich so ergebenden Risikomatrix ein Risikofaktor >=30 berechnet werden, so lassen Sie die Risikoanalyse gegenprüfen. Sollte nach Prüfung weiterhin der Risikofaktor derart hoch liegen und der Ausgang des Projektes Ihr Unternehmen stark beeinflussen ("unternehmenskritischer Faktor"), so sollten Sie Abstand von dem Projekt nehmen. Machen Sie immer eine "worst case" Betrachtung.
Addieren Sie nun die Risikofaktoren innerhalb der Gruppierungshierarchie und dividieren Sie diese durch die Anzahl der Risiken, dann erhalten Sie den Risikofaktor für die jeweilige Risikohierarchiestufe. So auch für die Risikohauptgruppen ( technisch, fachlich, Ressourcen, etc. ). 
Machen Sie sich klar, das die Risikomatrix nach der Erstellung nach jeder Iteration gepflegt werden muss.

Risikopriorisierung

Alle Risiken müssen priorisiert werden. Das geschieht wiederum durch Einstufung der Risiken in Prioritätsklassen von beispielsweise 1-6. Normalerweise gibt allerdings die Risikoschwere bereits ein Maß für die Risikopriorisierung vor.

Risiokmanagementplanung

Nachdem die "Hauptrisiken" identifiziert wurden, müssen geeignete Schritte aufgestellt werden, das Risiko zu "managen". Es müssen Maßnahmen aufgesetzt werden, die notwendig sind, das Risiko zu beseitigen. In unserem Beispiel "RAM reicht nicht aus" mit einem Risikofaktor von 36 (!!) müssen Sie mit dem Kunden reden, um eine Lösung des Problems herbeizuführen. Geeignete Gegenmaßnahme wäre in diesem Fall die Zustimmung des Kunden zur Erhöhung des RAMs
Diese Aktivitäten müssen in den "Master-Plan" eingepflegt werden.

Change Management

Vielen Kunden fällt erst nach Unterschrift des Projektvertrages - oder noch später - auf, dass etwas "fehlt" oder eine Funktionalität dringend zusätzlich implementiert werden muss. Es ist daher stark zu empfehlen, ein wirksames "Changemanagement" zu etablieren. 

1. Formales Vorgehen muss Bestandteil des Projektvertrages sein
   

2. Verantwortliche müssen genannt werden
   

3. Folgen müssen definiert werden
   

4. ...

Schlussbetrachtung

Das "Risikomanagement" ist ein zentraler Bestandteil eines Projektes. Ein Risiko, das nicht oder zu spät erkannt wird, kann viel Geld und Nerven kosten. Die Session soll nicht den Eindruck erwecken, alles Wesentliche zum Projektmanagement gesagt zu haben. Natürlich sind "MPM - Netzpläne", "Businesspläne", "Personalpläne" etc., etc. ebenfalls für ein Projekt entscheidend. Die wesentlichen Faktoren, die zum Scheitern eines Projektes führen, sind meist ein fehlendes "Risiko-, Change- und Qualitätsmanagement".