Strategisches Scope-Management

Der unterschätzte Hebel im Projektgeschäft

Was kommt noch ins Projekt und worauf können wir verzichten? Zum Anfang eines Projekts und erst recht später, wenn wir merken, dass wir den Zeit- bzw. Kostenplan nicht einhalten können, sind das wichtige Fragen. Es sind Fragen, die sich um den Scope – den Funktionsumfang – eines Vorhabens drehen. Der Scope ist eine der zentralen Größen im Projektmanagement. Die agile Vorgehensweise zeichnet sich unter anderem dadurch aus, dass der Scope nicht mehr fest vorgegeben, sondern verhandelbar ist. Wenn es also zeitlich eng wird, verzichten wir lieber auf ein paar Features, als den Termin zu überschreiten. Ähnliches gilt für Ressourcen: wir streichen Scope, statt mehr Leute als geplant einzusetzen. Und schließlich ist auch die Qualität nicht verhandelbar, sie wird gleichbleibend hoch gehalten u.a. mit kontinuierlicher Integration und automatisierten Tests.

Taktische und strategische Ausrichtung

Taktisches Scope-Management gibt es reichlich: vor jeder Iteration wird entschieden, welche User Storys (oder Features, je nachdem, wie die Arbeit strukturiert ist) abgearbeitet werden sollen. Abwägungen zwischen verschiedenen User Storys werden, insbesondere in Scrum, ad-hoc gemacht – man vertraut darauf, dass der Product Owner schon weiß, welche Prioritäten sie oder er setzen muss. User Storys werden dabei als weitgehend unabhängig voneinander betrachtet; das ist eine nützliche Fiktion, die Overengineering vermeiden soll.

Strategisches Scope-Management findet oft nur am Anfang eines Projektes statt: große Gruppen von Features werden ausgewählt, und nachdem die ersten Grobschätzung gemacht ist, wird nötigenfalls zusammengestrichen. Wenn ein Projekt in Schieflage geraten ist, ist es meist zu spät für echtes Scope-Management, vielmehr muss man „retten was zu retten ist“ und zähneknirschend auf Vieles verzichten, was beim Projektstart noch als „absolut essenziell“ eingestuft wurde. Auch viele angefangene Features, die vielleicht schon zu 80 % fertig waren, müssen gestrichen werden, da das Restbudget nur noch für das Nötigste reicht. Strategisches Scope-Management versucht, solche Zwangslagen zu vermeiden und berührt darüber hinaus noch weitere Fragen:

• Wie kann man günstigere Alternativen entwickeln, indem der Fachbereich z.B. seine Anforderungen leicht abändert?
• Wo gibt es Möglichkeiten, „Make or Buy“ zugunsten von „Buy“ zu entscheiden?
• Wie lassen sich größere Cluster von Anforderungen sinnvoll strukturieren?
• Wie vermeidet man, dass die Stakeholder nur jeweils ihre lokale Optimierung verfolgen und darüber den Geschäftsnutzen aus den Augen verlieren?

Das Idealbild von Scope entspricht ungefähr dieser Schachtel Pralinen. Ich kann die Pralinen in beliebiger Reihenfolge essen, und mit jeder Praline steigt mein Nutzen gleichmäßig an. Keine Rede davon, dass ich vielleicht das Stück in der Mitte zuerst essen muss, weil mir sonst alle anderen nichts nützen.

Den Scope strukturieren

Das bekannte „Eiserne Dreieck des Projektmanagements“ besagt, dass die drei Einflussgrößen Zeit, Kosten, und Scope voneinander abhängig sind. Wer Änderungen in einer Ecke will (z.B. die Zeit bis zur Fertigstellung verkürzen), muss Konsequenzen in den anderen Ecken in Kauf nehmen (z.B. höhere Kosten oder einen geringeren Funktionsumfang).

In agilen Projekten wird Scope als Puffer verwendet, um mit Unsicherheit umgehen zu können. Auf Scope zu verzichten ist meist besser als die Alternativen:

• Das Projekt zeitlich auszudehnen, verursacht Mehrkosten und verzögert das Feedback.
• Man könnte die Kosten erhöhen, indem man das Team vergrößert. Dagegen steht aber Brooks‘ Law: Mehr Leute auf ein verspätetes Projekt zu setzen, verzögert das Projekt nur noch mehr.¹
• Kann man nicht an der Qualität sparen und so den Termin halten? Das wird immer wieder versucht, ist aber ganz schwierig, u.a. weil verminderte Qualität schnell zu teuren Nachbesserungen führt.

