Sie sagen, sie wollen eine Lösung: Whitepaper

Dieses Whitepaper ist Teil unserer Sammlung "Aus der Praxis". Es beschreibt einige der häufigeren Herausforderungen, die Ihnen möglicherweise beim Planen von Projekten begegnen. Es beschreibt das Finden des besten Ansatzes, um zu bestimmen, wie lang Vorgänge sein sollten und wie viele Vorgänge in einem optimierten Projektplan definiert werden sollten. Es wird erörtert, in welcher Weise verschiedene Branchen normalerweise verschiedene Arten von Plänen erfordern (z. B. Softwareentwicklung, EPC (Engineering-Procurement-Construction) und Betriebsschließungen). Ferner werden verschiedene Faktoren für die Wahl der Projektauflösung erläutert (z. B. die Länge des Projekts, die beteiligten Ressourcen, die Verwaltung oder Einteilung von Ressourcen, Geschwindigkeit und Aufwand der Informationsbeschaffung und Zeitpläne für die Datenaktualisierung).

Die Word-Version dieses Whitepapers finden Sie unter Sie sagen, sie wollen eine Lösung : Whitepaper (Project Server 2010).

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

Sie sagen, sie wollen eine Lösung

Entschuldigung bei den Beatles für das ungeschickte Wortspiel, aber das heutige Thema ist die Auflösung Ihres Projekts.

Es gibt viel Material darüber, wie man einen Zeitplan erstellt, aber zu einer der schwierigsten Lektionen findet sich kaum etwas – wie viele Vorgänge sollten Sie in Ihrem Projektplan erfassen, und wie lang sollte jeder Vorgang sein?

Ich werde regelmäßig mit Projektplänen konfrontiert, die unglaublich komplex erscheinen, oder mit Projektmanagern, die nicht imstande sind, die Probleme in ihrem Projektplan dingfest zu machen, da der Zeitplan auf einer zu hohen Zusammenfassungsebene gestaltet ist. Ich habe ein Projekt gesehen, das sich über mehr als 100 Jahre erstreckte (ja, wirklich), dessen Länge vollkommen angemessen war und das einige Vorgänge mit jahrzehntelanger Laufzeit umfasste. Ich habe auch Projektpläne gesehen, die nur eine Stunde oder noch kürzer dauerten, deren Länge ebenfalls vollkommen angemessen war, und in denen einige Vorgänge nur eine einzelne Minute dauerten. Ich habe Projekte mit nur einer handvoll Vorgänge gesehen und andere mit mehr als 100.000 Vorgängen.

Die Software, die wir heute verwenden, kann tausende Vorgänge und eine große Bandbreite von Zeitdauern verarbeiten.

Also, was ist nun der richtige Ansatz?

Wie lang sollen Vorgänge sein, und wie viele sollten wir verwenden, um den Projektplan zu optimieren? Das bezeichne ich als die Auflösung des Projekts.

Ein jeder nach seinem Geschmack

Da die Anforderungen für verschiedene Branchen, verschiedene Arten von Projekten und verschiedene Situationen jeweils andere sind, sollten wir uns die Grundlagen der Entscheidung für die Anzahl der Vorgänge in einem Zeitplan und die Länge der einzelnen Vorgänge ansehen.

