Das Ende von „Scope Creep“?

Heute ist mir in einem Projekt der Kragen geplatzt. Der Change Management Prozess wird einfach ignoriert und letztlich fällt nun rework an da Mitarbeiter in unterschiedliche Richtungen begonnen haben zu realisieren. Nun stellt sich natürlich als erstes die Frage warum dies so ist. Es gibt ein umfangreiches Project Change Request Template und alle haben zugesagt, den Prozess zu nutzen. Nur in der Praxis hat es einfach nicht funktioniert.

Letztlich ist viel Arbeit der Projektmanager damit verloren gegangen, untergeschobene Changes in neuen Dokumenten und Kommunikation an den regulären Kanälen vorbei einzufangen und einer Bewertung zuzuführen. Tom Mertron schlägt im Blog Better Projects vor, den Begriff Scope Creep zu ersetzen. Er hat eine viel zu negative Konnotation da er mit dem Bild eines Projektmanagers verbunden ist, der alle Change Requests ablehnt.

Zum Tom’s Frage nach einem Ersatzbegriff würde ich einfach Scope Management vorschlagen im Sinne eine kontrollierten Änderung des Scopes. Im betroffenen Projekt haben wir viele Änderungen umgesetzt, die dem Kunden nutzen und den Aufwand bzw. die Komplexität reduzieren. Einige aufwandstreibende Changes sind ebenfalls angenommen worden, da sonst das Produkt schlecht am Markt plazierbar ist.

Des Pudel’s Kern scheint nach erster Betrachtung das Gewicht des Change Management Prozesses zu sein. Changes müssen von einem hohen Management-Gremium genehmigt werden, welches sich aus meiner Sicht eher Major Changes annehmen sollte, d.h. erheblichen Abweichungen des Scopes, die eine komplette Neubewertung des Projekts erfordern. Eine leichtgewichtige Vereinbarung für kleinere Änderungen scheint noch zu fehlen und so regiert die Keksconnection, d.h. der interne Kunde redet lieber gleich mit den Entwicklern.

Die nächsten Wochen werden zeigen, was die Analyse der Ist-Situation ergibt und was für ein gemeinsamer Weg zwischen Produktmanagern und Projektmanagern gefunden wird, um den Scope eines Projekts kontinuierlich weiterzuentwickeln. Es ist unrealistisch zu glauben, dass bei Software- und Internetprojekten der Scope wirklich vorher komplett festgeschrieben werden kann. Aber eine bewusste Steuerung von Änderungen ist unabdingbar.