Also verringern wir einfach den Scope, sobald unsere Vorhersage zeigt, dass wir den Termin verfehlen, und alles ist gut…oder?

Unangenehm wird es nur, wenn wir nichts streichen können, weil einfach zu wenig Nützliches übrig bleiben würde. Wenn ein entscheidender Schritt im Workflow noch fehlt, während die anderen Schritte schon 95 % der Wünsche erfüllen. Wenn ein Team nicht liefern kann, obwohl sein Beitrag entscheidend für das Gesamtergebnis ist. Oder wenn alle Features zu 80 % fertig sind, aber keines davon wirklich benutzbar ist. Daraus ergibt sich das erste Prinzip des Strategischen Scope-Managements:

Gutes Scope-Management heißt: Den Scope so strukturieren, dass man ihn später leicht verringern kann.

Ein realistischeres Bild für Scope. Die Teile des Gesamtsystems „Hafen“ sind voneinander abhängig. Es ist nicht ohne weiteres klar, ob und wie man auf einzelne Teile verzichten könnte. Kann man vielleicht einen Kran weglassen und trotzdem noch einen großen Teil des Kundennutzens retten? Oder Kosten sparen, indem man die Halle nicht baut?

Bevor wir uns den Zielen des Scope-Managements zuwenden, will ich noch ein paar Herangehensweisen beschreiben:

Abhängigkeiten visualisieren

Wir können die Abhängigkeiten im Scope nicht ignorieren, es ist daher wichtig, sich ein gutes Modell dafür zu erarbeiten. Am besten geht das mit einer Visualisierung des gesamten Scopes, die gern auch großformatig an eine Wand gehängt werden darf.

Nehmen wir als Beispiel ein fiktives Unternehmen: MisterFixit vermittelt kleinere Dienstleistungen rund ums Haus („Uber für Hausmeister“). Wenn bei Ihnen am Sonntagabend die Badewanne leckt, könnten Sie den Klempner-Notdienst beauftragen, doch das wird teuer. Oder sie rufen beim Call Center von MisterFixit an, dort schickt man unmittelbar einen von Hunderten Helfern vorbei, der sich das mal ansieht. Der Helfer kann Ihre Badewanne wahrscheinlich genauso gut reparieren wie ein Klempnermeister, allerdings zu einem Bruchteil der Kosten.

Für die Vermittlung muss der Call Center-Mitarbeiter von MisterFixit natürlich wissen, wer im Helferpool die nötigen Qualifikationen besitzt und verfügbar ist. Der Anfahrtsweg sollte auch nicht allzu lang sein. Das Unternehmen bindet die Kunden über eine Jahresmitgliedschaft an sich, selbstverständlich können Sie auch beim ersten Termin Mitglied werden. Bisher lief das alles im Innenstadtbereich von Hamburg über eine Kombination von Excel-Tabellen, gelben Klebezetteln und viel Erfahrung im Call Center. Die Geschäftsführung will das erfolgreiche Geschäftsmodell auf weitere Standorte ausdehnen, innerhalb eines Jahres sollen mindestens noch Berlin, Leipzig, München und Stuttgart dazukommen. Daher soll jetzt in eine Web-Applikation investiert werden, die die Arbeitsabläufe rund um die Buchung von Terminen beschleunigt und Fehler vermeidet. Dann bietet es sich natürlich an, dass die Club-Mitglieder auch Termine direkt über das Web buchen können. Außerdem möchte das Marketing Gutscheine und kostenlose Mitgliedschaften promoten. Idealerweise sollen die Club-Mitglieder direkt beim Termin vor Ort per Kreditkarte, PayPal, oder die (noch zu entwickelnde) MisterFixit App bezahlen („On-site payment“). Alternativ ist auch eine Rechnungsstellung möglich. Neben der eigentlichen Terminbuchung sollte es noch eine Möglichkeit zur Abrechnung („Charging“) geben, z.B. für Arbeitszeit, Anfahrtsweg und die Club-Mitgliedschaft. Und natürlich müssen sich die Helfer („Provider“) im System einloggen können („Auth“), um ihre Verfügbarkeiten einzutragen (etwa: nächste Woche immer von 9 bis 17 Uhr, im Zentrum von Berlin).

Die Abhängigkeiten der geplanten Web-Applikation finden Sie in nachfolgender Grafik. Die Abhängigkeiten sind durch Pfeile visualisiert.