Naturgemäß sind für verschiedene Arten von Projekten verschiedene Arten von Projektplänen geeignet. Betrachten wir drei verschiedene Beispiele:

  1. Softwareentwicklung   . Viele Softwareprojekte weisen gemeinsame Merkmale auf. Zwar ist jedes Softwareprojekt einzigartig, doch gibt es normalerweise eine Entwurfsphase, eine Programmierphase, eine Qualitätssicherungsphase, eine Dokumentationsphase und eine Entwicklungsphase. Softwareprojekte bemessen sich normalerweise in Wochen oder Monaten, und das ergibt fast schon aus sich heraus Vorgänge, die zwischen einem Tag und zwei Wochen lang sind. Die Ressourcenzuordnung wird hier häufig Einzelpersonen zugeteilt.

    Teams, die sich bei der Softwareentwicklung der agilen Vorgehensweise verschrieben haben, richten den Blick auf kurze "Sprints" von einer oder zwei Wochen Dauer und arbeiten innerhalb dieser Sprints Vorgänge von kurzer Dauer ab, während sich die Gesamtdauer der Projekte noch immer im Bereich von Wochen bewegt. Über agile Entwicklung später mehr.

    Ansicht von agilen Sprints als Gantt-Diagramm
  2. EPC – Engineering-Procurement- Construction   . Es sind die EPC-Projekte, bei denen die Methode des kritischen Wegs ihren Anfang nahm. Bei dieser Art von Projekten wird etwas sehr großes entwickelt. Dabei könnte es sich um ein großes Verteidigungsprojekt, wie das Polaris Missile-Projekt, in dem die PERT-Diagramme ihren Ursprung haben, oder eine Offshore-Ölbohrplattform, ein neues Schiff oder ein Kraftwerk handeln. In diesen Projekten gibt es eine Konstruktionsphase, in der das fertige Projekt konzipiert wird. Die Entwicklungsphase weist normalerweise eine Reihe von Aspekten auf, die noch nie zuvor verwirklicht wurden. Die Beschaffungsphase befasst sich mit dem Auffinden, der Vertragsvergabe und der Lieferung von Gütern oder Leistungen für das Projekt. In der Konstruktionsphase wird das Endprodukt konstruiert und schließlich zur Verwendung freigegeben. Projektpläne für EPC-Projekte umfassen normalerweise viele Monate oder sogar Jahre, und die Einzelvorgänge dauern von zwei Wochen bis zu mehreren Monaten. Es ist keineswegs ungewöhnlich, bei einem derartigen Projekt zwischen 5.000 und 20.000 Vorgänge abzuarbeiten. Die Ressourcenzuteilung orientiert sich hier nahezu immer an der Qualifikation statt an Einzelpersonen, und (nur, um keine Langeweile aufkommen zu lassen) es kann viele Unterprojekte geben, die zur einfacheren Verwaltung in einem Programm oder Masterprojekt zusammengefasst werden.

    Gantt-Diagrammansicht von mehreren Projekten und Unterprojekten
  3. Betriebsschließung   . Der Projektplan für eine Betriebsschließung und der Zeitablauf für Wartungsarbeiten ist eine der größten denkbaren Herausforderungen für die Projektplanung. Die Schließung einer Fabrik zu Wartungszwecken gibt es in zwei Geschmacksrichtungen: planmäßig und Notfall. Lassen wir den Notfall zunächst beiseite – er bildet ohnehin eine eigene Welt. Die Dauer der geplanten Betriebsschließung hängt stark von der Art der Fabrik ab. Ein Block eines Kernkraftwerks, kann beispielsweise eine "schnelle" Schließung und erneutes Anfahren in 12 Monaten bewerkstelligen. Eine Ölraffinerie braucht dazu möglicherweise vier bis sechs Wochen. Aber die Art von Werksprojektplan, die ich am interessantesten finde, betrifft Fertigungsanlagen, wie ein Stahlwalzwerk, eine Papiermühle oder ähnliche Fabriken. Es gibt Tausende oder sogar Zehntausende solcher Anlagen weltweit, und sie alle müssen regelmäßig gewartet werden, einmal im Jahr oder in ähnlichen Intervallen.

    Die Kosten für die Schließung in diesen Situationen wird normalerweise in Ersatzkosten berechnet; also den Kosten des Produkts, das während der Stilllegung der Fabrik und der stattfindenden Wartung nicht produziert wird. Diese Kosten werden in Stunden gemessen, und sie können durchaus 150.000 € oder 250.000 € pro Stunde erreichen! Daher gibt es jede Minute den Druck, den Auftrag abzuschließen. In solchen Situationen dauert die Schließung normalerweise 5-8 Tage, und ein einziger Tag Verzögerung kostet Millionen. Wenn Sie nur längere, eher traditionelle Zeitpläne gewohnt sind, denken Sie vielleicht, "in ein paar Tagen, wie viele Vorgänge kann man da schon abarbeiten?" – aber es ist keineswegs unüblich, dass eine derartige Schließung aus 2000 bis 4000 Vorgängen besteht, die einzeln zwischen 15 Minuten und einigen Stunden dauern. Ressourcenzuordnungen erfolgen hier auf der Grundlage der Qualifikation, es erfolgt aber selten ein Kapazitätsabgleich für die Mitarbeiter. Aufgrund der hohen Stundenkosten spielt es keine Rolle, ob Sie mehr Personen arbeiten lassen, solange Sie es so schnell wie möglich erledigen. Kapazitätsabgleich erfolgt in dieser Situation häufig für starken Einschränkungen unterliegende Engpässe. Beispielsweise "können nur zwei Personen im Schaltraum arbeiten, daher muss das gesondert verwaltet werden".

    Ansicht von sequenziellen Vorgängen als Gantt-Diagramm

