Top-Down oder Bottom-Up: Whitepaper

Dieses Whitepaper ist Teil unserer Sammlung "Aus der Praxis". Es diskutiert Projektmanagement, Portfoliomanagement und Aufgabenmanagement und vergleicht die zugehörigen Top-Down- und Bottom-Up-Managementpraktiken.

Eine Word-Version dieses Whitepapers können Sie unter Top-Down oder Bottom-Up: Whitepaper (Project Server 2010) herunterladen.

Weitere Whitepapers finden Sie unter "Aus der Praxis" – Whitepapers.

Top-Down oder Bottom-Up?

"Wir brauchen Projektmanagement… Hmmm, ich meinte Portfoliomanagement… Hmmm, eigentlich meinte ich tatsächlich Aufgabenmanagement… Zum Teufel, wir brauchen das alles.", ist ein Schlachtruf, den ich häufig höre. Es ist kein Mangel an Definition dieser drei Konzepte, die Verwirrung stiften, sondern ihre Ähnlichkeit.

Jene von uns, die schon ein paar Jahre in der IT-Branche arbeiten, sehen Dinge häufig von einer technischen Warte aus, was uns nicht immer dienlich ist. Wenn wir und Daten aus dem Portfoliomanagement, dem Projektmanagement und dem Aufgabenmanagement ansehen, sehen die möglicherweise recht ähnlich aus. Bei allen dreien gibt es ein ID-Feld, ein Beschreibungsfeld sowie ein Anfangs- und Enddatum. Diese drei miteinander zu verknüpfen, sollte also eine ganz natürliche Sache sein.

Vielleicht aber auch nicht.

Sehen wir uns diese drei Konzepte mal eins nach dem anderen an. Ihre Ähnlichkeiten lassen sich einfach sehen, aber es gibt grundlegende Unterschiede in den drei Betrachtungsweisen.

Portfoliomanagement – ein Top-Down-Ansatz

Unter "Portfoliomanagement" kann man eine Menge unterschiedliche Dinge verstehen, aber die gängigste Bedeutung dürfte wahrscheinlich Projektauswahl und -priorisierung sein. Die Prinzipien betreffen letztendlich jeden in der Organisation, aber von großem Interesse ist der Prozess für das Senior Management. Das Management beginnt mit bestimmten Rahmenbedingungen, z. B. verfügbares Gesamtbudget, und der Notwendigkeit, folgende Frage zu beantworten: "Was können und sollten wir mit dieser Menge Geld erreichen?". Wenn der Portfoliomanagementprozess ausreichend ausgereift ist, umfasst diese Analyse eventuell nicht nur neue Ideen, sondern auch schon bestehende Projekte.

Dashboard mit Anzeige des Status für mehrere Projekte

Um einen Prozess für die Portfolioauswahl und -priorisierung zu entwickeln, muss sich das Management damit auseinandersetzen, von welchen Geschäftsfaktoren das Unternehmen angetrieben wird, und sich im Vorfeld auf die Metriken einigen, die bei der Betrachtung neuer und bestehender Projekte herangezogen werden. Sollte die Investitionsrendite eine Hauptmetrik sein? Vielleicht sollten wir Auswirkungen auf die Kundenzufriedenheit oder die Mitarbeiterbindung oder die Ausrichtung an strategischen Zielen berücksichtigen. Wie auch immer die entscheidenden Metriken lauten, das Management muss jedes Projektvorhaben unter dem Blickwinkel abwägen, wie dieses Projekt jene Ziele voranbringen kann und wie sich jedes Projekt im Vergleich zu Alternativmaßnahmen darstellt, für die das Geld ausgegeben werden könnte.

