Projektmanagmenet Kapitel 4. Projektrisiken

Gemäss Lehrer wird unter Projektrisiko die Höhe des Schadens verstanden, den ein Unternehmen erleidet, wenn die Projektziele nicht erreicht werden.

1. Restriktionen ( Umwelt / Technik / IT-Vorgaben)

2. Projektbedingungen ( Zeit / Budget / Projektmngmt )

3. Anwenderbedingungen (soziales Verhalten / Verfügbarkeit)

4. Produktbedingungen ( Modularität  / Komplexität )

5. Firmenbedingungen ( Leitbild / Richtlinien / IT-Umfeld)

6. Entwicklungsbedingungen ( Entw. Basis / Prüfverfahren )

1. Die „prometheische“ Selbstüberschätzung
- Ziele viel zu hoch
- verliert frühzeitig die Motivation
- keine klare Rangordnung

2. Man weiss nicht, was man eigentlich will
- Unklarheit der Zielsetzung
- Gefahr, Unvereinbares unter einen Hut bringen zu wollen

3. Unrealistische Leistungszusage in der Vorprojektphase
- Hard Seller von IT-Projekten

4. Unterschätzen der Komplexität der Aufgabenstellung
- Versuch, anschliessend neue Lösungsansätze dem bestehenden Konzept Aufzudrücken

5. Fehlende Normen und Standards für Analyse und Programmierung
- fehlende Kalkulationsunterlagen

6. Mangelnde bzw. fehlende Dokumentation des abzulösenden Systems
-bei Wunsch, in Teilbereichen auf bestehende Aspekte aufzusetzen

7. Ungenügend strukturierte Projektorganisation
- unklare Aufgabenzuweisungen
- uneinheitliche / unklare Ergebnispräsentation

8. Qualifikation der Projektmitarbeiter
- ausreichende Fachkenntnisse werden stillschweigend erwartet
- fachliche Verständnisschwierigkeiten führen zu Vertrauen-/Akzeptanzhürden

9. Die Illusion des Maurerdreisatzes
-Eine Verdoppelung der Projektmitarbeiter führt nicht zu einer Halbierung der Projektlaufzeit.

10. Fehlende Motivation des Projektteams
-einengender Methodenzwang
-lange Laufzeiten beeinträchtigen die Euphorie der Fachpromotoren

11. Mangelnde Standfestigkeit gegenüber dem Erwartungsdruck des Anwenders
-Zusagen zu übertriebenen Erwartungshaltung führen zu Nichteinhaltung des Projekts

12. Diskontinuität in der Projektdetaillierung
- verschiede Projektmitarbeiter können verschiedene Detaillierungsstufen wählen, was zu Diskontinuitäten der Subsysteme führen kann

13. Nichteinfrieren der Projektspezifikation
- oft in Prototyping anzutreffen
- Wege eines Change-Managements sind einzuhalten

14. Nichteinhalten des festgelegten Phasenplans
- Eintritt in eine neue Phase ohne Abschluss (Abnahme des Ergebnisses) der Vorphase

15. Wider den Methodenzwang
- „kreativ“ denkende Programmierer können die vorgegebenen Methoden umgehen
- Methoden werden lieber diskutiert, als angewandt
 

16. Fehlende Software-Werkzeuge
-Tools werden oft zu Unrecht übertrieben kritisiert und abgelehnt

17. Mangelhaftes Datendesign
- das Datendesign wird evtl. mehrere Generationen der Software überdauern

18. Unterschätzen der softwaretechnischen Sicherheitsaspekte
- Fehlen einer nachvollziehbaren Qualitätsscherung

19. Nicht verbindlich festgelegte Abnahmeprozedere
- wiederholtes Problem der Kommunikation zwischen Anwender und Entwickler

20. Fehlender Durchgriff auf die Organisationsentwicklung
-Effizienzsteigerungen bzw. Erweiterungen der Dienstleistungen erfordern Anpassungen in Auf- und Ablauforganisation

- risiken erkannt man nicht automatisch. Sie müssen aktiv identifiziert und diskutiert werden.

- Risikoanalyse muss zu beginn erfolgen. Aber während dem Projektverlauf ist ein Risiko-Review durchzuführen.

1. Suche nach potentiellen Problemen

2. Gewichtung der potentiellen Probleme hinsichltich ihrer Eintrittswahrscheinlchkeit und Tragweite

3. Identifikation und Umgehung wahrscheinlicher Ursachen

4. Massnahmen zur Schadensminimierung definieren, falls die Ursachen nicht umgangen werden können.

- dedizierte Meeting zu Risikoidentifikation

- erkennbare Risiken bereits im Projektauftrag erwähnen

- korrekte Aufbereitung von Entscheidungsunterlagen

-Auftraggeber

-Sponsoren

-künftige Anwender

Vorgehensart

Systemdenken

Richtlinien zur Dokumentation

Softwareinstrumente wie MS-Projekt

e-Collaboration oder Sharepoint