Wichtige Risiken und Probleme in IT-Projekten

In diesem Artikel beschäftige ich mich mit der Aufzählung von wichtigen Risiken und Problemen in IT-Projekten, die in der Praxis auftreten können. Diese Aufzählung ist nicht abschließend. Sie kann neuen IT-Projekten als Hilfsmittel dienen, um für diese Risiken sensibilisiert zu sein.

 

In einem V-Modell XT Bund Projekt dient eine Risikoliste dazu, um Risiken möglichst frühzeitig zu identifizieren und auf diese proaktiv zu reagieren, damit diese nicht zum Problem für das Projekt werden können. Dazu wird jedem Risiko eine Gegenmaßnahme zugeordnet. Dazu dient eine entsprechende EXCEL-Vorlage (Risikoliste).

Projektrisiken in IT-Projekten

1. Resourcenproblem

  • Das Fachkonzeptteam hat zu wenig Ressourcen, um das während dem Projektverlauf erforderliche Änderungsmanagement durchzuführen, welches zum Kern den V-Modell XT gehört.
  • Es werden Lizenzkosten im Projektbudget nicht einkalkuliert.
  • Es sind nicht genügend Entwickler vorhanden, um die Programmierung im angestrebten Zeitraumen umzusetzten.

2. Austausch von Personal

  • Es werden Fachexperten während dem Projektverlauf ausgetauscht.
  • Dadurch geht Expertenwissen verloren, was insbes. bei nicht dokumentierter Software schädlich ist.

3. Einsatz von neuen Tools

  • Es werden neue Tools bzw. Toolketten eingesetzt, zu denen die Projektmitglieder keine Erfahrung haben bzw. zu denen generell noch keine Erfahrungswerte vorliegen.
  • Die Projektmitglieder werden nicht ausreichend geschult.
  • Die Projektmitglieder sind überfordert bzw. haben noch keine Prozesse zum effizienten Einsatz der Tool implementiert.

4. Einsatz von neuartigen Entwicklungsmethoden / Systemarchitekturen

  • Es werden Entwicklungsmethoden eingesetzt, zu denen noch keine Erfahrungswerte vorliegen.
  • Es werden Systemarchitekturen aus Fertigprodukten aufgebaut, die bisher noch nicht verwendet worden sind.
  • Es werden neuartige Systemarchitekturen z.B. SOA eingesetzt.

5. Änderungen in zentralen Komponenten

  • Es werden Änderungen in zentralen Komponenten (insbes. monolithische Systeme) durchgeführt, die in unterschiedlichsten und nicht genau identifizierbaren Teilen der Software (gerade bei Altsystemen) Abhängigkeiten haben.

6. Kommunikation

  • Probleme im Projekt werden nicht offen angesprochen, obwohl bereits Auswirkungen in bestimmten Teams zu bemerken sind.
  • Festgestellte Inkonsistenzen im Fachkonzept werden nicht an die Fachseite weitergegeben.
  • Probleme bei der Programmierung werden zu lange nicht offengelegt.

7. Fehlende Produkte

8. Fehlende Managementmechanismen

  • Es fehlt ein dokumentiertes Änderungsmanagement, wodurch Änderungen an Produkten, auf die andere Projektmitglieder aufbauen, nicht im Projekt kommuniziert werden.

 

Liebe Leser, wenn ihr noch weitere Vorschläge habt, könnt ihr mir die gerne in den Kommentaren schreiben, damit ich den Risikokatalog ergänzen kann!

Schreibe einen Kommentar

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


*