Gut, wir haben jetzt also drei Beispiele, und es gibt noch viel mehr, aber für die Erörterung erfüllen diese drei unsere Zwecke voll und ganz. In Typ eins (Softwareentwicklung) haben wir es mit Vorgängen zu tun, die typischerweise einen bis oder Tage bis zu maximal zwei Wochen lang sind. Bei Typ zwei (EPC) kommen wir zu Vorgängen, die Wochen oder Monate lang sind. Bei Typ drei (Betriebsschließung) kommen wir zu Vorgängen, die in Einheiten von 6 Minuten (1 Zehntel einer Stunde), 10 Minuten, 15 Minuten (einer Viertelstunde) bis zu zwei Stunden gemessen werden. Es ist offensichtlich, dass in einigen Fällen kurze Vorgänge, in anderen jedoch lange Vorgänge sinnvoll sind. Gemäß dieser Logik ist es manchmal sinnvoll, eine große Anzahl von Vorgängen zu definieren, manchmal aber nicht.

Faktoren bei der Wahl der Projektauflösung

Bei diesen drei Einzelfällen fällt sofort ins Auge, dass der zwei Monate umfassende Vorgang aus dem EPC-Projekt in einer sechstägigen Betriebsschließung lächerlich wäre und dass ein 15-Minuten-Vorgang weder im EPC-Projekt noch im Softwareprojekt angebracht ist. Aber abgesehen vom Rückbezug auf diesen Artikel und der Aussage "Vandersluis sagt, es ist ein Softwareprojekt, daher können die Vorgänge nur 1-10 Tage lang sein" (und ich bitte Sie, das nicht zu tun), welche Merkmale der Projekts teilen uns mit, welche Auflösung wir wählen sollten? Sehen wir uns ein paar offensichtliche an:

Wie lange dauert das Projekt?

Also auch hier wieder das Naheliegende. Wenn Ihr Projekt einige Tage umfassen wird, wie in unserem Beispiel der Werksstilllegung, ist es überhaupt nicht sinnvoll, Vorgänge zu definieren, die mehrere Tage dauern. Von einem Top-Down-Ansatz auszugehen ist oftmals produktiv, wenn wir daran denken, den Umfang weiter zu unterteilen. Denken Sie im Sinne eines Projektstrukturplans. Beginnen Sie mit den Hauptkomponenten. Versuchen Sie, bei nicht weniger als 4 und nicht mehr als 20 Einzelkomponenten anzulangen.

Ist das eine Regel? Nein, natürlich nicht.

Das sagt einem der gesunde Menschenverstand. Bei weniger als 4 müssen Sie sich fragen, warum Sie die Arbeit überhaupt aufgeteilt haben, und mehr als 20 sind zu viele, um sie zugleich im Blick behalten zu können. Ich persönlich überschreite nicht die Anzahl von 8 Komponenten pro PSP-Element, und zwar aufgrund eines Artikels den ich vor Jahren einmal gelesen habe, der die These aufstellte, ein Achteck sei die komplexeste Einzelform, die vom Verstand auf einen Blick erkannt werden können.

Denken Sie mal einen Moment darüber nach. Sie können einen Kreis, ein Dreieck, ein Quadrat, ein Fünfeck, ein Hexagon mit seinen 6 Seiten, ein Heptagon (ok, das ist ein bisschen schwer zu visualisieren) und ein Oktogon erkennen.

Können Sie seine Form mit 9 Seiten erkennen, ohne sie abzuzählen? Also, ich kann's nicht. Für die Faktenhuber unter Euch: das heißt "Nonagon".

