Risiko Nr. 11 Verändernde Anforderungen

Kategorie und Projektphase

Phasenueberblick

Risikosatz

Aus der Unwissenheit der Projektbeteiligten, einer veränderten Zielsetzung, unternehmenspolitischen Änderungen oder einer mangelnden Anforderungsqualität könnte es zu verändernden Anforderungen (neudeutsch: „requirements drift“) kommen, die den Projektfortschritt im Zeit- und Budgetrahmen in vielfacher Weise in Frage stellen.

Risikobeschreibung

Da es eine zentrale Eigenschaft von Softwareprojekten ist während der Projektlaufzeit Wissen zu akquirieren, werden bestehende Anforderungen laufend reflektiert und auch nachträglich angepasst. Dieses Risiko gehört zu den Top-Risiken von Softwareprojekten.
  • Eine amerikanische Studie stellt fest, dass sich pro Monat 1% der Anforderungen ändern. Dies bedeutet bei einer Projektlaufzeit von 36 Monaten, dass sich mehr als 33% aller Anforderungen in dieser Zeit geändert haben werden.
  • Eine spezielle Ausprägung dieses Risikos ist die Änderung grundlegender Anforderungen, die oft auf eine geänderte Zielsetzung zurückzuführen ist und besonders stark den Projekterfolg bedrohen.

Indikatoren

  • Sie entwickeln eine Software für viele, gegebenenfalls sogar stark unterschiedliche Anspruchsgruppen, die unterschiedliche Zielsetzungen verfolgen.
  • Während der Laufzeit des Projektes kommen neue Anspruchsgruppen hinzu, die Anforderungen stellen.
  • Die Zielsetzung des Projektes wird schleichend oder prompt verändert.
  • Die Analysephase dauert sehr lange, ist umfangreich oder komplex und es sind wenige Fortschritte zu erkennen.
  • Das Ende der Analysephase wird immer wieder verschoben.
  • Der Benutzer wird bei der Aufnahme der funktionalen Anforderungen nicht eingebunden.

Risikomatrix und das magische Viereck

Risikomatrix

Maßnahmen

Für dieses Risiko kann zwischen kurz- und langfristigen Maßnahmen unterschieden werden. Zunächst die langfristigen:

  • Changemanagement: Etablieren Sie einen geregelten Prozess, wie Änderungen eingebracht werden, wie diese für die Implementierung beschrieben werden, wie diese implementiert werden und wie die Änderungen in die Projektdokumentation nachgetragen werden.
  • Anforderungsmanagement: Aufgenommene Änderungen sollten priorisiert, in den Kategorien Risiko und Nutzen bewertet werden und bis zur Auslieferung durchgängig nachverfolgt werden.
  • Projektziele aktiv managen: Überprüfung und aktive Änderung der Projektziele zusammen mit dem Auftraggeber/den Anspruchsgruppen. Im gleichen Zug die Budget- und Zeitplanungen anpassen, denn verschiebt sich der Fokus des Projektes, hat dies Anforderungsänderungen oder eine Anforderungsexplosion zur Folge.
  • Stakeholdermanagement: Pflege der Beziehungen zu den Anspruchsgruppen eines Projektes und Berücksichtigung ihrer Zielsetzung für die Projektplanung.
  • Inkrementelles und iteratives Vorgehensmodell wählen. Pro Iteration entsteht eine Programmversion, die jeweils eigenständig geplant werden sollte. Dazu gehören Zeitplan, Auslieferung, enthaltende Anforderungen etc.
  • Vertragsgestaltung, die grundlegende Zielsetzung oder Anforderungen bzw. die Unterstützung eines entsprechenden Changemanagementprozesses umfasst.
  • Die Projektkalkulation sollte einen Puffer für die Anforderungsänderungen enthalten (nehmen Sie nicht 0%, wie früher, sondern 1% pro Monat an).

Kurzfristige Maßnahmen:

  • Den Auftraggeber und das eigene Management wiederholt darauf hinweisen, dass es erfolgskritisch ist, dass die grundlegenden Anforderungen stabil bleiben (vgl. Kapitel 3.4.4 unter „Lernen Sie von den Erfolgsfaktoren anderer Projekte“).
  • Eine ständige Validierung durchführen: Wird das richtige Produkt für die Benutzer geschaffen?
  • Die Zielsetzung prüfen: Stimmt die Zielsetzung noch?
  • Die wirklichen Benutzer des Systems frühzeitig einbinden. Nicht nur Mitarbeiter des Auftraggebers, denn beide Gruppen können sich stark unterscheiden.
  • Prototypen erstellen und zusammen mit Benutzer und Auftraggeber überprüfen.
  • Bereits vor der Implementierung ein Benutzerhandbuch erstellen und es von Benutzern abnehmen lassen und Feedback einholen.
  • Strukturierte Anforderungsanalyse durchführen: Methoden einsetzen (Interviewtechniken, Workshops), Anwendungsfälle analysieren, Geschäftsprozesse analysieren.
  • Meilensteine trotz umfangreicher Änderungsanträge versuchen zu halten, indem Änderungen auf die Folgeversion geschoben werden.
  • Die Iterationen des Vorgehensmodells verkürzen, so können die Änderungen schneller adaptiert werden.
  • Den Umfang einer Version begrenzen (auf dem Anforderungsbasar mitmischen, um Budget und Zeitplan zu halten): Wenn Anforderung B kommen soll, kann Anforderung A nicht mehr umgesetzt werden. Hierzu müssen akkurate Umfangsschätzungen vorliegen.
  • Mit dem Auftraggeber möglichst auf Win-Win-Basis verhandeln.

Eskalation: Grundsatzentscheidungen herbeiführen und schwelende Konflikte zwischen Anspruchsgruppen nicht unterdrücken.

Beziehungen

Beziehungen zu Vorgängerrisiken und Nachfolgerrisiken

Identifizieren und Überwachen

  • Endecker: Projektleiter, Steuerkreis, Anforderungsmanager, Systemanalytiker
  • Überwacher: Projektleiter, Anforderungsmanager, Systemanalytiker