Scope Creep ist der Fluch im Leben eines jeden Projektmanagers und bis zu einem gewissen Grad unvermeidlich, sagt Andrew Vermes, Technology Practice Leader beim Beratungsunternehmen Kepner-Tregoe.<\/p>\n
Scope Creep kann von vornherein vermieden werden. Sollte dies jedoch nicht m\u00f6glich sein, werden wir uns M\u00f6glichkeiten ansehen, wie man damit umgehen kann. Dies ist eine Sammlung praktischer Techniken und kein Ersatz f\u00fcr das umfangreiche theoretische Wissen, das Sie im Project Management Body of Knowledge (PMBoK), im Capability Maturity Model for Projects, in PRINCE2 oder an anderer Stelle finden k\u00f6nnen. <\/p>\n
Es gibt gute Gr\u00fcnde f\u00fcr Unternehmen, die Anforderungen in einem IT-Projekt zu erweitern oder zu \u00e4ndern: Die Welt dreht sich weiter; neue Bedrohungen f\u00fcr die Datensicherheit werden entdeckt, externe Kundenanforderungen \u00e4ndern sich, die Technologie schreitet so weit fort, dass das Unwahrscheinliche oder hoffnungslos Teure in praktische Reichweite r\u00fcckt. Die schlechten Gr\u00fcnde f\u00fcr Anforderungs\u00e4nderungen lassen sich so zusammenfassen: \u201eWir haben es am Anfang einfach nicht richtig durchdacht\u201c. <\/p>\n
Sie k\u00f6nnen einen Gro\u00dfteil des Scope Creep vermeiden oder bew\u00e4ltigen, indem Sie die folgenden Ans\u00e4tze bei jedem Projekt oder Teilprojekt anwenden:<\/p>\n
Um den endg\u00fcltigen Umfang fest im Griff zu haben, m\u00fcssen Sie die Stakeholder an der Prozess\u00fcberpr\u00fcfung beteiligen. Auf diese Weise werden sie auf M\u00e4ngel im aktuellen Prozess hinweisen sowie auf Punkte, an denen der \u201ereale\u201c Prozess erheblich vom Betriebshandbuch der Abteilung abweicht. Sp\u00e4tere \u00dcberraschungen f\u00fchren zu unerw\u00fcnschten \u00c4nderungen. <\/p>\n
Wenn Sie eine bestehende Funktion \u00e4ndern, lassen Sie einige Anwender ihre Arbeitsabl\u00e4ufe durchspielen. Post-it-Notizen sind eine hervorragende M\u00f6glichkeit, die einzelnen Schritte festzuhalten. Achten Sie darauf, dass sie Ihnen zeigen, was sie tun, anstatt nur zu beschreiben, was ihrer Meinung nach passiert. Bei einem neuen Prozess k\u00f6nnen sie mit Ihnen den von ihnen vorgestellten Ablauf durchgehen. <\/p>\n
Sobald Sie den Prozess erfasst haben, lassen Sie ihn die Anwender bei einer realen Aufgabe testen. Zeichnen Sie bei Bedarf ein paar grobe Entw\u00fcrfe der Benutzeroberfl\u00e4che auf Papier und fragen Sie die Anwendergruppe, wie gut diese funktionieren. Dokumentieren Sie die L\u00fccken und spielen Sie den Prozess so lange durch, bis Sie sicher sind, dass er das tut, was er soll. <\/p>\n
\u201eWhite Space\u201c ist ein Schlagwort, das in letzter Zeit h\u00e4ufig verwendet wird. Der Begriff, der in den neunziger Jahren von Alan Brache und Geary Rummler bekannt gemacht wurde, bezieht sich auf die Beobachtung, dass ein Gro\u00dfteil der wichtigen Arbeit in jeder Organisation au\u00dferhalb der \u201eoffiziellen\u201c Prozessschritte und ohne R\u00fccksicht auf die Organisationshierarchie erledigt wird. W\u00e4re dies nicht der Fall, k\u00f6nnten viele unserer Unternehmen zusammenbrechen. <\/p>\n
Ein Ansatz besteht darin, zu versuchen, alles in die Prozessvorgaben zu zwingen. Aus der Sicht eines Projektmanagers zeigt dies auch, dass wir uns um die Schnittstellen zwischen den Prozessschritten k\u00fcmmern m\u00fcssen. Was passiert eigentlich entlang des Pfeils von einem Schritt zum n\u00e4chsten? Was tun die Menschen, um einen Mehrwert zu schaffen, der im Prozessfluss nirgendwo dargestellt ist? <\/p>\n
Beziehen Sie die Anwender- und Stakeholder-Gemeinschaft viel st\u00e4rker in die Entwicklung des Projektumfangs ein. Der typische Ansatz besteht darin, dass Business- und Systemanalysten Fragen stellen, Anforderungen entwerfen und diese dann mit den Stakeholdern abstimmen. Die Risiken sind bekannt: Anwender liefern eine schlecht durchdachte Wunschliste und f\u00fcgen dann w\u00e4hrend des gesamten Entwicklungszyklus st\u00e4ndig neue Punkte hinzu oder \u00e4ndern ihre Meinung. <\/p>\n
Ein typischer Projektumfang definiert f\u00fcnf Elemente: Was, Warum, Wie, Wann und Wie viel. Die Definition dessen, was das Projekt erreichen soll \u2013 bekannt als Project Statement \u2013, ist entscheidend. Es muss das Endprodukt pr\u00e4gnant beschreiben, und zwar so, dass der Anwendergemeinschaft klar wird, was sie erh\u00e4lt, und den Erstellern (uns), was wir produzieren m\u00fcssen. <\/p>\n
Die richtigen Worte \u2013 oder Bilder \u2013 in dieser Phase zu finden, ist extrem wichtig. Es ist auch n\u00fctzlich, die Stakeholder-Gruppe an der Erstellung des Projektstrukturplans zu beteiligen. W\u00e4hrend es kontraproduktiv sein kann, sie in jedes Detail einzubeziehen, gibt ihnen ihre Anwesenheit bei der Festlegung der wichtigsten Ergebnisse ein Verst\u00e4ndnis daf\u00fcr, was wie gebaut werden soll, und dient als n\u00fctzlicher Realit\u00e4tscheck. <\/p>\n
Projektziele (Warum machen wir das?) sind h\u00e4ufig selbst eine Quelle f\u00fcr Scope Creep, insbesondere wenn wir uns zu Ergebnissen verpflichten, die das Projekt allein nicht liefern kann.<\/p>\n
Eine einfache Technik, die Sie f\u00fcr einen Realit\u00e4tscheck und zur Hinterfragung von Anforderungen einsetzen k\u00f6nnen, ist die 5-Why-Methode. Die 5-Why-Methode hat ihren Ursprung bei Toyota in Japan und sollte die Ursache eines Problems aufdecken. Die Idee dahinter ist, dass man durch f\u00fcnfmaliges aufeinanderfolgendes Fragen nach dem \u201eWarum\u201c den Wissensstand erh\u00f6ht, den man f\u00fcr eine L\u00f6sung ben\u00f6tigt, indem man den Kern des Problems versteht, das das Unternehmen zu l\u00f6sen versucht. <\/p>\n
Worin besteht das Problem?<\/strong> Dieses kurze Beispiel zeigt, dass unsere Herausforderung darin besteht, die bew\u00e4hrte Stabilit\u00e4t beizubehalten, wir aber einen Weg finden m\u00fcssen, die Kapazit\u00e4t schnell zu erh\u00f6hen. Es hilft auch, den Fokus weg von der Suche nach mehr Platz f\u00fcr Serverfarmen hin zu dem Versuch zu lenken (vielleicht), Maschinen zu identifizieren, die die gleiche Betriebszeit bei geringerer W\u00e4rmeentwicklung liefern k\u00f6nnen. <\/p>\n Es ist nicht immer der Fall, dass f\u00fcnf \u201eWarum\u201c ausreichen. KT bef\u00fcrwortet das, was es \u201eHinterfragen bis ins Leere\u201c nennt \u2013 mit anderen Worten, die Frage so lange zu wiederholen, bis man sicher ist, dass man alle verf\u00fcgbaren Informationen oder Ideen ausgesch\u00f6pft hat. <\/p>\n Die 5-Why-Methode ist auch n\u00fctzlich, um die Hintergr\u00fcnde der genannten Anforderung zu ergr\u00fcnden:<\/strong><\/p>\n Wir m\u00fcssen unsere CRM-Datenbank mit dem System f\u00fcr das regulatorische Meldewesen verbinden Nat\u00fcrlich werden Sie die Formulierungen variieren, um nicht wie ein Papagei zu klingen: \u201eWas hat Sie zu diesem Bedarf gef\u00fchrt?\u201c \u201eInwiefern hilft Ihnen das weiter?\u201c<\/p>\n Risikomanagement wird von jeder Instanz im Projektmanagement bef\u00fcrwortet, einschlie\u00dflich des Project Management Body of Knowledge. In der Realit\u00e4t konzentrieren sich Risikoprotokolle jedoch zu oft auf greifbare, offensichtliche Risiken wie \u201eServerausfall\u201c oder \u201eGeb\u00e4udebrand\u201c und vers\u00e4umen es, die spezifischen Projektherausforderungen tief genug zu untersuchen. Beim Management des Projektumfangs kommt es darauf an, sich sowohl auf Chancen als auch auf Risiken zu konzentrieren und alle potenziellen Abweichungen vom Umfang auf die gleiche Weise zu behandeln. <\/p>\n Unser Ziel sollte es sein, ein kontinuierliches Verst\u00e4ndnis daf\u00fcr zu entwickeln, wie Ver\u00e4nderungen um uns herum unser Projekt beeinflussen oder verbessern k\u00f6nnen. F\u00fcr das Management des Projektumfangs ist das Gesch\u00e4ftsumfeld die Kategorie von Risiko\/Chance, die am meisten Beachtung finden sollte, sowie die Ereignisse innerhalb und au\u00dferhalb der Organisation, die uns dazu veranlassen k\u00f6nnten, unsere Meinung \u00fcber Anforderungen zu \u00e4ndern. <\/p>\n F\u00fchren Sie w\u00f6chentliche Sitzungen zu Problemen, Risiken und Chancen mit den Stakeholdern durch. Unpraktisch? Nein \u2013 vor allem dann nicht, wenn Sie ein einfaches Framework verwenden und das Meeting oder den Call auf 30 Minuten begrenzen. Die Schl\u00fcsselfragen lauten stets: <\/p>\n Welche Probleme sehen Sie, die in irgendeiner Verbindung mit diesem Projekt stehen? W\u00e4hlen Sie aus, welche Risiken und Chancen Sie \u2013 Jedes Projekt basiert auf vielen Annahmen. Diese k\u00f6nnen interne und externe M\u00e4rkte, Lohns\u00e4tze, verf\u00fcgbare Technologien, regulatorische Beschr\u00e4nkungen, Margen f\u00fcr Produkte und Dienstleistungen und sogar die Art des Gesch\u00e4fts betreffen. Der Projektumfang muss wahrscheinlich angepasst werden, wenn sich eine der Annahmen wesentlich \u00e4ndert. Ein Fr\u00fchwarnsystem kann uns helfen, die St\u00f6rungen besser zu bew\u00e4ltigen. <\/p>\n Im Extremfall bedeutet eine grundlegende \u00c4nderung der Annahmen, dass das Projekt beendet werden muss. Je schneller wir das erkennen, desto besser, um die Verschwendung von Ressourcen zu reduzieren. Im vorangegangenen Beispiel des technischen Support-Teams war eine zentrale Annahme \u2013 dass qualifiziertes Personal verf\u00fcgbar und kosteng\u00fcnstig ist \u2013, die damals zutraf, heute weniger g\u00fcltig. Und die Umst\u00e4nde k\u00f6nnen sich erschreckend schnell \u00e4ndern. <\/p>\n Die Liste der Ideen ist nicht ersch\u00f6pfend, aber dies sind sechs Dinge, die Sie und Ihr Projektteam schnell und mit wenig zus\u00e4tzlichem Aufwand tun k\u00f6nnen.<\/p>\n Beim Management des Projektumfangs geht es vor allem darum, auf die kleinen Dinge zu achten. Die Anzeichen daf\u00fcr, dass sich die Dinge \u00e4ndern, sind \u00fcberall um uns herum, wenn wir uns entscheiden, sie zu h\u00f6ren und zu sehen. <\/p>\n","protected":false},"excerpt":{"rendered":" Scope Creep ist der Fluch im Leben eines jeden Projektmanagers und bis zu einem gewissen Grad unvermeidlich, sagt Andrew Vermes, Technology Practice Leader beim Beratungsunternehmen Kepner-Tregoe. Scope Creep kann von vornherein vermieden werden. Sollte dies jedoch nicht m\u00f6glich sein, werden wir uns M\u00f6glichkeiten ansehen, wie man damit umgehen kann. Dies ist eine Sammlung praktischer Techniken […]<\/p>\n","protected":false},"author":8,"featured_media":37956,"template":"","white-paper-type":[],"class_list":["post-63733","white-paper","type-white-paper","status-publish","has-post-thumbnail","hentry"],"acf":[],"yoast_head":"\n
\nWir k\u00f6nnen die neue Serverkapazit\u00e4t nicht rechtzeitig installieren.
\nWarum?<\/strong>
\nEs gibt Beschr\u00e4nkungen f\u00fcr die Anzahl der Maschinen pro Rack
\nWarum?<\/strong>
\nDie erzeugte Hitze ist hoch
\nWarum?<\/strong>
\nVerwendung von Maschinen \u00e4lterer Bauart
\nWarum?<\/strong>
\nWeil die vorherige Generation eine hohe Stabilit\u00e4t bietet<\/p>\n
\nWarum?<\/strong>
\nWir ben\u00f6tigen Einblick in meldepflichtige Beschwerden, wenn wir mit neuen Kundenanfragen zu tun haben
\nWarum?<\/strong>
\nWir wollen sicherstellen, dass die technische Beratung angemessen ist<\/p>\nEreignisse managen<\/h4>\n
\nIn welcher Weise?
\nWas ist die aktuelle (tats\u00e4chliche) Auswirkung dieser Probleme, falls vorhanden?
\nWas ist die potenzielle (zuk\u00fcnftige) Auswirkung?
\nListen Sie die spezifischen Risiken, wahrscheinlichen Ursachen und potenziellen Ma\u00dfnahmen auf
\nListen Sie die spezifischen Chancen, wahrscheinlichen Ursachen und potenziellen Ma\u00dfnahmen auf<\/p>\n
\n\u2013 vorerst ignorieren
\n\u2013 genau beobachten
\n\u2013 aktiv angehen<\/p>\nAnnahmen sichtbar machen<\/h4>\n