Also, ich persönlich strebe die 8 Komponenten als Obergrenze an, aber die Faustregel lautet 4-20.

Überlegen Sie bei jedem Element, das Sie betrachten, wie Sie die Arbeit aufteilen sollten. Behalten Sie auch da wieder die 4-20-Regel im Blick. Aber das Geheimnis ist, zu wissen, wann man aufhören muss. Frisch gebackene Projektmanager unterteilen und unterteilen und unterteilen, bis aus jedem Schritt auf dem Gang ein verwalteter Vorgang geworden ist. Einige gute Fragen zur Grenzziehung, die Sie sich zur Länge eines Vorgangs stellen können, sind etwa:

  • Welche Aktion ergreife ich, wenn dieser Vorgang verspätet ist?    Wenn die Antwort "nichts" lautet, ist das ein gutes Anzeichen dafür, dass der fragliche Vorgang zu klein ist, um den Verwaltungsaufwand zu rechtfertigen. Wenn das der Fall ist, befassen Sie sich mit zu vielen Details. Gehen Sie wieder eine Ebene höher, treten Sie einen Schritt zurück, und sehen Sie, ob Sie fertig sind.

  • Dauert das Erfassen der Daten zum Status dieses Vorgangs länger als der Vorgang selbst?    Wir bedenken nicht immer, welchen Aufwand das Verwalten eines geplanten Vorgangs mit sich bringt, es ist aber sinnvoll, sich diese Frage wenigstens für einen Moment zu stellen. Wenn es mehr Aufwand mit sich bringt, den Vorgang zu verwalten, als ihn zu erledigen, ist das ein guter Indikator dafür, dass der Vorgang auf einer zu detaillierten Stufe definiert wurde.

  • Wie lange dauert dieser Vorgang?     Beim Unterteilen von Arbeit verlieren wir manchmal aus den Augen, wie klein eine Vorgang geworden ist. Die großen Phasen auf der obersten Ebene waren möglicherweise Wochen lang, wenn wir aber zwei Ebenen tiefer in der Granularität gehen, können wir leicht in die Falle tappen, einen Vorgang für die Verwaltung zu definieren, der nur einige Minuten lang ist. Wenn wir zu winzigen Vorgängen gelangen, müssen wir fragen, welchen Vorteil es bringen würde, sie zu verwalten.

Wenden wir mal einen Realitätstest auf das eben Gesagte an. In einem zwei Jahre umfassenden EPC-Projekt ist es nahezu sicher nicht erforderlich, aktiv zu werden, wenn ein einwöchiger Vorgang einen Tag verspätet abgeschlossen wird. In einem sechsmonatigen Softwareprojekt ist ein einwöchiger Vorgang, der einen Tag verspätet abgeschlossen wird, wahrscheinlich kein Grund, aktiv zu werden. In einem sechs Tage umfassenden Schließungsprojekt ist ein einwöchiger Vorgang, der einen Tag zu spät fertig gestellt wird, ein massiver Notfall. Anders gesagt, ein einwöchiger Vorgang kann im EPC-Projekt bereits eine zu kleine Detailstufe darstellen; im Softwareprojekt ist er vermutlich genau richtig; und im Schließungsprojekt muss er nahezu sicher in kleinere Details aufgeteilt werden.

Wie viele Ressourcen sind betroffen?

Ich weiß, wir arbeiten gerade am Umfang, aber wenn wir überlegen, welche Auflösung wir benötigen, ist es sinnvoll, einen Moment nachzudenken, wie viele Personen an einem Vorgang arbeiten sollen. In einem großen EPC-Projekt sind möglicherweise Dutzende Arbeiter einer Qualifikation an einer Phase der Arbeit beteiligt. Wenn wir aber bei vielen verschiedenen Qualifikationen im gleichen Vorgang landen, wird das Verwalten des Vorgangs zu einer ziemlichen Herausforderung, wenn nicht gar unmöglich. In dieser Situationen müssen Vorgänge, die viele verschiedene Qualifikationen erfordern, wahrscheinlich aufgeteilt werden.