Alles, was aus meiner Sicht in einer ersten Version verzichtbar ist, habe ich gestrichelt dargestellt. So könnten wir auf Funktionalität verzichten und zumindest einen Teil des Nutzens noch einfahren: Dienstleistungen können auf jeden Fall gebucht und abgerechnet werden.

• Wenn wir Termine nicht in Selbstbedienung über die Webseite vergeben, können wir auch die Authentifizierung von Kunden sparen.
• Für den Anfang können wir damit leben, wenn die Provider ihre Fähigkeiten selbst einschätzen („self-declared skills“), Zertifikate können notfalls später hinzukommen.
• Wenn wir die Bezahlung nur über Rechnung machen, können wir auf eine Menge Zahlungsmethoden verzichten.
• Schließlich könnten wir zur Not auch ohne Marketing-Kampagnen (Gutscheine, kostenlose Mitgliedschaften) starten.

All diese Abstriche an der Funktionalität ziehen natürlich Einbußen im Wert des Projektergebnisses nach sich.

Merkmale zur Strukturierung

Für die Strukturierung bieten sich einige Merkmale an:

• Funktionsumfang,
• Varianten,
• Verzögerungskosten.

Die Gliederung nach Funktionsumfang haben wir gerade am Beispiel MisterFixit gesehen: wir liefern in mehreren Ausbaustufen, wobei die erste Stufe schon ein benutzbares Ergebnis liefert, aber vom eigentlichen Projektziel noch weit entfernt sein kann.

Man kann den Funktionsumfang auch nach variantenbildenden Merkmalen aufschlüsseln. Dies sind Merkmale, deren Ausprägungen den betrachteten Geschäftsprozess in seinem Ablauf ändern. Wenn wir z.B. Bestellungen aus dem Ausland anders behandeln müssen, dann ist der Standort des Kunden ein variantenbildendes Merkmal. Im Beispiel könnte das Merkmal die Ausprägungen „Deutschland“, „Europäische Union“ und „Drittland“ haben.

Idealerweise weiß man, wie viel Umsatzvolumen (oder Gewinn) mit jeder Variante erzielt wird, was dann die Verbindung zwischen Scope und Nutzen herstellt. Eine Vielzahl von variantenbildenden Merkmalen eröffnet genug Spielraum, um sinnvolle Ausbaustufen zu definieren. So könnte die erste Version etwa nur Kunden in Deutschland unterstützen und damit schon 80 % des Umsatzvolumens abdecken. An dieser Stelle kann man oft auch Möglichkeiten zur permanenten Verringerung des Scopes entdecken: Geschäftsvorfälle, die nur im Promillebereich auftreten, muss man vielleicht gar nicht mit Software unterstützen.

Verzögerungskosten eignen sich gut zur Priorisierung von Features. Verzögerungskosten beantworten die Frage: Wie ändert sich das Gesamtergebnis (Profitabilität des Projekts über die gesamte Lebensdauer), wenn wir dieses Feature einen Monat später ausliefern? Bei MisterFixit würde man die Verzögerungskosten für die Terminvereinbarung in Selbstbedienung zum Beispiel so schätzen: Mit Selbstbedienung bekommen wir 10 % mehr Termine, bei 5 % weniger Kosten für das Call Center. Die Verzögerungskosten sind also 10 % eines Monatsgewinns plus 5 % der monatlichen Kosten des Call Centers, für jeden Monat, den das Feature später ausgeliefert wird. Priorisierung sollte noch den Zeitaufwand (in Kalendermonaten) für das Feature berücksichtigen, Details können Sie gern bei Don Reinertsen² nachlesen.

Kombinationen der hier genannten Strukturierungsmöglichkeiten sind natürlich auch sinnvoll: Etwa wenn die Version 1 nur inländische Kunden berücksichtigt und Features mit sehr hohen Verzögerungskosten beinhaltet.

Kommen wir nun zu Merkmalen, die nicht ganz so gut für das Scope-Management geeignet sind:

• der Reifegrad einer Anforderung
• die Gliederung nach Aufwand
• technische Abhängigkeiten
• die Organisationsstruktur

Den Reifegrad einer Anforderung kann man gelegentlich benutzen: Wenn die Fachabteilung noch gar nicht genau weiß, was sie will, können wir die Anforderung ablehnen oder verschieben. Das birgt natürlich ein Risiko, denn auch unausgereifte Anforderungen können großen Nutzen bringen. Es geht hier eher darum, in einem Überfluss von Wünschen schnell ablehnen zu können.

