Was ist Scope Creep?

Während der Entwicklungsphase eines IT-Projekts können aufgrund technologischer Entwicklungen, einer unzureichenden Planungsphase oder sich verändernder Wettbewerbsbedingungen neue oder zusätzliche Anforderungen entstehen. Wenn solche Änderungen nicht über einen formellen Änderungsantrag in das Projekt eingebracht werden, sondern nur über informelle Vereinbarungen oder „schnelle Gefälligkeiten“ (Ference, 2015, S.18), kann es zu einem unkontrollierten Anwachsen des Projektumfangs kommen. Die Folgen sind ebenso unkontrollierbare Kostensteigerungen, Zeitverzug, entstehende konkurrierende parallele Strategien und damit einhergehend Funktionszuwächse die für das eigentliche Projektziel weniger relevant sind.  Dieses Phänomen wird als Scope Creep bezeichnet.

Die Ursachen von Scope Creep

Scope Creep erklärt

Nach Schiff (2017) sind die Gründe für Scope Creep vielfältig und umfassen u.a.

  • unzureichende oder informelle Kommunikation mit dem Kunden,

  • keine oder zu wenige Meetings,

  • keine Priorisierung von Projekten und Aufgaben,

  • kein Projektstrukturplan / Scope Management.

Ausgehend von Teye Amoatey (2017) gewinnt das Scope Creep zunehmend an Bedeutung,

  • je länger die Dauer des Projekts ist,

  • je schneller das Tempo des technologischen Fortschritts in der Industrie ist,

  • je ungenauer die Spezifikation und die Akzeptanzkriterien definiert sind.

Zudem führt auch eine unzureichende Priorisierung, Strategiefokussierung, Ziel- und Anforderungsdefinition zu Scope Creep. Beispielsweise stellen während eines laufenden IT-Projektes häufig auch andere, nicht beteiligte Abteilungen zur Verfolgung ihrer eigenen Ziele Anforderungen an das IT-Projekt.

Es bestehen also häufig funktionale Silos innerhalb eines Unternehmens die unterschiedliche Strategien zur Erreichung unterschiedlicher Ziele haben. Hierdurch kann es zu unterschiedlichen Anforderungen kommen und damit zu einem unkontrollierten Anforderungszuwachs bei einem IT-Projekt.

Ziele, Anforderungen und Verantwortlichkeiten müssen daher zu Beginn eines Projektes erhoben, der Umfang definiert und zudem validiert werden. Darüber hinaus muss die Verantwortung des Projektleiters klar und offiziell kommuniziert werden. Das klingt naheliegend, aber in der Praxis ist oft zu beobachten, dass höherrangige Manager in der Hierarchie ihre Macht nutzen, um Einfluss auf das Projekt zu nehmen, auch wenn das eigentliche Projekt für ganz andere Ziele und Bereiche konzipiert wurde.

Maßnahmen gegen Scope Creep im Überblick

  • Genaue und formale Festlegung und Spezifikation der Anforderungen vor Projektbeginn (Schwalbe, 2015).

  • Einführung eines formalen Änderungsmanagements (Teller et al., 2012). So kann zum Beispiel jede Änderungsanforderung auf Kosten und Zeitplan durch die Einrichtung eines Change Control Board evaluiert werden.

  • Konsequentes Konfigurationsmanagement (Verner et al., 2014)

  • Mit Hilfe von Projektsoftware können Möglichkeiten zur Erweiterung des Projektumfangs identifiziert und evaluiert werden. Auch der Projektstatus kann mit den Projektmitgliedern geteilt werden.

  • Langfristiges Ideen- und Innovationsmanagement zur Sammlung von Verbesserungsvorschlägen.

Quellen

  • Ference, S. (2015) Don’t let scope creep lead you out of bounds. Journal Of Accountancy, 220 (3), pp. 18-19.

  • Schiff, J. (2017) 8 common project management mistakes – and how to avoid them. Cio, p. 1.

  • Schwalbe, K. (2015) Information Technology Project Management. 8th ed. Boston: Cengage Learning.

  • Teller, J., Unger, B., Kock, A. & Gemünden, H. (2012) Formalization of project portfolio management: The moderating role of project portfolio complexity. International Journal of Project Management, 30 (5), pp. 596-607.

  • Teye Amoatey, C. (2017) Investigating the major causes of scope creep in real estate construction projects in Ghana. Journal of facilities management, 15 (4), pp. 393-408.

  • Verner, J., Brereton, O., Kitchenham, B., Turner, M. & Niazi, M. (2014) Risks and risk mitigation in global software development: A tertiary study. Information and Software Technology, 56 (1), pp. 54-78.