Bei einem Softwareprojekt tendieren wir dazu, uns nahezu jede Einzelperson als hochgradig technische Ressource mit einzigartigen Fertigkeiten vorzustellen. Außerdem ist es in Softwareprojekten oft üblich, viele Vorgänge zu haben, die innerhalb einer Abteilung anders zugeordnet werden können, wobei jedoch jeweils nur ein Vorgang einer Person zugeordnet ist. Wenn wir also bei Vorgängen angelangt sind, die auf der Ebene von Einzelpersonen einer bestimmten Ressourcengruppe oder Abteilung zugeordnet sind (z. B. Schnittstellenprogrammierung) sind wir nah genug dran, um sagen zu können, dass wir keine feinere Aufteilung mehr benötigen.

Wie werden Ressourcen verwaltet oder unterteilt?

Wie Ressourcen verwaltet werden ist ein wichtiger Faktor, der bestimmt, wie Sie die Unterteilung Ihrer Vorgänge vornehmen. Bei großen EPC-Projekten muss häufig eine Aufteilung in Unterprojekte vorgenommen werden, die als Gesamtpaket an einen großen Vertragsnehmer vergeben werden. In dieser Situation kommt es auf zwei Dinge an:

  • Die Arbeit in einer Weise zu definieren, die einen Projektmanager die Arbeit des Vertragsnehmens mit der Zuversicht überblicken lässt, dass Fortschritte gemacht werden, ist ein wichtiger Faktor.

  • Die Vorgänge in einer Weise zu definieren, die vom Projektmanagement des Vertragsnehmers und seinem Ingenieurteam unzweideutig verstanden wird.

  • Stellen Sie sicher, dass der Auflösungsgrad, den Sie als Ihren Standard angenommen haben, verstanden und vom Vertragsnehmer akzeptiert wird.

Wenn wir uns Projekte für Angestellte, wie Software, biologische Forschung oder Entwicklung ansehen, treffen wir höchst wahrscheinlich auf eine Matrix-Verwaltungsstruktur, in der die Projektmanager keine der Ressourcen besitzen und übergreifend mit Abteilungsleitern zusammenarbeiten müssen, die diese Ressourcen vielen verschiedenen Projekten zuteilen. In diesem Fall wären das die Kernfragen:

  • An wie vielen verschiedenen Projekten arbeitet eine Ressource wahrscheinlich im Lauf eines Tages?

  • Wie lange benötigt ein Mitarbeiter, um von einem Projekt zu einem anderen zu wechseln?

  • Ist die Arbeit in einer Weise definiert, dass sowohl die Mitarbeiter als auch die Manager der Ressourcenabteilung verstehen, wie sie die richtige Qualifikation zuweisen?

Wenn wir ein Betriebsschließungsprojekt oder ein Bauprojekt betrachten, arbeiten wir tendenziell mit Teams zusammen, die für den Zweck zusammengestellt wurden. In diesen Situationen kann der Leiter eines Ressourcenteams etwa das Elektroteam (auch, wenn das Team auch Zimmerleute und Rohrverleger umfasst), ein Klempnerteam oder ein Boiler-Instandsetzungsteam verwalten. Die Arbeit muss so organisiert werden, dass die Mannschaft während der gesamten Schicht beschäftigt werden kann und es nicht vorkommt, dass zwei Teams gleichzeitig im gleichen Bereich arbeiten. Angesichts des immensen Abschlussdrucks bei Schließungsprojekten wird die Arbeit oftmals zuerst nach den zu verrichtenden Arbeiten organisiert, geplant, dann neu gruppiert und vom Leiter eines Ressourcenteams unterteilt, sodass jeder Teamleiter mit nur seinen eigenen Vorgängen in einem Dokument und dem Gesamtprojekt im Kontext in einem anderen arbeiten kann. Daher müssen Vorgänge auf eine Weise definiert werden, die sowohl für den Mitarbeiter als auch für den Leiter des Ressourcenteams verständlich ist. Vorgänge werden hier wahrscheinlich bis hinunter zur Stundenebene oder sogar mit feinerer Granularität bis zum Zehntel oder Viertel einer Stunde definiert.

Wie schnell können Sie Daten erfassen, und wie viel Aufwand ist dazu nötig?