Hierbei handelt es sich um einen hoch analytischen Prozess, selbst wenn er nur im Kopf abläuft. Er ist mit Sicherheit hoch analytisch, wenn Sie Projektportfoliomanagement-Software (PPM) einsetzen. Selbst, nachdem die Analyse aus der Software in Form eines Berichts oder Diagramms gewonnen wurde, gibt es praktisch immer eine Übersicht auf Managementebene, wo eine endgültige Entscheidung über die Prioritäten gefällt wird. Wenn dieser Prozess abgeschlossen ist, müssen die endgültigen Ergebnisse an diejenigen übermittelt werden, die jedes einzelne der Projekte managen werden. Die Effekte dieser Entscheidungen bestehen in der Finanzierung mancher Projekte und in der Nichtfinanzierung anderer Projekte, darin, für manche Projekte (und nicht für andere) Ressourcen mit höherer Priorität verfügbar zu machen, sowie darin, den Zeitplan einiger Projekte zu forcieren, während andere Projekte etwas zurückgestellt werden.

Projektmanagement – Top-Down und Bottom-Up

Sobald ein Projekt einmal genehmigt ist, wechselt es in einen vollkommen anderen Bereich. Jetzt rückt die klassischere Sichtweise der Projektplanung in den Fokus. Jetzt müssen wir das "Ding", das wir in unserer geschäftlichen Rechtfertigung vor der Genehmigung beschrieben haben, tatsächlich realisieren.

Ein Projektmanager beginnt, in Dimensionen von Projektumfang und -ergebnissen zu denken. Der Projektmanager kennt das endgültige Produkt, dass realisiert werden muss, sei es eine Softwarekomponente oder ein bezugsfertiges Gebäude. Er denkt an die Hauptphasen des Projekts und erstellt eine Aufgabenverteilungsstruktur.

Hauptphasen eines Projekts, in einem Diagramm dargestellt

Es wird ein kritischer Pfad logischer Schritte entworfen, die erforderlich sind, um das Projekt zum Abschluss zu bringen. Der Projektmanager weißer außerdem, dass er oder sie für den erzeugten Zeitplan verantwortlich gemacht werden wird, weshalb er oder sie sich mit einer breiten Palette von Fachleuten innerhalb des Projekts beraten wird. Der Projektmanager erstellt eine Bottom-Up-Ansicht des Projekts, indem er aufgabenweise vorgeht und die Aufgaben zu Projektphasen zusammenfasst und diese schließlich zum Gesamtprojekt selbst. Zu diesem Zeitpunkt beginnt der Projektmanager eventuell auch schon damit, Ressourcen nach Fähigkeiten, nach Abteilungen oder sogar schon namentlich zuzuordnen. Diesen Ressourcen werden möglicherweise Kosten zugewiesen. Als Ergebnis der Berechnung der Dauer der Aufgaben, der erforderlichen Ressourcen und ihrer Kosten erhalten wir eine Bottom-Up-Abschätzung des Projekts.

So weit, so gut.

Ansicht eines Projekts als Gantt-Diagramm

Wenn wir uns nun aber den Top-Down-Ansatz des Projektportfolioauswahl-Prozesses ansehen, gab es auch da Kosten. Tatsächlich waren die geschätzten Kosten Bestandteil der geschäftlichen Rechtfertigung, die vom Management berücksichtigt wurde, als das Projekt genehmigt wurde. Wenn wir nun erst die Bottom-Up-Abschätzung des Projekts aus dem vereinten Fachwissen der Fachleute erhalten, auf welcher Basis wurde dann die Projektauswahl im Management getroffen?

Gute Frage! In manchen Organisationen erhält das Projekt eine grobe Schätzung durch die Projektabteilung, um eine geschäftliche Rechtfertigung für das Projekt beizubringen. In anderen Organisationen wird, noch bevor ein Projekt im Portfolioprozess berücksichtigt wird, eine vollständige Bottom-Up-Abschätzung durchgeführt. Das Problem bei beiden Ansätzen ist, dass sie aufwändig sind. Eine vollständige Abschätzung kann eine Menge Aufwand bedeuten, wobei die Genehmigung des Projekts, um eine Finanzierung jeglichen Aufwands zu erhalten, überhaupt noch aussteht. Somit gibt jemand aus dem Management einfach eine Schätzung über die Höhe der für dieses Projekt zu erwartenden Kosten ab.