Die Gliederung nach Aufwand kann verführerisch sein, warum nicht erstmal die „low hanging fruits“ ernten und mit wenig Aufwand schnell etwas auf die Beine stellen? Das führt in die Irre, wenn man dabei den Nutzen außer Acht lässt.

Scope nach technischen Abhängigkeiten zu sortieren ist ebenfalls naheliegend, nur verläuft leider der Geschäftsnutzen fast nie parallel zu technischen Abhängigkeiten. Wenn wir etwa zunächst das Backend fertigstellen, bleibt der realisierte Nutzen immer noch bei Null. Die übertriebene Gewichtung von technischen Abhängigkeiten tritt oft auf, wenn man versucht, den Gesamtaufwand zu minimieren („Wenn wir schon mal dabei sind, können wir das auch gleich richtig und allgemeingültig lösen“).

Auch die Gliederung nach Organisationsstruktur wird manchmal versucht: Warum nicht erstmal alles machen, was Abteilung X betrifft? Leider ist der Nutzen oft abteilungsübergreifend, so dass wieder das Ergebnis lange bei Null bleibt. Falls nicht, machen Sie besser ein kleineres, abteilungsspezifisches Projekt. Conway’s Law besagt, dass die Architektur des Systems sowieso die Struktur Ihrer Organisation widerspiegeln wird, ein gewissen Maß von „Strukturierung“ auf diese Weise wird sich also nicht vermeiden lassen.

Ziele im Scope-Management

Wenn man über das Strukturieren von Scope nachdenkt, hilft es, sich

• Optionen für den Projektabbuch vorzustellen,
• das Feedback zu maximieren,
• paralleles Arbeiten zu ermöglichen,
• und einen Evolutionspfad zu schaffen.

Optionen für Abbruch schaffen

Was könnten wir liefern, wenn nächste Woche das Projekt beendet werden müsste? Das ist äquivalent zum Überziehen des Budgets bzw. zu einer zu optimistischen Schätzung: wir müssen beenden, bevor wir „fertig“ sind. Welche Features wären dann schon fertig (oder wenigstens benutzbar), welche Geschäftsprozesse könnten wir schon unterstützen? Wie kann man also die Optionen schaffen bzw. den Scope so strukturieren, dass er später ohne allzu große Kollateralschäden verringert werden kann?

1. Features nach Kundennutzen strukturieren. Das bedeutet, die Features in eine Reihenfolge zu bringen, in der möglichst früh möglichst viel vom geplanten Kundennutzen realisiert werden kann. Für jedes noch nicht angefangene Feature haben wir dann die Option, es nicht auszuliefern.
2. Features in Ausbaustufen liefern. Wenn ein Feature schon in der Grundversion sinnvoll ist, können wir die Grundversion fertig stellen und uns danach erstmal anderen Features zuwenden. Wir bekommen also die Option, das Feature teilweise auszuliefern.

Feedback maximieren

So kann man die Vorteile der agilen Vorgehensweise auch ausdrücken:

Wollen Sie die Überraschungen alle auf einmal, oder eine nach der anderen, iterativ?³

Wenn es um böse Überraschungen im Projekt geht, wollen wir am liebsten gar keine. Und die unvermeidlichen sollen bitteschön nach und nach kommen. Eine der peinlichsten Überraschungen ist sicher:

Wir haben alles richtig gemacht, aber der Endanwender will das Projektergebnis nicht haben.

So geschehen beim Großprojekt ROBASO (Rollenbasierte Oberflächen) der Arbeitsagentur. Auf einer einzigen IT-Plattform sollten 16 bestehende Anwendungen vereinigt werden, um die Bearbeitung ohne Doppeleingaben und Programmwechsel zu ermöglichen und insgesamt zu vereinfachen. Nach 5 Jahren Entwicklungszeit stellte man in einer Pilotphase 2015 fest, dass die MitarbeiterInnen die Software nicht einsetzen wollten bzw. konnten: Im praktischen Einsatz im Kundengeschäft zeigte sich, dass die Software zu wenig flexibel war, um der Komplexität der Kundenanliegen gerecht zu werden.

In der Presse wurde kolportiert, dass die Korrektur einer Kontonummer nicht möglich sei, ohne die gesamten Daten des Leistungsempfängers neu einzugeben. Nachdem die Pilotphase gravierende Mängel aufgedeckt hatte, beauftragte die Arbeitsagentur noch ein externes Projektaudit, Ergebnis: Die Defizite hätten nicht zeitnah und wirtschaftlich behoben werden können. Die BA hat sich deshalb entschlossen, das Projekt, in das seit dem Start 2010 insgesamt 60 Millionen Euro investiert wurden, zu beenden.

Soweit ich das beurteilen kann, gab es im Projektverlauf schon gelegentliches „Feedback“ von Anwendern. Nur ein echtes Release, und damit echtes Feedback, gab es zu spät.

Gutes Scope-Management bedeutet: Den Scope so strukturieren, dass möglichst früh möglichst realistisches Feedback eingeholt werden kann.

Neben dem wertvollen Feedback von Endanwendern zu Anforderungen und Usability wollen wir auch möglichst frühes Feedback zu

• interner Passung, d.h. funktioniert das Zusammenspiel von Teilprojekten bzw. Modulen?
• externer Passung, zum Beispiel: kann das System über die vorgesehenen Schnittstellen mit der es umgebenden IT-Landschaft zusammenspielen?

Hierfür bieten sich Integrationspunkte an: definierte Zeitpunkte bzw. Releases, an denen das Zusammenspiel der Komponenten unter möglichst realistischen Bedingungen getestet wird. Idealerweise können wir so auch frühzeitig Genaueres über den Kundennutzen erfahren, am besten geht das natürlich, indem man in den Produktivbetrieb ausliefert.

Paralleles Arbeiten ermöglichen

Wie können wir den Scope so aufteilen und anordnen, dass möglichst viele Leute gleichzeitig daran arbeiten können? Dabei versucht man, Reibungsverluste zu minimieren, muss jedoch Abhängigkeiten und Schnittstellen in Kauf nehmen. Die maximale Parallelität wird erreicht, wenn alle an voneinander unabhängigen Teilen des Systems arbeiten. Das verträgt sich normalerweise nicht mit dem Ziel, wertvolle Teile zuerst auszuliefern. Die Architektur des Systems kann paralleles Arbeiten stark unterstützen oder eben ausbremsen.

Evolutionspfad schaffen

Damit meine ich, dass schon frühzeitig die weitere Entwicklung des Systems (ggf. auch über den Zeithorizont des Projekts hinaus) in den Blick genommen wird. Das ist natürlich vordergründig die Aufgabe der Architektur, aber das Scope-Management kann die Entwicklung der passenden Architektur stimulieren. Denken Sie etwa an ein System, das aus einem Kern und vielen Plugins bestehen soll. Dann bietet es sich an, eine primitive Version des Kerns und ein paar Plugins als erstes zu entwickeln, wobei die Plugins schon einen großen Teil des Spektrums der späteren Anforderungen abdecken. Oder denken Sie an ein API: es empfiehlt sich, das API zusammen mit einem ersten realistischen Client zu entwickeln.

Der Make-or-Buy-Test

Wer kann gutes Scope-Management leisten? Nach welchen Qualifikationen sollten wir suchen, und mit welchen Entscheidungsbefugnissen sollten wir die Rolle „Scope-Manager“ ausstatten? Wir wir oben gesehen haben, braucht man ein tiefgehendes und abteilungsübergreifendes Verständnis für den Wert (Kundennutzen), der mit dem Projektergebnis erreicht werden soll. Dazu gehört fachliche Kompetenz und Erfahrung.

Beim strategischen Scope-Management geht es auch um den Ausgleich von Interessen, und manchmal schmerzhafte Kompromisse, die einzelne Stakeholder zugunsten des Gesamtergebnisses benachteiligen (müssen). Um festzustellen, ob für das Scope-Management ausreichende Befugnis und übergreifendes Verständnis vorhanden ist, benutze ich gern den Make-or-Buy-Test. Er lautet:

Wenn das Scope-Management keine Make-or-Buy-Entscheidungen bewirken kann, dann ist es nicht hoch genug angesiedelt.

Eine Make-or-Buy-Entscheidung zwingt uns, über den durch ein Projekt zu schaffenden Wert zu diskutieren. Erst dann können wir entscheiden, ob wir das gewünschte Ergebnis (zumindest teilweise) besser mithilfe zugekaufter Komponenten erzielen könnten. An vielversprechenden Angeboten mangelt es ja nicht: alles Mögliche ist per API, als Software as a Service (SaaS), oder als Open-Source verfügbar, von der Produktsuche über das Content Management System bis zur Bonitätsprüfung.

Wenn nun die Diskussion über Make or Buy nicht stattfindet, bzw. eine Entscheidung zugunsten von „Buy“ nicht möglich ist, kann das verschiedene Ursachen haben:

• Der Scope ist „von oben“ fest vorgegeben und darf nicht hinterfragt werden.
• Die Aufgaben sind zu kleinteilig formuliert, so dass die Optionen für „Buy“ nicht mehr erkennbar sind.
• Es gibt nicht genug Einblick in den zu schaffenden Wert, daher ist keine Kosten-Nutzen-Abwägung möglich.
• Es gibt keine ausreichende Entscheidungsbefugnis.
• Die fachliche Kompetenz reicht nicht aus, um die Angebote für „Buy“ zu bewerten.

Dies sind allgemeine Warnsignale, dass etwas mit dem Scope-Management nicht optimal läuft, und zwar unabhängig davon, ob wir überhaupt einmal zugunsten von „Buy“ entscheiden würden.

Wer Make or Buy nicht verhandeln kann, der kann auch in anderen Situationen den Scope nicht gut genug verhandeln. Damit wird der Scope zu starr vorgegeben, und die Unsicherheit im Projekt wird sich einen anderen Ausweg suchen: irgendwo zwischen Kosten, Zeit und Qualität.

Übrigens: Auch die Alternative „es von Hand machen“ wird oft voreilig ausgeschlossen, analog zum Make-or-Buy-Test können wir formulieren: Wenn das Scope-Management nicht zugunsten einer manuellen Lösung entscheiden kann, dann ist es nicht hoch genug angesiedelt.

Der Scope Manager

Ich sehe die Rolle des Scope-Managers als eine Person, denn die Abwägungen sind anspruchsvoll, Entscheidungen werden gelegentlich unpopulär sein, und Informationen aus verschiedensten Bereichen müssen in ein Gesamtbild integriert werden. Diese Person darf aus der IT oder aus dem Fachbereich kommen und sollte sich das nötige Hintergrundwissen aus dem jeweils anderen Bereich erarbeiten.

Wenn man nach Vorbildern für diese Rolle sucht, wird man eher im Produktmanagement als imProjektmanagement fündig. So gibt es bei Toyota die Rolle des Chief Engineers, der die Gesamtverantwortung für ein neues Modell trägt, inklusive der ökonomischen Verantwortung. Es ist traditionell ein Ingenieur, der die Auto-Produktion aus eigener Praxis kennt und sich in der Ingenieurs-Hierarchie nach oben gearbeitet hat. Auf der anderen Seite wird erwartet, dass der Chief Engineer sich ein ebenso tiefgehendes Verständnis der Kundenbedürfnisse erarbeitet. So geschehen beim Relaunch des Toyota Sienna im nordamerikanischen Markt, wo der Chief Engineer Yuji Yokoya monatelang durch Kanada, die USA und Mexiko fuhr, um die Wünsche der nordamerikanischen Kunden besser zu verstehen. Eine der vielen Erkenntnisse aus 53000 Meilen auf der Straße: Der Sienna muss als Minivan auf die Bedürfnisse der Eltern und ihrer mitfahrenden Kinder augerichtet sein. Also wurde er u.a. mit einem „conversation mirror“ ausgestattet, der es den Eltern erlaubt, die hinteren Sitze im Blick zu behalten.

Strategisches Scope-Management braucht Gesamtverantwortung in einer Person, die

• tiefgreifendes fachliches Wissen mit Verständnis für den Nutzen verbindet,
• die Abhängigkeiten und Konsequenzen von Entscheidungen kennt,
• das Potenzial neuer Technologien und Herangehensweisen erkennen kann,
• das Zusammenspiel von Organisation, Fachlichkeit und IT steuern kann,
• Entscheider verstehen und beeinflussen kann.

Fazit

Strategisches Scope-Management bedeutet: den Nutzen verstehen und mit den Kosten und technologischen Möglichkeiten in Einklang bringen. Es gehört nicht nur an den Anfang eines Projekts sondern muss von der Idee bis zur Nutzung durchgängig betrieben werden. Allzu oft wird der Projekt-Scope als inhaltlich vorgegeben hingenommen. Strategisches Scope-Management begreift dagegen den Scope konsequent als Variable und schafft damit wertvolle Optionen, sei es für ein vorzeitiges Projektende, Make-or-Buy, oder die Entwicklung von sinnvollen Alternativen.

Mein Fazit lautet daher: strategisches Scope-Management lohnt sich.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

[1] Brook’s Law
[2] The Principles of Product Development Flow: Second Generation Lean Product Development
[3] Michael de la Maza auf Twitter

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.