Das hört sich nach einer albernen Frage an, wenn Sie daran gewöhnt sind, am Ende der Woche Ihre sämtlichen Projektdaten zur Überprüfung vorliegen zu haben, aber beim Bestimmen des Auflösungsniveaus Ihres Projekt kann es eine Schlüsselfrage sein. Wenn Sie z. B. mit vielen Vertragsnehmern arbeiten erhalten Sie wahrscheinlich ein wöchentliches oder monatliches Update in irgendeiner Form. Tatsächlich ist es unbedingt wichtig, die Klausel zum Projektmanagementupdate in den Vertrag aufzunehmen. In dieser Situation müssen Sie die Daten von den verschiedenen Firmen in Ihre eigenen integrieren, überprüfen, ob die berichteten Fortschrittsdaten einen Sinn ergeben und dann Ihre eigene Analyse erstellen und den eigenen Bericht schreiben. Im EPC-Modus, erfolgt das wahrscheinlich monatlich.

Bei einem Betriebsschließungsprojekt müssen Sie Ihr Projekt zu jedem Schichtwechsel aktualisieren, das Update schnell vornehmen und den aktuellen Stand den Leitern der Ressourcenteams in der Mitte der nächsten Schicht kommunizieren. In so einem Fall schwärmen Projektmitarbeiter während der gesamten Schicht über das Betriebsgelände, sammeln Daten so nah an Echtzeit wie möglich und lassen Leiter von Ressourcenteams und Vorarbeiter Notizbögen verwenden, um den Fortschritt der zugeteilten Arbeiten zu notieren. In einem Software- oder Forschungsprojekt arbeiten Sie vermutlich mit einem wöchentlichen Zeitplan oder etwas nahe an dieser Auflösung, bei dem die einzelnen Personen ihren Fortschritt berichten und die Genehmigungen einen oder zwei Tage später in Händen halten.

Das ist ein wichtiger Punkt, den Sie bei der Entscheidung für die Anzahl der Vorgänge in Ihrem Projekt berücksichtigen müssen, denn das Erfassen der Daten verursacht Aufwand.

Zu bedenken, wie schnell Sie die Daten regelmäßig auf wiederkehrender Basis erfassen, genehmigen, integrieren, analysieren und zu einem Bericht verarbeiten können, ist entscheidend, ebenso wie die Überlegung, welchen Aufwand das Erfassen der Daten verursacht und ob es sich rentiert.

Wie oft wird aktualisiert?

Hier sind zwei Schlüssel, die Ihnen helfen, zu bestimmen, wie viele Daten Sie sammeln und integrieren können:

  • Überlegen Sie, wie Sie Ihre Daten erfassen.

  • Bedenken Sie, wie oft Sie Ihr Projekt vernünftiger Weise aktualisieren und die Geschäftsleitung mit den erforderlichen Tools zur Entscheidungsfindung versehen können, die dafür erforderlich sind, das Projekt und die Ressourcen in die richtige Richtung zu lenken.

Ich habe Projektmanager erlebt, die darauf bestehen, auf Projektmanagement und Projektdatensammlung "in Echtzeit" umzustellen – und während das theoretisch möglich sein mag, ist es ungeheuer schwierig in die Praxis umzusetzen.

Beim Betrachten von Projektmanagementdaten machen wir einige Annahmen. Wir gehen davon aus, dass:

  • Alle Daten liegen vor   . Wir erwarten nicht, einige aktualisierte Vorgänge zu betrachten, während andere das nicht sind.

  • Die Daten wurden alle zu einer vergleichbaren Zeit aktualisiert   . Wir erwarten nicht, dass die Hälfte der Vorgänge vor einigen Minuten aktualisiert wurde, die andere Hälfte jedoch seit zwei Wochen nicht mehr aktualisiert worden ist.

  • Die Daten haben alle einen gewissen Genehmigungsstatus   . Wir erwarten, dass der Projektmanager hinter den Daten steht, die er präsentiert und dass er oder sie sagen kann "Dies ist eine zutreffende und genaue Darstellung des Projekts".

  • Die Daten gehören zusammen   . Wir erwarten nicht, dass das Risiko mit den Kosten und möglichst noch den Ressourcen vermischt ist, sofern wir unsere Analyse und unsere Berichte nicht spezifisch so ausgelegt haben.