Der Prozess sieht zwar vollständig integriert aus, doch könnte hier durchaus eine Zwickmühle auftreten. Was ist zuerst da, die auf die Abschätzung verwandte Arbeit oder die Auswahl des Projekts, um in der Lage zu sein, Zeit auf das Projekt zu verwenden?

Ferner, was geschieht, wenn die Bottom-Up-Abschätzung nicht mit der Schätzung des Portfolioauswahlprozesses übereinstimmt? Ist die Abschätzung niedriger, gibt es wahrscheinlich kein Problem, aber wenn die Arbeit nicht innerhalb des von den Portfolioauswahlverantwortlichen geschätzten Zeit- und/oder Budgetrahmens abgeschlossen werden kann, liegt ein Konflikt vor.

Sie denken vielleicht, dass es da natürlichste wäre, das Senior Management erneut zusammenzurufen und das Problem einfach zu besprechen, aber es gibt eine Menge von Situationen, in denen das nicht so einfach ist, wie es den Anschein hat.

Zuallererst ist die Portfolioauswahlgruppe selten mit den Projektmanagementmitarbeitern identisch. Senior Projektmanager sind praktisch immer Bestandteil der Portfolioauswahlgruppe, aber die Gruppe selbst besteht auch aus leitenden Senior Managern, für die es schwierig ist, die Zeit zu finden, um alle zusammenzubringen. Zweitens trifft sich die Auswahlgruppe eventuell nur unregelmäßig, weshalb es eine große Herausforderung darstellen kann, alle wieder an einen Tisch zu bekommen, um alle Konsequenzen einer Abweichung der Projektkosten von der Schätzung zu diskutieren. Schließlich gibt es Unternehmenskulturen, in denen es nicht gerade der Karriere förderlich sein dürfte, dem Senior Management mitzuteilen, dass seine Schätzungen hinsichtlich eines geeigneten Zeitplans und Budgets für dieses Projekt vollkommen falsch sind.

Aufgabenmanagement – ein Bottom-Up-Ansatz

Wenn wir an Aufgabenmanagement denken, denken wir in der Regel sehr operational, also durchführungstechnisch, was uns dann meistens zu unserer täglichen Agenda und einem Produkt wie Outlook führt.

Ansicht einer Aufgabenliste

In diesem Moment arbeiten wir auf Ebene einer einzelnen Person oder von Mitgliedern eines kleinen Teams. Wir sehen die Aufgaben nicht im Kontext. Wir sehen die Dinge, die wir übernommen haben, oder die, um deren Übernahme wir ein Teammitglied gebeten haben. Dies ist nun überhaupt keine analytische Betrachtungsweise. Es gibt zu erledigende Aufgaben, und der Einzelne hat versprochen, sie zu erledigen.

In seinem Kern ist Aufgabenmanagement sehr geradlinig. Sie erledigen die Aufgabe, und wenn Sie fertig sind, teilen Sie der Person, von der Ihnen die Aufgabe übertragen wurde, mit, dass Sie sie erledigt haben. Sämtliche Funktionen hierfür sind bereits in Outlook enthalten.

Das Dumme an ähnlichen Daten

Es gibt eine Redensart: "Wenn es wie eine Ente aussieht und wie eine Ente schnattert, muss es eine Ente sein." Das mag auf Enten zutreffen, ist aber bei aufgabenbasierten Daten nicht immer richtig.

Betrachten wir folgende drei Ebenen projektorientierter Daten:

  • Auf der Portfolioebene haben wir ein Projekt und vielleicht Phasen unterhalb dieses Projekts. Die Phaseninformationen enthalten vielleicht eine Codenummer, eine Beschreibung, eine Dauer sowie ein Anfangs- und Enddatum..

  • Auf Projektebene haben wir ein Projekt und Aufgaben unterhalb dieses Projekts. Die Aufgabeninformationen enthalten vielleicht eine Codenummer, eine Beschreibung, eine Dauer sowie ein Anfangs- und Enddatum..

  • Auf Aufgabenmanagementebene haben wir eine Aufgabe, und die Aufgabeninformationen enthalten vielleicht eine Codenummer, eine Beschreibung, eine Dauer sowie ein Anfangs- und Enddatum..

