Wie kann man das Scope Creep minimieren?

Ich habe mich in den letzten 2 Jahren viel mit einem Scope Creep beschäftigt. Ich habe eine Liste mit Dingen erstellt, die unbedingt beachtet werden müssen, um die negativen Auswirkungen auf das Projekt zu minimieren.

Zunächst sollten Sie sich darüber im Klaren sein, dass es zu einem Scope Creep kommen wird!

Du solltest:

• die Anforderungen kennen;
• die Erwartungen des Kunden kennen;
• haben Eier, um "Nein" zu sagen. „Ja“ zu sagen, um den Kunden zu besänftigen, kann zu einem ausreichenden Scope Creep führen. Infolgedessen könnte ein gutes Projekt zu einem Distressed-Projekt werden;
• Hinterfragen Sie immer die Notwendigkeit der Änderung. Stellen Sie sicher, dass es eine angemessene Begründung für eine Änderung gibt. Änderungskontrollprozess im Voraus definieren;
• Bestimmen Sie, wie sich die Umfangsänderung auf den Zeitplan, die Kosten und die Ressourcen auswirkt. Sehen Sie, ob einige der Meilensteindaten verschoben werden können oder nicht;
• Beziehen Sie die Benutzer frühzeitig mit ein. Eine gute Idee könnte sein, Kundeninterviews zu führen, bevor Sie ein tatsächliches Produkt haben;
• wissen, wer "unterschriftsberechtigt" ist. Sie sollten diese Art von Stakeholdern genau verwalten;
• Vermeiden Sie Vergoldung und Perfektionismus. Ändern Sie Ihre Denkweise von „perfekt“ zu „gerade genug“;
• Beachten Sie die Vertragsstrafen für verspätete Lieferung. Indem er Umfangsänderungen durchsetzt, die den Zeitplan verlängern, könnte der PM Strafklauseln vermeiden.

Konzentrieren Sie sich auf den Kundennutzen. Nur weil dem Kunden eine neue Funktion einfällt, heißt das nicht, dass die, die Sie gerade schreiben, ihren Wert verloren hat.

Ich versuche, diese Richtlinien zu befolgen: - Langsamer werden. Springen Sie nicht zu den neuen Scopy-Dingen. Der ursprüngliche Geltungsbereich wurde analysiert und sorgfältig geprüft. Der neue Geltungsbereich ist wahrscheinlich gerade aufgetaucht. Keineswegs sind alle Anforderungen und Implikationen bekannt. Geben Sie der Idee Zeit zum Reifen. Während Sie am ursprünglichen Umfang arbeiten. - Sobald Sie den 'Jump-at-it'-Modus verlassen haben, erfassen Sie den neuen Umfang in Anforderungen, Benutzergeschichten usw. - Überprüfen Sie, wie es hineinpasst und ob Ihr ursprüngliches Zielfernrohr bereits einen Teil dieses neuen Zielfernrohrs bietet. Und wenn Sie schon dabei sind; Fragen Sie nach einem Businesscase für den neuen Anwendungsbereich. Wie wird der Kunde das Geld zurückverdienen?

Viele Ideen scheitern in dieser Phase, da sie bereits möglich sind oder nicht wirklich nah genug am Herd sind, um die Spezifikationen tatsächlich aufzuschreiben.

Für Ideen, die überleben, bringe ich das Programm immer noch gerne zuerst im Betrieb zum Laufen. Sehen Sie sich „Minimal Viable Product“ an.

Wenn Ihr Programm tatsächlich in Betrieb ist, werden Sie sinnvolle Diskussionen führen: Fügen wir Dinge hinzu, an die wir ursprünglich gedacht haben (ursprünglicher Umfang)? Oder möchten Sie lieber, dass wir diese neue Idee zuerst bauen? Welche Idee bringt an dieser Stelle den größten Mehrwert?

Wenn Sie dies richtig machen, verliert das Wort „Scope Creep“ seine Bedeutung.

Der beste Weg zur Minimierung des Scope Creep ist eine sorgfältige Planung und ein strukturierter Change-Management-Prozess. Indem Sie einen klaren Projekt- und Zeitplan haben und Änderungen nicht von Anfang an unkontrolliert zulassen, ist dies der beste Weg, um Scope Creep zu vermeiden. Sie können den Projektplan anpassen, müssen jedoch abwägen, wie sich dies auf Ihr Budget, Ihren Zeitplan und Ihren Umfang auswirkt. Ein Muss in jedem Projekt ist auch die Dokumentation des Umfangs in einem Scope Statement, dieses Dokument hilft Ihnen, Ihre Maßnahmen gegenüber Ihrem Auftraggeber zu begründen und dient am Ende des Projekts als Nachweis, dass Sie die Anforderungen im Vertrag erfüllt haben.