Ich frage Führungskräfte, die vom Konzept des Projektmanagements in Echtzeit begeistert sind, oft, was sie tun würden, wenn die eben angesprochenen Punkte überwunden werden könnten. "Sind Sie darauf gefasst, die ganze Woche hindurch Managemententscheidungen zu treffen?" So frage ich. Die Antwort sollte von der Auflösung abhängen. Bei einem Schließungsprojekt sollte die Antwort wohl eindeutig "Ja" lauten. Bei einem Softwareprojekt lautet die Antwort wahrscheinlich "Nein, das machen wir wöchentlich". Und in einem EPC-Projekt wäre die Antwort "Einmal im Monat".

An einem bestimmten Punkt fordert das Gesetz der abnehmenden Rendite Geltung ein und führt zu der Aussage "Projektberichte schneller vorzulegen bringt uns keine gesteigerte Effizienz".

Überprüfen Ihrer Arbeit

Sie haben jetzt eine Reihe guter Anregungen erhalten, Sie haben die Projektstrukturplan-Methode angewendet, um Ihre Daten weiter zu unterteilen, und Sie haben nach einigen Warnzeichen Ausschau gehalten, dass Ihre Datendefinition zu fein aufgelöst ist. Jetzt ist es an der Zeit, den Projektplan an die Wand zu pinnen, zurückzutreten und das Projekt perspektivisch zu betrachten. Es ist erstaunlich, wie viele Projektmanager das niemals tun. Sie sind völlig in dem Vorhaben gefangen, noch die letzten Details zu definieren und sind so beschäftigt, Vorgänge weiter und weiter zu unterteilen, dass sie sich bis an die Realisierungsdeadline heranpushen, ohne einmal aufzusehen, um nachzusehen, ob das, was sie da definiert haben, das Drehbuch für einen Managementalptraum ist.

In manchen Fällen sind Führungskräfte nach vielen MBA-Schulungen sicher, dass "mehr Detail immer besser" ist und verlangen nach 5-Minuten oder 15-Minuten-Vorgängen in Projekten mit sechs Monaten Laufzeit.

Ein Projekt zu ändern, bevor es gestartet ist, ist immer einfacher als zu jedem späteren Zeitpunkt, daher sollten Sie in Ihren Aktivitäten zur Projektplanerstellung Zeit zum Umbau des Projektplans vorsehen, falls das erforderlich sein sollte.

Ist es zu viel?

Manchmal blicken Projektmanager auf den Umfang dessen, was sie erstellt haben, und stellen fest, dass sie eine zu feine Detailstufe betrachten. In dem Fall ist die Lösung offensichtlich. Es mag viel Arbeit sein, aber Sie werden sich selbst später dafür dankbar sein, dass Sie den Projektplan vereinfacht haben, indem Sie eine Ebene höher gegangen sind.

Manchmal ist das Bild nicht so deutlich zu erkennen. In manchen Fällen muss erst der gesamte Projektplan fertig gestellt sein, ehe der Projektmanager sehen kann, wie komplex er ist. Komplexe Projekte sind naturgemäß riskanter, und Risiko stellt in der Wirtschaft von heute einen Schlüsselfaktor für die Entscheidung für oder gegen ein Projekt dar. Einige Fragen, die abgewogen werden sollten, bevor ein so komplexes Projekt auf den Weg gebracht wird, lauten etwa:

  • Lässt sich das Projekt stückweise realisieren?    Einige riskante Projekte können in kleinere Portionen aufgeteilt werden, und das Risiko für die Einzelprojekte ist geringer. Wenn Sie diese Strategie befolgen möchten, sollte aber jedes der Einzelprojekte nach dem Abschluss einen Wert für sich haben.

  • Sollten wir den Umfang überdenken?    Manchmal ist die einfachste Maßnahme, zu den ursprünglichen Entwicklern der Arbeit zu gehen, die Komplexität zu erläutern, die sich aus dem Projektplan ablesen lässt, und zu fragen, ob die Arbeit anders definiert werden kann. Dies führt oft zu innovativen Ideen, die anders nie eine Chance gehabt hätten.

Sollen wir es überhaupt realisieren?

Einige Projekte waren nie dafür bestimmt, das Licht der Welt zu erblicken, und der billigste Zeitpunkt für ihren Abbruch ist am Tag vor ihrem Start. Wenn das Risiko des Projekts erst jetzt sichtbar wird, ist es immer noch besser, es jetzt zu verstehen als später. Wenn Sie die Ergebnisse der Projektplanerstellung wieder in den PPM-Prozess (Projekt-Portfolio-Management)einweben, kann sich herausstellen, dass sich durch das Risiko des komplexeren Projekts der Wert der Arbeit im Sinne der Kapitalrendite stark verschlechtert.

Ein flinkes... nein, sondern ein agiles Projekt

Ich habe versprochen, ein paar Dinge zum Agile-Projektmanagement zu sagen, und wenn Sie ein Agile-Anhänger sind und bis hierher gelesen haben, weiß ich Ihre Geduld zu schätzen. Das Verwalten von Softwareprojekten mithilfe der Agile-Methode hat sich zu einer Art Philosophie entwickelt, die aber speziell bei denen, die sich bei fehlgeschlagenen umfänglichen Softwareentwicklungsprojekten die Finger verbrannt haben, zunehmend beliebter wird.

In einer Welt der Softwareentwicklung nach Agile-Prinzipien versuchen wir, unser Projekt in häppchengroße "Sprints" von einer bis drei Wochen Dauer aufzuteilen, wobei das Ziel für jedes dieser Miniprojekte ein Ergebnis in Form von nutzbarem Code ist. In diesem Fall arbeiten wir im Rahmen einiger wohlbekannter Einschränkungen, so dass unser Auflösungsniveau praktisch schon für uns bestimmt ist.

Wir haben ein Zeitfenster von einer bis drei Wochen, die Ressourcen stehen zu unserer Verfügung, und wir werden jeder Ressource Arbeit zuordnen. Die Anzahl der möglichen Vorgänge, die wir in dieser Struktur definierten können, ist endlich und bietet sich für ein passendes Auflösungsniveau an. Ja, man kann sich beim Agile-Management in Schwierigkeiten bringen, indem man viel zu kurze Vorgänge definiert. “Definiere Feld1: 10 Minuten, Definiere Feld2: 10 Minuten, Definiere Feld3: 10 Minuten, aber das ist nicht sehr gebräuchlich.

Agile wurde für eine Entwicklungsumgebung im Unternehmen entwickelt, die Software für den Gebrauch im eigenen Haus erstellt, wird aber häufig auf die kommerzielle Softwareentwicklung ausgeweitet. (Wir verwenden die Methode hier bei HMS für unsere eigene Entwicklung von TimeControl.) Die Agile-Methode führt zu einer besser lenkbaren und flexibleren Entwicklungsabteilung, aber sie lässt sich nicht auf jede Branche und nicht einmal auf jede Softwarefirma anwenden. Wenn Sie Projektmanagement in einer Softwareumgebung betreiben, dann ist meine Empfehlung, dass Sie sich zu Agile gründlich einlesen, daraus lernen und dann die Elemente (alle, einige oder keine) übernehmen, die Ihre Effektivität steigern.

Nachbereitung

Wie bei den meisten Aspekten des Projektmanagements gibt es keine feststehende Antwort auf Fragen, die auf den ersten Blick so klar wirken. Wie viele Vorgänge Sie in Ihrem Projekt haben sollten und wie lang jeder von ihnen dauern sollte ist etwas, das Sie selbst entscheiden müssen – aber entscheiden müssen Sie es.

Die Wahl der richtigen Projektauflösung ist eine Aufgabe im Projektmanagement, die den Schlüssel zum Erfolg Management des Projektzeitplans darstellen kann.

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).

Ihre Fähigkeiten erweitern
Schulung erkunden
Neue Funktionen als Erster erhalten
An Office Insider teilnehmen

War diese Information hilfreich?

Vielen Dank für Ihr Feedback!

Vielen Dank für Ihr Feedback. Es klingt, als ob es hilfreich sein könnte, Sie mit einem unserer Office-Supportmitarbeiter zu verbinden.

×