Mit Sicherheit sehen sie identisch aus, aber durch den Betrachtungswinkel der Daten dient jeder dieser eher allgemeinen Datensätze einem sehr unterschiedlichen Zweck.

Ich werde oft gefragt: "Kann ich Daten aus der Portfolioansicht in die Projektansicht und nach Outlook und dann wieder zurück verschieben?"

Auf kurze Antwort auf diese Frage lautet: "Ja."

Aber in unserer Firma haben wir ein Mantra, das wir immer "beten", wenn wir technische Ratschläge erteilen: "Sag mir nicht, wie ich es machen soll, sag mir, warum du es tun solltest."

  1. Um den Punkt zu verdeutlichen, stellen Sie sich folgendes Beispiel vor. Wir bauen eine vollständig integrierte Umgebung auf. Am oberen Ende der Skala haben wir eine per Portfolio organisierte Liste mit Projekten. Wir wählen diese Projekte nicht nur aus, sondern wir treiben die Integration noch weiter, indem wir sie, nachdem sie vom EPM-System aktiviert wurden, verfolgen. Hierzu verwenden wir Funktionen, die uns bereits zur Verfügung stehen, um das Projekt mit den Phasendefinitionen von der Portfolioseite unseres integrierten Systems auf die Projektseite des Systems zu verschieben. Die Daten sehen identisch aus.

  2. In unserem Enterprise Project Management-System nehmen wir nun eine detailliertere Definition vor, indem wir die ursprünglichen Phasen aus der Portfoliodefinition verwenden, die von oben nach unten (Top-Down) verschoben wurde. Hierdurch ermöglichen wir eine gleichzeitige Aktualisierung der Zusammenfassung im Portfoliosystem, wenn wir unsere Projekte aktualisieren. Wir erstellen viele Aufgaben und weisen zahlreiche Ressourcen zu. Nun nehmen wir eine Ressourcenabgleichsanalyse vor, um unsere Kapazität über viele Projekte hinweg zu bestimmen.

  3. Wir verwenden unsere Ressourcenzuweisungen, um Aufgaben- und Zuweisungsdaten an jeden Benutzer als Outlook-Aufgabe oder -Kalenderereignis zuzustellen. Benutzer müssen nicht mehr zu einem "Projektmanagementsystem" wechseln. Sie können ihre Daten jetzt einfach in ihrer täglichen Agenda sehen. Die Daten sehen aus wie in der Projektliste und sind in Aufwärtsrichtung mit der Portfolioansicht verknüpft.

  4. Der Status dieser Aufgaben und die Verfügbarkeit werden nun wiederum über Outlook aus dem Individualsystem zurück in das Projektmanagementsystem übernommen, wobei gleichzeitig Schätzungen übermittelt werden, wie lange der Abschluss der jeweiligen Arbeiten dauern wird. Die Daten sehen genauso aus, wie in den anderen beiden Systemen, weshalb das Verschieben der Daten recht einfach ist.

Ein solches System lässt sich technisch relativ einfach mithilfe der Tools einrichten, die uns bereits zur Verfügung stehen, plus ein bisschen Konfigurations- und Entwicklungsarbeit. Und es wäre eine wunderbare Demonstration.

Nach dieser Art von Struktur werden wir regelmäßig gefragt. Aber selbst, wenn wir es machen können, warum sollten wir?

Stellen Sie sich das mal auf Aufgabenebene vor. Eine Person nimmt den Morgen wegen eines dringenden, kurzfristig vereinbarten Zahnarzttermins frei und aktualisiert Outlook mit der Information, dass sie am Vormittag nicht verfügbar ist. Das sind schlechte Nachrichten für den Mitarbeiter, aber die störenden Auswirkungen auf das Projekt könnten dramatisch sein. Denn jetzt berechnet das Projektsystem, dass die Aufgabe, deren Abschluss für diesen Vormittag geplant war, heute nicht mehr erledigt wird, sondern erst morgen Mittag. Pflichtschuldig kontrolliert es den kritischen Pfad und alle von dieser Aufgabe abhängigen bzw. darauf nachfolgenden Aufgaben (downstream), und verschiebt sie um vier Stunden in die Zukunft. Hiervon könnten Hunderte von Aufgaben betroffen sein. Das Ergebnis wäre möglicherweise, dass sich das Abschlussdatum des gesamten Projekts um einen halben Tag verzögert. Andere Projekte werden ebenfalls davon beeinflusst, weil die Aufgaben anderer Mitarbeiter dieses Projekts nun neu geplant werden müssen, und die Portfolioansicht selbst verschiebt sich um ein paar Pixel nach vorne.

Wenn wir uns das in Echtzeit vorstellen, wird das Problem noch größer. Hunderte oder Tausende von Leuten nehmen den ganzen Tag lang Änderungen vor, und die EPM-Ansicht, die Ressourcenkapazitätsabgleichs-Ansicht und die Portfolioansicht springen durch die Effekte hin und her.

In der Realität kommt es nicht dazu. Zuallererst wird der glücklose Zahnarztpatient mittags wieder auf seinem Posten sein und vielleicht einfach ein paar Stunden länger arbeiten, um sicherzustellen, dass der kritische Pfad eingehalten wird, sodass am nächsten Morgen wieder alles nach Plan läuft.

Darüber hinaus, selbst wenn die Daten identisch aussehen, sind sie niemals auf diese Weise integriert, um genau dieses Effekte abzufangen.

Datenkontext – die Perspektive ist entscheidend

Wenn wir Daten betrachten, ist deren Kontext von entscheidender Bedeutung. Daten, die gemäß einem datensatzbasierten Schema identisch aussehen können, werden auf Grundlage der Sichtweise der Anwendung für sehr unterschiedliche Zwecke verwendet.

In einer Top-Down-Portfolioansicht treffen wir strategische Entscheidungen darüber, wo Ressourcen einzusetzen sind, um die Investitionsrendite zu maximieren. Wir könnten Entscheidungen treffen, die ein Projektmanager nicht treffen würde. In meiner eigenen Organisation wählen wir manchmal Projekte aus, die vollständig außerhalb unseres Kompetenzrahmens liegen, wohl wissend, dass wir bei ihrer Umsetzung furchtbar ineffektiv sein werden. Aber genau, um diese Kompetenzen zu verbessern, machen wir es. Die Investitionsrendite besteht dann nicht in einer effektiven Installation, sondern in geschultem Installationspersonal. Dies ist eine analytische Betrachtungsweise.

In einer taktischen Projektansicht treffen wir operationale Entscheidungen darüber, wo wir den besten Durchsatz mit unserem Personal erzielen können und wie wir unsere Projekte so schnell und effizient wie möglich abschließen können. Das Auge eines Projektmanagers ist immer in die Zukunft gerichtet. Die Ereignisse der Vergangenheit sind für einen Projektmanager nur insofern von Interesse, als sie die Sicht auf die Zukunft verbessern. Dies ist ebenfalls eine hoch analytische Betrachtungsweise.

In einer Aufgabenmanagementansicht wie einer Agenda sind wir nicht analytisch. Eine Agenda ist ein Verpflichtungssystem. Wir versprechen uns selbst oder anderen, dass wir bestimmte Dinge zu einer bestimmten Zeit ausführen werden. Dies könnte in die analytische Sichtweise passen. Oder auch nicht.

Werden diese Perspektiven und Kontexte gemischt, ohne die Auswirkungen zu kennen, kann dies zu Chaos führen.

Top-Down oder Bottom-Up?

Es gibt, wie immer, keine richtige Antwort. Manche Aspekte Ihres Projektmanagementsystems müssen wirklich von unten nach oben (Bottom-Up) aufgebaut sein. Letztendlich werden Individuen das realisieren, womit sich Ihr Projekt auch immer beschäftigt. Aber manche Entscheidungen werden von ganz oben getroffen (und müssen dies auch), weshalb sie notwendigerweise von oben nach unten (Top-Down) angelegt sind.

Wenn Sie die Unterscheidung zwischen den Zwecken, für die jede Ebene des Projektmanagementparadigmas bestimmt ist, beibehalten, lässt sich deutlicher sehen, ob manche dieser Systeme tatsächlich integriert werden sollten oder nicht. Wenn der Prozess und die Denkweise einer Ebene keinen direkten Vorteil durch ihre vollständige Integration mit einer anderen Ebene liefert, ist Integration nicht die beste Vorgehensweise. Es ist wichtig, dass Sie durchspielen, wie eine solche Integration in einem realen Kontext funktionieren würde, und ob die Häufigkeit und Detailgenauigkeit der einen Ebene der anderen einen Nutzen liefert.

Diagramm, dass einen Workflow darstellt

Wenn sich beispielsweise ein Lenkungsausschuss einmal im Quartal trifft, um groß angelegte Entscheidungen darüber zu treffen, welche Projekte voranzubringen sind, und welche nicht, worin liegt dann der Nutzen, deren Ansicht jeden Tag, jede Woche oder sogar jeden Monat zu aktualisieren?

Muss der EPM-Algorithmus für den Ressourcenabgleich wirklich den Zahnarzttermin einer einzelnen Person sehen, oder reicht es nicht aus, dass er die ungefähre Verfügbarkeit dieser Person kennt?

Und andererseits, wenn wir eine Zuweisung direkt an die Agenda oder die Arbeitszeittabelle einer einzelnen Person schicken könnten, würde ihr dies jeden Tag ein paar Minuten Zeit sparen, weil sie nicht jedes Mal das System wechseln muss, um dieselben Daten zu sehen?

Unter manchen Umständen ist also Top-Down richtig und unter anderen Bottom-Up. Sie müssen Ihre eigene Situation betrachten, um zu sehen, wo sich die Integration dieser Tools und Konzepte mit den richtigen Dividenden auszahlen kann, bevor Sie sie aneinander binden.

Informationen zum Autor

Chris Vandersluis ist der Präsident und Gründer von HMS Software, einem im kanadischen Montreal ansässigen Microsoft Certified Partner. Er hat einen Abschluss in Wirtschaftswissenschaften von der McGill University und mehr als 30 Jahre Erfahrung in der Automatisierung von Projektsteuerungssystemen. Er ist ein langjähriges Mitglied des PMI (Project Management Institute) und hat geholfen, die Ortsverbände der Microsoft Project-Benutzergruppen (MPUG) in Montreal, Toronto und Quebec zu gründen. Vandersluis hat Beiträge in Fortune, Heavy Construction News, im Magazin "Computing Canada" und im PMNetwork von PMI veröffentlicht. Darüber hinaus verfasst er regelmäßig die Leitartikel für Project Times. Er unterrichtet Projektmanagement für Fortgeschrittene an der McGill University und hält häufig Vorträge auf Veranstaltungen der Project Management Association in Nordamerika und weltweit. HMS Software ist der Herausgeber von TimeControl, einem projektorientierten Zeiterfassungssystem, und seit 1995 ein Microsoft Project Solution Partner.

Sie können Chris Vandersluis per E-Mail kontaktieren: chris.vandersluis@hms.ca

Wenn Sie weitere EPM-bezogene Artikel von Chris Vandersluis lesen möchten, besuchen Sie die EPM Guidance-Website von HMS (http://www.epmguidance.com/?page_id=39).

Teilen Facebook Facebook Twitter Twitter E-Mail E-Mail

War diese Information hilfreich?

Sehr gut. Noch anderes Feedback?

Was können wir verbessern?

Vielen Dank für Ihr Feedback!

×