Erstens sollten Sie nicht versuchen, expandierende Anforderungen zu minimieren. Veränderungen werden stattfinden und sollten stattfinden, und es sollte keinen Druck geben, dies zu verhindern. Was benötigt wird, ist ein Änderungskontrollprozess, der Änderungen sowohl prospektiv als auch rückwirkend verarbeiten kann, wobei letztere nur minimal genutzt werden. Wenn sich also Anforderungen ändern oder neue identifiziert werden, verarbeiten Sie die Änderung schnell, integrieren den neuen Umfang in das Projekt, gewinnen Zeit und Geld und arbeiten weiter.

Veränderung ist gut. Es macht das Produkt für den Kunden wertvoller und steigert im Falle des Verkäufers den Umsatz.

In Bezug auf die Akzeptanzkriterien für Änderungsanträge muss der Prozess die gemeinsame Verantwortlichkeit und Kundenorientierung erleichtern. Zum Beispiel:

Die allgemeine Weisheit zur Vermeidung von Scope Creep lautet ungefähr so:

1. Fordern Sie den Anforderer der Bereichsänderung auf, ein Formular auszufüllen oder die Änderung anderweitig formell zu beschreiben.

2. Protokollieren Sie das Formular (wie Sie alles andere auch tun).

3. Bestimmen Sie die Auswirkungen der angeforderten Änderung.

4. Überprüfen Sie die Änderung mit dem Kunden / Geschäftsinhaber / Projektteam und genehmigen oder lehnen Sie die Anfrage ab.

5. Aktualisieren Sie Projektdokumente und benachrichtigen Sie das Team über alle Änderungen.

Mein Trick besteht darin, Schritt 3 im Grunde genommen als Komponente von Schritt 1 nach oben zu verschieben und einen kurzen Fragebogen über die Auswirkungen der vorgeschlagenen Änderung direkt in das ursprüngliche Anfrageformular aufzunehmen. Ich bitte auch darum, dass die Änderung – wenn möglich quantitativ bestimmbar – einer der Schlüsselmetriken/Geschäftsziele zugeordnet wird, die in den Geschäftsanforderungen des Projekts festgelegt sind.

Verweise

• Bekämpfen Sie Scope Creep mit diesem Change-Request-Trick

MEINER BESCHEIDENEN MEINUNG NACH,

Mögliche Ursachen für Scope Creep und ihre Indikatoren

Locker definierte Projekte - Wenn das Projekt zusammen mit seinem Erfolg nicht richtig definiert ist, hat das Team nichts, worauf es sich stützen kann.

Mögliche Indikatoren:

Sie erhalten immer wieder Verweise auf andere Apps/Sites - ich denke, dass "Idee" in den meisten Fällen überbewertet wird. Die Mehrheit der neuen Unternehmer versucht einfach, den Erfolg von jemand anderem zu schaffen. Sie werden keine definierte Vision in ihrem eigenen Kopf haben, was sie zu erreichen versuchen, als Ergebnis werden sie sich immer von einem Weg entfernen, den sie sich ursprünglich vorgenommen haben.

Sie beschweren sich über – VIEL – Sie versuchen nur, den Erfolg eines anderen nachzubilden, und sie werden immer feststellen, dass ihre Leistung hinter ihren Erwartungen zurückbleibt, ohne wirklich zu wissen, was sie zu lösen versuchen. Sie wittern nur eine Gelegenheit, ohne das Problem und den Erfolg richtig zu definieren.

Mögliche Lösung- Haben Sie eine gute kundenorientierte Einheit (muss nicht unbedingt eine separate Einheit sein, sondern eine Gruppe, die Personen umfassen kann, die in unterschiedlichen Kapazitäten arbeiten). Agile ermutigt zu Änderungen und rät von Verträgen ab, aber das bedeutet nicht, dass Sie verpflichtet sind, jemandem ein vollwertiges maschinelles Lern-Tool zur Beurteilung der finanziellen Gesundheit zu geben, wenn er sich zum ersten Mal auf den Weg macht, ein finanzielles Logbuch zu erstellen. Es liegt in der Verantwortung der Einheit, die Kundenorientierung aufrechtzuerhalten, und das Ziel sollte immer darin bestehen, definierte Projekte zu haben. Um dies zu erreichen, benötigen Sie möglicherweise gute Verhandlungs- und Organisationsfähigkeiten. Wenn Sie jedoch bereits den Fehler gemacht haben, das Projekt nicht zu definieren, versuchen Sie es ab sofort in jeder möglichen Weise zu korrigieren.

Die Lösung funktioniert nicht für das Problem – Viele Projektmanager verlassen sich manchmal stark auf die Anforderungen des Kunden. Wenn jemand mit einer Projektidee hereinkommt, versucht er vermutlich, ein bestimmtes Problem zu lösen. Es muss eine Anforderungsanalyse und eine richtige Vorstellung davon geben, wie das Team an die Lösung herangehen wird. Es ist seitens des Kunden unfair, wenn ein Team Lösungen vom Kunden erwartet, und das wird natürlich nie gut. Es ist, als würde man zu einem Arzt gehen und dem Patienten Ratschläge geben, wie er die Behandlung angehen soll. Im Großen und Ganzen sagen für zB. Ich möchte eine Software für mein Café erstellen. Das Problem ist subjektiv und die Aussage hat mehrere Bedeutungen.

Ich könnte versuchen, das Problem mit meinen Mitarbeitern und deren Gehaltsverwaltung ODER zu beheben

Ich könnte versuchen, eine Software zu entwickeln, die mir hilft, meine Bestandsverwaltung zu optimieren ODER

Ich könnte versuchen, eine Software zu entwickeln, die meinen Kunden hilft, ihre Bestellungen online aufzugeben.

Daher werden die Lösungen, das Design und die Benutzererfahrung davon abhängen, was ich tatsächlich zu erreichen versuche. Wie die Ergebnisse aussagekräftig präsentiert werden, kann für jede der oben genannten Gruppen völlig unterschiedlich sein. Daher muss die Anforderungsanalyse subjektiv angegangen und die Schlussfolgerungen richtig definiert werden, um eine Vision/Richtlinien zu erstellen, denen das Team folgen wird. Es versteht sich von selbst, dass es partizipativer Natur sein sollte, wobei die wichtigsten Aspekte berücksichtigt werden, um die Interessengruppen zufrieden zu stellen und das Arbeitsteam zu motivieren.

Mögliche Indikatoren:

Sie besuchen immer wieder dieselbe Funktion – der Kunde weiß, dass die Lösung für das Problem nicht funktioniert, und kommt immer wieder mit einer Lösung zurück, von der er glaubt, dass sie funktionieren könnte, aber tatsächlich nicht funktioniert.

Eine Art Änderungszyklus wiederholt sich mit jedem Sprint – der Kunde könnte unwissentlich versuchen, Sie wieder auf die Lösung auszurichten, die tatsächlich für ihn funktioniert.

Mögliche Lösung - Wahrscheinlich kennt der Kunde sein Problem und er weiß, dass die von Ihnen bereitgestellte Lösung nicht sein Kernproblem anspricht. Sie werden versuchen, eine Lösung zu finden, die wiederum funktionieren kann oder nicht. Um die Dinge ins rechte Licht zu rücken, sagen wir, ich versuche, meine Finanzen zu verfolgen, dann würde ich wahrscheinlich Datenvisualisierungen mit KPIs wollen, der Kunde weiß vielleicht nicht einmal, was KPI ist. Als Lösungsanbieter liegt es an uns, tatsächlich Ideen vorzuschlagen, die ihr Problem tatsächlich lösen können. Denn genau darum geht es bei Innovation. Das Team soll jederzeit motiviert bleiben, Erfolge zu erzielen, die es zu definieren gilt. Wenn das Team das Problem versteht und ihre Lösungen aufeinander abgestimmt sind, werden sowohl Scope Creep als auch Scope Change nicht teuer.

Definieren Sie das Projekt und seinen Erfolg richtig. Dies ist das Wichtigste, unabhängig von der philosophischen Neigung Ihrer Organisation, die Organisation muss einen einheitlichen und eindeutigen Prozess zur tatsächlichen Definition des Projekts und seiner Erfolgskriterien haben.