4 Responses to Das Ende von „Scope Creep“?

  1. Karl-Wilhelm von Rotenhan sagt:

    Ach ja.. Es gibt da einen einfachen Merksatz:
    „Lieber richtig Krach am Anfang als „Gegrummel“ ohne Ende.“
    Aushalten muss man als Projektleider beides können wollen. 😉

  2. Ich sehe, dass ich erfolgreich in ein Wespennest gestochen habe 🙂 Das Projekt befindet sich in der glücklichen Situation wohlformulierte Requirements mit einer vom Management und vom Team abgenommenen Baseline vorweisen zu können. Die permanent eingesteuerten Änderungen lassen sich jedoch aufgrund ihrer Quelle nicht auf direktem Wege einfangen. Die angesprochenen Empfehlungen und lessons learned sind bereits bekannt und berücksichtigt.

    Als Berater bin ich in der angenehmen Lage die Situation von außen betrachten zu können und hier aufgrund den im Projekt auftretenden Symptomen sowohl das Projekt auf Kurs zu halten als auch organisatorische Veränderungsprozesse initiieren und mitgestalten zu können, die für die zukünftige Zusammenarbeit wesentlich sind. Die Projekte werden übrigends in diesem Kontext immer in der gleichen Weise mit häufig den gleichen Stakeholdern abgewickelt, deshalb lohnt sich der Blick über den Tellerand hin zu organisatorischen Veränderungen.

    Allgemein zu meinen Postings: Das Blog wird nicht nur von alten Hasen gelesen und so schreibe ich Postings wie dieses als Anreißer für Diskussionen und freue mich über die hervorragenden Kommentare. D.h. Situationen sind häufig vereinfacht und pointiert dargestellt sowie ein Stück weit abstrahiert, wenn es sich wie hier um ein reales Projekt handelt. Ziel ist immer wieder die wesentlichen Punkte aufzuzeigen und interessierten Projektleitern mit auf den Weg zu geben.

    Gerne schreibe ich auf sehr hohem Niveau, allerdings sind die meisten Leser des Blogs daran weniger interessiert. So versuche ich eine geeignete Mischung von Postings für Alle zu bieten und die Highlights unter dem „Best of“-Feed zusätzlich zu publizieren.

    In diesem Sinne: Ich freue mich über hochkarätige Kommentare und biete gerne die Möglichkeit für Gastartikel und -Postings an, wenn ein Leser/Kommentarautor ein Thema zum Anlass nehmen möchte über einen Kommentar hinaus umfangreicher zu schreiben. Interesse geweckt?

  3. Karl-Wilhelm von Rotenhan sagt:

    Ist ja mal wieder toll. Die Totgesagten leben immer am längsten ….

    Was Sie hier beschreiben, ist ein identischer aktions-Reaktionsmechanismus, den alle anderen anderen Projektwelten vor der IT in den vergangenen .. > 10xx Jahren .. durchgemacht haben ….
    Irgend wie werde ich das Gefühl nicht los, dass alle Neuzeit – Projektmanager die (Un-)reife des menschlichen (Fehl-)verhaltens selbst erfinden und erkennen wollen. Das als solches schadet ja nichts.
    Es wäre aber hilfreich dann doch mal auch andere und besonders hier auch ältere Quellen (u.U. sogar lateinische oder benediktinische) heranzuziehen.

    Da gab und gibt es für das Thema Änderungen ganz einfache – manchmal natürlich auch unangenehme Regeln. Hier die – etwas – neuere Ausgabe!

    Ich gehe mal davon aus dass Sie der PL sind und leiten, nicht leiden oder?
    Dann ….
    1. Klären Sie in Ihrem Projekt den Unterschied zwischen Plan und Änderung.
    1a Ergänzen Sie ein SOLL für das, was im Plan nicht hinterlegt ist, aber gemacht werden sollte. Wenn Plan =//= SOLL, dann ist es an Ihnen als PL das in Ordnung zu bringen.
    2. Klären Sie in Ihrem Projekt den Unterschied zwischen Änderung und Veränderung. (= Neue Wand einziehen oder Rosen züchten)
    3. Klären Sie in Ihrem Projekt mit allen Beteiligten den Weg von der Idee zum Wunsch zum Bedarf zum Auftrag und zur Realisierung.
    4. Klären Sie in Ihrem Projekt verbindlich den Weg der Entscheidungs-Eskalation.
    5. Stellen Sie klare Regeln dafür auf wo Agilität (= mach mal schnell) ihr Ende hat und bei wem.

    Ach ja .. noch zwei Hinweise zum Leiten

    Stellen Sie hin und wieder mal nicht die „Wer soll das jetzt Zahlen?“ Frage hinterher sondern die „Ist es das Wert ? Und wem?“ vorher – Frage?
    Lassen sie das Team auf Basis der (eignen) Antwort entscheiden wohin die Reise gehen soll.

  4. Kurt Jelinek sagt:

    Im IT Geschäft sind Changes Standardware. Es stellt sich die Frage wie gehe ich damit um! Klar kann man rigoros ablehnen. Das hilft nicht wirklich. Eines stelle ich jedoch in der Praxis fest, eine Qualtitätssteigerung der Requirements – daher mehr Eindeutigkeit bei den Anforderung und Aufgaben – steigert die gesamte Projektablaufqualität, reduziert die Summe der Change Requests, verbessert die Arbeit innerhalb der IT-Entwicklung und Testteam. Sprüche wie, heute rechts und morgen links lassen sich damit sehr oft vermeiden usw. Eines ist jedoch auch klar, Einfordern von mehr Eindeutigkeit bei den Aufgaben und den Anforderung bedeutet Pflichtenhefte hinterfragen, Ehrenrunden drehen, und es bedeutet auch sehr oft der Projektstart wird um einige Tage verzögert. Es ist jedoch auch schon vorgekommen, dass der gesamte Projekt Scope komplett überdacht wurde und das Projekt eine neue Ausrichtung erhält. Dass die Verzögerung oft Unverständnis und Unmut beim Business (Auftraggeber) auslöst, damit muss man umgehen lernen. Trotzdem leiste ich mir den Luxus die Aufgaben und Anforderung in Requirements Engineering Qualität einzufordern. Es reduziert die Changes und schont das Projekt-Budget und die ggf. notwendige vermeintliche Projektverzögerung hat kaum einen Einfluss auf den Projekt Endtermin. Ob man nun Scope creep umbenennt berührt mich persönlich nicht.

%d Bloggern gefällt das: