Teilen!

Einige der populärsten Fragen im Projektumfeld und natürlich auch in agilen Entwicklungsprozessen zeigen eine Rivalität zwischen dem WBS und dem Backlog. Obwohl ein solcher Kampf meiner bescheidenen Meinung nach etwas albern ist, werde ich im Folgenden einige der Fragen beantworten:

  1. Ist es besser, einen WBS oder ein Backlog zu entwickeln?
  2. Warum haben agile Projekte, die mit Scrum oder XP durchgeführt werden, keinen Projektstrukturplan?
  3. Wie kann ich ein Projekt planen, wenn kein Umfang in einem Projektstrukturplan definiert ist?

Hier werde ich all diese Fragen - und noch mehr - beantworten, um Ihnen zu helfen, den Projektstrukturplan (PSP) und die Rückstand.

Was ist ein WBS?

Im Zusammenhang mit Projekten wird eine Work Breakdown Structure (WBS) verwendet. Per Definition ist der WBS ein hierarchische Zerlegung des gesamten Arbeitsumfangs durchgeführt zu werden[1]Basierend auf der neuesten Definition des Project Management Body of Knowledge oder PMBOK Version 7.

Der Projektstrukturplan ist ein leistungsfähiges und nützliches Instrument, wenn es möglich ist, den gesamten Arbeitsumfang zu erfassen, aber was ist, wenn es nicht möglich oder sinnvoll ist, den Projektumfang zu erfassen?

WBS: Schlüsselinstrument in vorausschauenden Umgebungen

Viele Projektleiter glauben, dass die Unfähigkeit, den gesamten Umfang des Projekts zu erfassen, ein Problem der Analyse oder der Planung ist. Auch wenn schlechte Planung häufig zu Problemen führt, ist der Projektstrukturplan kein narrensicheres Instrument.

Der WBS ist sehr nützlich - und nur dort - wo die der Planungskontext ist vorhersehbar. Das heißt, wenn unsere Schätzungen und "Vorhersagen" dessen, was geschehen wird, eine hohe Eintrittswahrscheinlichkeit haben.

Ein Foto eines Apfels in der Hand - als ob er bereit wäre, ihn in die Luft zu werfen.

Schauen wir uns ein Beispiel an. Wenn man einen Apfel in die Luft wirft, kann man ziemlich sicher sein, dass er irgendwann wieder herunterkommt. Sicher, wir könnten uns vorstellen, dass ihn jemand in der Luft auffängt oder dass Außerirdische kommen und den Apfel mit einem Gravitationsstrahl auffangen, aber die Wahrheit ist, dass wir mit fast 100% Sicherheit wissen, dass der Apfel fallen wird. Selbst wenn Sie sich noch an die Parabelbewegung aus der Schule erinnern, können Sie berechnen, wohin er fallen wird. Also starten wir Raketen in den Weltraum und holen die Astronauten nach ihrer Rückkehr zurück. Wir können mit einem hohen Maß an Sicherheit vorhersagen, was passieren wird.

Hier ist der WBS - die Aufschlüsselung des Gesamtumfangs - sehr nützlich. Aber was ist mit einem anderen Umfeld, in dem es nicht möglich oder praktisch ist, das Ergebnis vorherzusehen?

EDT: Mehr Probleme als Nutzen in komplexen und anpassungsfähigen Umgebungen

Stellen Sie sich ein Projekt vor, bei dem Sie keinen geschlossenen Umfang haben. Einige Kontrollfreaks werden sagen, wie ist es möglich, dass ein Projekt ohne einen geschlossenen Umfang existiert? Um meinen Standpunkt zu verdeutlichen, möchte ich eine Anekdote anführen.

Herausforderungen in anpassungsfähigen Umgebungen

Vor einigen Jahren haben wir uns in einem meiner Masterkurse mit dem Konzept der adaptiven Projekte befasst und mit der Notwendigkeit, Projektmanagementmodelle zu entwickeln, bei denen der Umfang nicht definiert oder überhaupt nicht klar ist, oder bei denen wir trotz der Definition davon ausgehen, dass er sich ändern wird.

Eine Teilnehmerin kam zu mir und sagte: "Das ist der erste Kurs in diesem Masterstudiengang, der für meine Arbeit Sinn macht", und erklärte mir, dass für sie der Projektstrukturplan, der detaillierte Aktivitätenplan und das Budget - als Ergebnis einer solchen Aufschlüsselung und Konstruktion des Plans, eines TOP-DOWN-Ansatzes - echter Unsinn sei.

Der Grund für diese Behauptung? Sie arbeitete in der wissenschaftlichen Forschung und erklärte, dass das größte Problem darin bestehe, dass diese "prädiktiven" Konzepte auch von den Stellen gefordert würden, die Forschungsmittel zuweisen. Um Zugang zu Forschungsmitteln zu erhalten, mussten sie und ihr Team einen detaillierten Zeitplan für die Aktivitäten und ein Budget vorlegen.

Wie kann man Projekte mit variablem Umfang durchführen, ohne einen Projektstrukturplan zu haben?

Es besteht die Notwendigkeit, Projekte ohne einen geschlossenen oder definierten Rahmen durchzuführen, und das methodische Problem ist nicht unerheblich. Wir sehen das in der wissenschaftlichen Forschung, aber auch in den Innovationsbereichen: Könnte man einen Innovationsbereich auffordern, zu Beginn des Jahres einen detaillierten Zeitplan für seine Aktivitäten vorzulegen? Oder könnten wir in den Bereichen Marketing und Werbung oder Imagemanagement die Reaktion der Öffentlichkeit auf ein bestimmtes Thema vorhersehen? Was, wenn keine Zeit für Marktforschung bleibt?

Daher verwenden wir in dieser Art von Szenario flexiblere und weniger prädiktive Strukturen. Dies ist der Ort, an dem die Rückstand als eine der Alternativen.

Warum funktioniert der WBS nicht als Backlog?

Kehren wir zur Definition des WBS zurück: hierarchische Zerlegung des gesamten Arbeitsumfangs. Hier geht es um den Gesamtumfang und die hierarchische Zergliederung.

Vier Unterschiede zwischen dem Backlog und dem WBS

  1. Der Umfang. Alles, was im Projektstrukturplan enthalten ist, muss fertiggestellt werden, um das Projekt abzuschließen. Der Rückstand hingegen kann Elemente mit niedriger Priorität enthalten, die nie geliefert werden.
  2. Prioritäten. Der Projektstrukturplan setzt keine Prioritäten, daher wird die Arbeit nach der Logik der Lösung oder der Konstruktion des Ergebnisses optimiert (Optimierung des Produktionsprozesses). Das Backlog wird nach dem Wert für das Unternehmen optimiert, was bedeutet, dass es manchmal möglich ist, etwas zu tun und es dann "anders zu machen" oder "zu ändern", um den wahrgenommenen Wert zu erhöhen.
  3. Struktur. Der Projektstrukturplan ist hierarchisch aufgebaut, und obwohl es sich nicht um eine Faustregel handelt, verwenden viele eine solche Hierarchie, um Phasen oder vergleichbare Ebenen festzulegen - d. h. Ebene 0, Endprodukt, Komponenten oder Projektphasen der Ebene 1, Kontrollkonten der Ebene 2 und so weiter. Das Backlog kann, entgegen der landläufigen Meinung, Elemente unterschiedlicher Art enthalten, wie z. B. User Stories, Epics, Fixes, Enhancements, Use Cases, Point Requirements.
  4. Geschäftswert. Viele Leute nehmen in den Projektstrukturplan - genauer gesagt in das Projektstrukturplan-Wörterbuch - die Kosten für die Ausführung einer bestimmten Komponente oder eines bestimmten Elements der Gliederung auf. Der Rückstand kann diese Kosten enthalten - das ist nicht verboten -, aber sie werden nach ihrem Wert, d. h. dem Nutzen, den sie darstellen, priorisiert. Kosten und Nutzen sind nicht immer dasselbe, etwas, das kostengünstig ist, kann für das Unternehmen sehr vorteilhaft sein und umgekehrt.

Wir könnten wahrscheinlich noch über andere Unterschiede sprechen, aber dies sind meiner Meinung nach die wichtigsten.

Besser ein WBS oder ein Backlog?

Weder noch. Der Projektstrukturplan ist von zentraler Bedeutung und sehr nützlich, wenn Ihr Projekt erfordert, dass Sie die Kontrolle über den Umfang haben - was erledigt wird, was nicht erledigt wird und wann wir diskutieren, ob wir eine dieser beiden Antworten ändern.

Der Rückstand hingegen fördert die Anpassungsfähigkeit. Wenn sich also der Umfang Ihres Projekts ändert oder Sie sich auf Feedback-Zyklen zur Anpassung des Umfangs verlassen, benötigen Sie ein Backlog, und das Führen eines Projektstrukturplans kann Ihnen Kopfzerbrechen bereiten.

Ist es möglich, den WBS und das Backlog gleichzeitig in einem Projekt zu verwenden?

Auch wenn man auf den ersten Blick sagen könnte... WAS FÜR EIN NONSENSE. Die Wahrheit ist, dass dies möglich und manchmal auch notwendig ist. Stellen Sie sich ein großes Projekt vor, bei dem eine der Komponenten die Entwicklung einer mobilen Anwendung ist. Obwohl es sich um ein größeres Projekt handelt, das z. B. die Schulung des Außendienstes, die Einführung von Werbeprodukten, Veranstaltungen und andere vorhersehbare Aktivitäten umfasst, wird die Entwicklung selbst - die als Arbeitspaket oder Kontrollkonto betrachtet werden kann - dynamisch verwaltet, indem Dauer und Kosten im Plan festgelegt werden.

Es mag Ihnen etwas "verworren" vorkommen, aber sind alle Projekte einfach? Wir haben nicht immer das Szenario im Buch, das von 100% prädiktiven oder 100% agilen Projekten spricht. Außerdem hoffe ich, dass diese "Differenzierung" in Zukunft verschwinden wird, da sie nur zu einer weiteren Spaltung führt.

Wie schätzt man die Kosten eines Projekts ohne WBS oder geschlossenen Umfang?

Also, zurück zu den schwierigen Fragen. Obwohl es mehr als eine richtige Antwort gibt, entscheiden wir uns für die wahrscheinlichste Option.

Wenn ein Projekt ohne einen geschlossenen oder vollständig definierten Umfang beginnen muss, ist es am besten, ein Zeit- und Budgetlimit festzulegen, um ein Ergebnis zu validieren - geschäftlich oder sozial. Als wir beispielsweise entdeckten, dass wir als Gesellschaft an einem Impfstoff gegen eine neue Krankheit arbeiten sollten, stellten viele Regierungen und Privatunternehmen einen festen Geldbetrag - eine Haushaltslinie - zur Verfügung und gaben den Labors Fristen oder Zeitfenster für die Vorlage der Ergebnisse vor.

Diese Projekte mit "festen" Kosten und Zeitaufwand werden mit dem Ziel der "Gewinnmaximierung" verwaltet. Mit anderen Worten: Ich weiß nicht, was dabei herauskommen wird, aber es wird das beste Ergebnis sein, das wir in der zur Verfügung stehenden Zeit und mit den zur Verfügung stehenden Mitteln erreichen können.

Das bedeutet, dass einige Labors in der Lage waren, einen Impfstoff zu finden, während es anderen einfach nicht gelang, und die Projekte abgebrochen wurden.

Manche mögen solche Ansätze als "Glücksfall" empfinden, doch in vielen Bereichen wie Unternehmertum und Innovation sind sie das einzige logische und konsistente Modell.

In diesem Fall ist es wichtig, dass eine der Variablen, nämlich das Budget oder der Umfang, streng eingehalten wird. Andernfalls werden wir uns in einem Projekt wiederfinden, das kein Ende hat, keine Verpflichtungen eingeht und keine Ergebnisse liefert.

Teilen!

Kommentare und Anmerkungen des Autors[+]

Standardbild
Alberto Dominguez

Führung von Teams von der Theorie bis zur tatsächlichen und nachhaltigen Bereitstellung innovativer IT-Produkte und -Dienstleistungen.

Artikel: 35

2 Kommentare

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

de_DE