Projektlösung

Dieser Artikel ist Teil unserer Sammlung "From the Trenches". Es werden einige häufige Herausforderungen beschrieben, mit denen Sie bei der Planung von Projekten konfrontiert sein können. Es wird beschrieben, wie sie den besten Ansatz finden, wenn Sie bestimmen möchten, wie lange Vorgänge dauern und wie viele Vorgänge vorhanden sein sollten, um einen Projektzeitplan zu optimieren. Es wird erläutert, wie unterschiedliche Branchen in der Regel unterschiedliche Arten von Zeitplänen benötigen (z. B. Softwareentwicklung, EPM (Engineering, Beschaffung und Bau) und Stilllegung von Anlagen). Außerdem werden verschiedene Faktoren bei der Auswahl der Projektauflösung behandelt (z. B. Projektdauer, involvierte Ressourcen, Verwaltung oder Aufteilung von Ressourcen, Geschwindigkeit und Aufwand beim Sammeln von Daten und Zeitplan für Datenaktualisierungen).

Informationen zum Herunterladen der Word-Version dieses Artikels finden Sie unter Sie möchten eine Lösung: Whitepaper (Project Server 2010).

Weitere Artikel finden Sie in den Whitepapers "Aus den Gräben".

Projektlösung

Mit Entschuldigung bei den Beatles für den Titel ist das heutige Thema die Auflösung Ihres Projekts.

Es gibt viele Materialien zum Erstellen eines Zeitplans, aber eine der kritischsten Lektionen ist sehr schwer zu finden– wie viele Vorgänge sollten in Ihrem Projektzeitplan enthalten sein und wie lange sollte jeder Vorgang dauern?

In regelmäßigen Abständen bin ich mit Projektplänen konfrontiert, die unvorstellbar komplex erscheinen, oder mit Projektmanagern, die hilflos scheinen, Probleme in ihrem Zeitplan zu ermitteln, weil der Zeitplan auf einer solchen Zusammenfassungsebene liegt. Ich habe ein Projekt gesehen, das über hundert Jahre lang war (ja, wirklich), das in der Länge vollkommen angemessen war und in dem es einige Aufgaben gab, die jahrzehntelang waren. Ich habe auch Projektpläne gesehen, die nur eine Stunde oder weniger dauerten, die vollkommen angemessen waren und in denen einige Aufgaben nur eine Minute gedauert haben. Ich habe Projekte mit nur einer Handvoll Aufgaben und andere mit über 100.000 Vorgängen gesehen.

Die Software, die wir heute verwenden, kann Tausende von Aufgaben und eine vielzahl von Daueren bewältigen.

Was ist also der richtige Ansatz?

Wie lange sollten Vorgänge dauern, und wie viele müssen wir haben, um unseren Projektzeitplan zu optimieren? Ich nenne dies die Lösung des Projekts.

Verschiedene Striche für verschiedene Leute

Da die Anforderungen für verschiedene Branchen, verschiedene Arten von Projekten und unterschiedliche Situationen unterschiedlich sein können, sehen wir uns an, wie Sie entscheiden, wie viele Vorgänge in Ihren Zeitplan eingefügt werden sollen und wie lange Vorgänge dauern sollten.

Verschiedene Arten von Projekten erfordern natürlich verschiedene Arten von Zeitplänen. Betrachten wir drei verschiedene Beispiele:

1. Softwareentwicklung. Viele Softwareprojekte weisen gemeinsame Merkmale auf. Obwohl jedes Softwareprojekt einzigartig ist, gibt es in der Regel eine Entwurfsphase, eine Programmierphase, eine Qualitätssicherungsphase, eine Dokumentphase und eine Bereitstellungsphase. Softwareprojekte werden in der Regel in Wochen oder Monaten gemessen und eignen sich für Aufgaben, die einen Tag bis ein paar Wochen lang sind. Die Ressourcenzuordnung wird hier häufig der einzelnen Ebene zugewiesen.

   Diejenigen, die den Agile-Prozess für die Entwicklung von Software übernommen haben, suchen nach kurzen "Sprints" von ein oder zwei Wochen und innerhalb dieses Sprints legen Aufgaben von kurzer Dauer, aber die Gesamtprojektdauer wird immer noch in Wochen gemessen. Wir werden etwas später mehr über agile Entwicklung sprechen.

   

2. EPC - Engineering, Procurement, and Construction. Epc-Projekte sind der Ausgangspunkt für die Methodik für die Planung kritischer Pfade. In dieser Art von Projekt wird etwas sehr Großes entwickelt. Es könnte ein großes Verteidigungsprojekt wie das Polaris-Raketenprojekt sein, das PERT-Diagrammen ihren Start gab, oder es könnte eine Offshore-Ölplattform, ein neues Schiff oder ein Kraftwerk sein. Bei solchen Projekten gibt es eine Engineering-Phase, in der das fertige Projekt konzipiert wird. Die Entwicklungsphase hat in der Regel einen Aspekt, der noch nie zuvor entworfen wurde. In der Beschaffungsphase geht es um die Lokalisierung, Vergabe und Verwaltung der Lieferung von Lieferungen oder Unteraufträgen für Elemente des Projekts. In der Bauphase wird das Endprodukt konstruiert und dann zur Verwendung in Betrieb genommen. Wir denken in der Regel an EPC-Projektpläne in vielen Monaten oder mehreren Jahren mit Einer Aktivitätsdauer zwischen einigen Wochen und einigen Monaten. Es ist überhaupt nicht ungewöhnlich, 5.000 bis 20.000 Aufgaben in einem solchen Projekt zu haben. Die Ressourcenplanung wird hier fast immer der Qualifikationsstufe und nicht der Einzelperson zugewiesen, und (um den Spaß zu erhöhen) kann es viele Unterprojekte geben, die zur Vereinfachung der Verwaltung in einem Programm oder Masterprojekt zusammengefasst werden.

   

3. Stilllegung der Anlage. Wenn Sie einen Projektplan für das Herunterfahren einer Anlage und die Wartung durchführen, arbeiten Sie in einer der schwierigsten Planungsumgebungen, die möglich sind. Eine Stilllegung der Anlage zur Wartung gibt es in zwei Varianten: geplant und notfallmäßig. Lassen Wir den Notfalltyp für einen Moment beiseite; es ist eine Welt für sich selbst. Die Dauer eines geplanten Anlagenstillstands hängt stark von der Art der Anlage ab. Ein Kernkraftwerksaggregat kann beispielsweise eine "schnelle" Abschaltung und Einen Turnaround der Anlage in 12 Monaten durchführen. Eine Ölraffinerie kann 4-6 Wochen dauern. Aber die Art des Anlagenprojektplans, den ich am interessantesten finde, ist ein Fertigungswerk wie ein Stahlwerk, eine Papierfabrik oder ähnliches. Es gibt Tausende oder Zehntausende solcher Pflanzen auf der ganzen Welt, und sie müssen jedes Jahr regelmäßig gewartet werden.

   Die Kosten des Herunterfahrens für diese Situationen werden in der Regel an den Verkaufschancen gemessen; die Kosten des Produkts, das nicht produziert wird, während die Anlage im Leerlauf ist und gewartet wird. Diese Kosten werden in Stunden gemessen, und die Kosten können zwischen 150.000 und 250.000 US-Dollar pro Stunde betragen! Der Druck liegt also minutenauf, um die Arbeit zu erledigen. In einer solchen Situation dauert das Herunterfahren in der Regel 5-8 Tage, und die Verzögerung eines einzelnen Tages wird in Millionenhöhe berechnet. Wenn Sie nur an längere, traditionellere Zeitpläne gewöhnt sind, denken Sie vielleicht, dass in ein paar kurzen Tagen "Wie viele Vorgänge könnten es in der Regel geben?", aber es ist überhaupt nicht ungewöhnlich, dass ein solches Herunterfahren 2.000 bis 4.000 Vorgänge umfasst, die jeweils zwischen 15 Minuten und ein paar Stunden dauern. Ressourcenzuweisungen werden hier durch Qualifikationen durchgeführt, aber ressourcenabgleich wird selten für Mitarbeiter durchgeführt. Da die Kosten pro Stunde so intensiv sind, spielt es keine Rolle, ob Sie mehr Leute in das Projekt setzen, es einfach in Eile erledigen. Das Abgleichen von Ressourcen erfolgt in dieser Situation häufig bei eng begrenzten Engpässen. Beispiel: "Wir können nur zwei Personen in den Elektrischen Raum einpassen, das muss also diskret verwaltet werden".

   

Ok, wir haben jetzt drei Arten von Beispielen, und es gibt viele weitere, aber diese drei dienen den Zwecken der Diskussion genau richtig. In Typ 1 (Softwareentwicklung) erhalten wir Aufgaben, die in der Regel einen Tag oder zwei Tage bis zwei Wochen lang sind. In Typ 2 (EPC) erhalten wir Vorgänge, die wochen- oder monatelang sind. In Typ 3 (Anlagenstillstand) erhalten wir Vorgänge, die in Einheiten von 6 Minuten (1/10 einer Stunde), 10 Minuten, 15 Minuten (1/4 einer Stunde) bis zu einigen Stunden lang gemessen werden. Es ist offensichtlich, dass in einigen Fällen kurze Aufgaben sinnvoll sind und in anderen langen Aufgaben besser geeignet sind. Wenn Sie der gleichen Logik folgen, ist es manchmal sinnvoll, eine große Anzahl von Aufgaben zu haben, und manchmal ist dies einfach nicht der Fall.

Faktoren bei der Auswahl ihrer Projektauflösung

Mit diesen drei Unterschieden ist leicht zu erkennen, dass die zweimonatige EPC-Projektaufgabe in einem Sechs-Tage-Shutdown-Zeitplan lächerlich aussehen würde und dass ein 15-Minuten-Vorgang im EPC- oder Software-Projekt fehl am Platz wäre. Aber abgesehen davon, auf diesen Artikel zurück zu verweisen und zu sagen: "Vandersluis sagt, dass es sich um ein Softwareprojekt handelt, sodass Aufgaben nur 1-10 Tage lang sein können" (und bitte, tun Sie das nicht), welche Merkmale des Projekts sagen uns, welche Auflösungsebene wir wählen sollten? Sehen wir uns einige offensichtliche Beispiele an:

Wie lange dauert das Projekt?

Beginnen wir mit dem offensichtlichsten. Wenn Ihr Projekt voraussichtlich einige Tage lang ist, wie in unserem Beispiel für das Herunterfahren, ist es überhaupt nicht sinnvoll, aufgaben zu haben, die mehrere Tage lang sind. Mit einem Top-Down-Ansatz zu beginnen, ist oft produktiv, wenn wir über eine Unterteilung des Bereichs nachdenken. Verwenden Sie das Denken der Struktur der Arbeitsstruktur. Beginnen Sie mit den Hauptkomponenten. Denken Sie daran, nicht weniger als 4 und nicht mehr als 20 Elemente zu haben.

Handelt es sich um eine Regel? Nein, natürlich nicht.

Es ist gesunder Menschenverstand. Weniger als 4 lässt Sie sich fragen, warum Sie die Arbeit überhaupt aufgeteilt haben und mehr als 20 ist zu schwer, um sich auf einmal im Kopf zu halten. Persönlich gehe ich mit nicht mehr als 8 Elementen pro WBS-Element und das liegt an einem Artikel, den ich vor Jahren gelesen habe, der nahelegte, dass ein Achteck die komplexeste einfache Form war, die der Geist sofort erkennen konnte.

Denken Sie einen Moment darüber nach. Sie können einen Kreis, ein Dreieck, ein Quadrat, ein Fünfeck, ein Sechseck mit 6 Seiten, ein Heptagon mit 7 Seiten (ok, das ist schwer zu visualisieren) und ein Achteck identifizieren.

Können Sie eine 9-seitige Form ohne Zählen identifizieren? Ich kann nicht. Es wird als "nonagon" für Sie Trivia buffs bezeichnet.

Also persönlich strebte ich das 8-Punkte-Limit an, aber meine Faustregel ist 4-20.

Überlegen Sie für jedes Element, das Sie sich angesehen haben, wie Sie die Arbeit aufteilen sollten. Denken Sie noch einmal an die 4-20-Regel. Aber zu wissen, wann man aufhören muss, ist das Geheimnis. Neuere Projektmanager werden unterteilen, unterteilen und unterteilen, bis jeder Schritt unten im Korridor eine verwaltete Aufgabe ist. Einige gute Fragen, die Sie sich über die Länge einer Aufgabe stellen können, könnten sein:

• Welche Aktion würde ich ergreifen, wenn diese Aufgabe zu spät wäre? Wenn die Antwort "nichts" lautet, ist dies ein guter Hinweis darauf, dass die Aufgabe, an die Sie denken, zu klein ist, um es zu verwalten. Wenn dies der Fall ist, sehen Sie sich zu viele Details an. Sichern Sie eine Ebene, gehen Sie einen Schritt zurück, und überprüfen Sie, ob Sie fertig sind.

• Dauert das Sammeln der Daten bei der Aktualisierung dieser Aufgabe länger als die Aufgabe selbst? Wir denken nicht immer darüber nach, welche Art von Aufwand es erfordert, einen geplanten Vorgang zu verwalten, aber es lohnt sich, darüber nachzudenken, auch wenn für einen Moment. Wenn die Verwaltung des Vorgangs mehr Aufwand erfordert, als zum Abschließen erforderlich ist, ist dies ein guter Hinweis darauf, dass die Aufgabe mit zu feiner Detailgenauigkeit definiert wird.

• Wie lange dauert diese Aufgabe? Wenn wir arbeitlich unterteilen, verlieren wir manchmal den Überblick darüber, wie winzig eine Aufgabe wird. Die großen Phasen auf der obersten Ebene waren vielleicht wochenlang, aber wenn wir ein paar Granularitätsebenen herunterkommen, können wir leicht in die Falle fallen, eine Aufgabe zu definieren, die nur wenige Minuten lang ist. Wenn wir mit winzigen Aufgaben kommen, müssen wir uns fragen, was der Vorteil wäre, sie zu verwalten.

Lassen Sie uns einen Realitätscheck auf das anwenden, worüber ich gerade gesprochen habe. In einem zweijährigen EPC-Projekt lohnt es sich fast sicher nicht, maßnahmen zu ergreifen, wenn eine einwöchige Aufgabe einen Tag zu spät ist. In einem sechsmonatigen Software-Projekt ist eine einwöchige Aufgabe, die einen Tag zu spät ist, wahrscheinlich keine Aktion wert. In einem sechstägigen Shutdown-Projekt ist eine einwöchige Aufgabe, die einen Tag zu spät ist, ein massiver Notfall. Mit anderen Worten, eine einwöchige Aufgabe im EPC-Projekt kann zu detailliert sein; im Softwareprojekt ist es wahrscheinlich genau richtig; und im Shutdown-Projekt muss es mit sicherheit noch ausführlicher untergliedert werden.

Wie viele Ressourcen sind beteiligt?

Ich weiß, dass wir nur an dem Umfang arbeiten, aber wenn wir uns ansehen, welche Art von Lösung wir benötigen, lohnt es sich, darüber nachzudenken, wie viele Personen an einer Aufgabe arbeiten werden. In einem großen EPC-Projekt können wir beispielsweise Dutzende von Mitarbeitern einer Qualifikation haben, die an einer Phase der Arbeit beteiligt sind. Aber wenn wir am Ende viele verschiedene Fähigkeiten in derselben Aufgabe haben, wird die Verwaltung dieser Aufgabe sehr schwierig, wenn nicht gar unmöglich. In dieser Situation müssen aufgaben, die viele verschiedene Fähigkeiten erfordern, wahrscheinlich aufgeteilt werden.

In einem Softwareprojekt neigen wir dazu, fast jedes Individuum als hochtechnische Ressource mit einzigartigen Fähigkeiten zu betrachten. Außerdem ist es in Softwareprojekten üblich, dass viele Aufgaben innerhalb einer Abteilung neu zugewiesen werden können, aber nur eine Aufgabe einer Person zugewiesen wird. Wenn wir also Aufgaben haben, die einer Ein-Personen-Ebene einer bestimmten Ressourcengruppe oder Abteilung zugeordnet sind (z. B. Schnittstellenprogrammierung), sind wir nah genug, um zu sagen, dass wir keine weiteren Details benötigen.

Wie werden Ressourcen verwaltet oder unterteilt?

Die Verwaltung von Ressourcen ist ein wichtiger Faktor für die Unterteilung Ihrer Aufgaben. In großen EPC-Projekten beispielsweise werden Projekte häufig in Teilprojekte aufgeteilt, die an große Subunternehmer verteilt werden. In dieser Situation müssen wir einige Dinge tun:

• Definieren Sie die Arbeit so, dass ein Projektmanager den Unterauftragnehmer mit der Gewissheit überwachen kann, dass fortschritte ein großer Faktor sind.

• Definieren Sie die Aufgaben so, dass das Projektmanagement und das Engineering-Personal des Unterauftragnehmers ohne Mehrdeutigkeit verstehen, was sie bedeuten.

• Stellen Sie sicher, dass die Lösungsebene, die Sie als Standard angenommen haben, vom Unterauftragnehmer verstanden und vereinbart wird.

Wenn wir uns Wirtschaftsprojekte wie Software, biologische Forschung oder Technik ansehen, stoßen wir höchstwahrscheinlich auf eine Matrix-Management-Struktur, in der Projektmanager keine der Ressourcen besitzen und wir abteilungsübergreifend arbeiten müssen, die diese Ressourcen für viele verschiedene Projekte zuordnen. In diesem Fall wären die wichtigsten Fragen:

• Wie viele Projekte wird eine Ressource wahrscheinlich an einem einzigen Tag bearbeiten?

• Wie lange dauert es, dass ein Mitarbeiter von einem Projekt zu einem anderen wechselt?

• Ist die Arbeit so definiert, dass sowohl die Mitarbeiter als auch die Ressourcenabteilungsleiter verstehen, wie sie ihr die richtigen Fähigkeiten zuordnen können?

Wenn wir uns ein Shutdown- oder Construction-Projekt ansehen, arbeiten wir in der Regel über Crews hinweg, die speziell erstellt wurden. In diesen Situationen kann ein Leiter des Ressourcenteams das Elektroteam (auch wenn dieses Team Zimmerer und Rohrschlosser umfasst), ein Sanitärteam oder ein Kesseleinheitsüberholungsteam verwalten. Die Arbeit muss so organisiert werden, dass die Crew während der gesamten Schicht beschäftigt sein kann und dass sie nicht auf einer anderen Crew ankommen wird, die bereits in etwas in diesem Bereich arbeitet. Angesichts des hohen Drucks, ein Shutdown-Projekt abzuschließen, wird die Arbeit häufig zuerst nach Arbeit organisiert, geplant und dann durch einen Ressourcenteamleiter neu gruppiert und untergliedert, sodass jeder Teamleiter nur mit seinen Aufgaben in einem Dokument und mit dem gesamten Projekt im Kontext in einem anderen Dokument herumlaufen kann. Aufgaben müssen also so definiert werden, dass sie vom Mitarbeiter und vom Ressourcenteamleiter verständlich ist. Aufgaben werden hier wahrscheinlich bis zur Stunde oder mit noch mehr Granularität bis zum Zehnten oder Viertel einer Stunde definiert.

Wie schnell können Sie Daten sammeln, und wie viel Aufwand ist dafür erforderlich?

Es klingt nach einer dummen Frage, wenn Sie daran gewöhnt sind, dass Ihre Projektdaten am Ende der Woche gut eingereiht sind, um überprüft zu werden, aber wenn Sie versuchen, den Auflösungsgrad Ihres Projekts zu bestimmen, kann dies eine wichtige Frage sein. Wenn Sie z. B. zahlreiche Unterauftragnehmer durcharbeiten, erhalten Sie wahrscheinlich eine Art wöchentliches oder monatliches Update. In der Tat ist es wichtig, die Updateklausel für das Projektmanagement in Ihren Vertrag zu integrieren. In dieser Situation müssen Sie die Daten dieser verschiedenen Unternehmen in Ihre eigenen integrieren, überprüfen, ob die Fortschrittsdaten sinnvoll sind, und dann Ihre eigene Analyse und Berichterstellung durchführen. In einem EPC-Modus ist dies wahrscheinlich ein monatliches Ereignis.

In einem Herunterfahren-Projekt müssen Sie Ihr Projekt in jeder Schicht aktualisieren, es schnell aktualisieren und die Updates für die Ressourcenteamleiter in der Mitte der nächsten Schicht erhalten. In dieser Situation schwärmen projektbezogene Mitarbeiter während der Schicht im gesamten Werk, sammeln Daten so nah wie möglich in Echtzeit und lassen Ressourcenteamleiter und Foremen mithilfe von "Take-down"-Blättern den Fortschritt ihrer Aufgaben "herunternehmen". In einer Software oder einem Forschungsprojekt arbeiten Sie wahrscheinlich nach einem wöchentlichen Zeitplan oder einem ähnlichen Zeitplan mit Personen, die ihren eigenen Fortschritt melden und über ein oder zwei Tage hinweg Genehmigungen durchlaufen.

Dies ist ein wichtiger Punkt, den Sie berücksichtigen sollten, wenn Sie sich ansehen, wie viele Vorgänge in Ihrem Projekt vorhanden sein sollen, da das Sammeln der Daten Kosten verursacht.

Daher ist es wichtig, darüber nachzudenken, wie schnell Sie die Daten regelmäßig zyklischer Basis sammeln, genehmigen, integrieren, analysieren und melden können, ebenso wie die Berücksichtigung der Kosten für die Erfassung der Daten und der Rendite der gesammelten Daten.

Wie oft werden wir aktualisieren?

Hier sind zwei Schlüssel, um zu bestimmen, wie viele Daten Sie sammeln und einschließen können:

• Überlegen Sie, wie Sie Ihre Daten sammeln.

• Überlegen Sie, wie oft Sie Ihr Projekt angemessen aktualisieren können, und stellen Sie dem Management die Entscheidungstools zur Verfügung, die erforderlich sind, um das Projekt und die Ressourcen in die richtige Richtung zu führen.

Ich habe gesehen, wie einige Projektmanager darauf bestehen, dass sie zu "Echtzeit"-Projektmanagement und -sammlung wechseln möchten, und obwohl dies theoretisch möglich ist, ist es in der Praxis furchtbar schwierig zu realisieren.

Wenn wir uns Projektmanagementdaten ansehen, gehen wir von einigen Annahmen aus. Wir gehen davon aus, dass:

• Die Daten sind alle vorhanden. Wir erwarten nicht, dass wir uns einige Aufgaben ansehen, die aktualisiert werden und andere, die dies nicht tun.

• Die Daten wurden alle zu einem ähnlichen Zeitpunkt aktualisiert. Wir gehen nicht davon aus, dass die Hälfte der Aufgaben vor einigen Minuten aktualisiert wurde, aber die andere Hälfte wurde seit zwei Wochen nicht mehr aktualisiert.

• Die Daten hatten alle eine gewisse Genehmigungsebene. Wir erwarten, dass der Projektmanager hinter den präsentierten Daten steht und sagen kann: "Dies ist eine faire und genaue Darstellung des Projekts."

• Die Daten gehören zusammen. Wir gehen nicht davon aus, dass das Risiko mit Kosten und Ressourcen verschwommen wird, es sei denn, wir haben unsere Berichte und Analysen speziell auf diese Weise entworfen.

Ich frage oft Führungskräfte, die vom Konzept des Echtzeitprojektmanagements begeistert sind, was sie tun werden, wenn wir die oben genannten Punkte überwinden könnten. "Sind Sie bereit, die ganze Woche über Managemententscheidungen zu treffen?" Ich werde fragen. Die Antwort sollte von der Auflösungsebene abhängen. Bei einem Herunterfahrensprojekt wäre die Antwort besser "Ja" gewesen. In einem Softwareprojekt lautet die Antwort wahrscheinlich "Nein, das machen wir wöchentlich". Und in einem EPC-Projekt würde die Antwort "Monatlich" sein.

Irgendwann tritt das Gesetz der abnehmenden Rendite auf, um zu sagen: "Die schnellere Übermittlung von Projektberichten bringt uns keine Effizienzsteigerung."

Überprüfen Ihrer Arbeit

Sie haben jetzt etwas zu denken gegeben, Sie haben die Work-Breakdown-Methode verwendet, um Ihre Daten unterzuteilen, und Sie haben auf einige der Warnsignale geschaut, dass die Daten zu fein definiert sind. Jetzt ist es an der Zeit, den Zeitplan an die Wand zu lehnen, zurückzutreten und das Projekt mit einer Perspektive zu betrachten. Erstaunlicherweise tun viele Projektmanager dies nie. Sie werden so in die letzten definierten Details eingeholt und sind immer wieder so ausgelastet, dass sie sich bis zum Starttermin selbst pushen und nie nachsehen, ob das, was sie gemacht haben, ein Alptraum für die Verwaltung sein wird.

In einigen Fällen sind sich Führungskräfte aus all dem MBA-Training sicher, dass "mehr Details besser" sind, und sie drängen auf diese 5-Minuten- oder 15-Minuten-Aufgaben bei sechsmonatigen Projekten.

Das Ändern des Projekts vor dem Start ist immer einfacher als zu jedem späteren Zeitpunkt, daher sollten Sie Zeit in Ihre Zeitplanerstellungsaktivität integrieren, um den Zeitplan bei Bedarf zu überarbeiten.

Ist es zu viel?

Manchmal betrachten Projektmanager den Umfang der von ihnen erstellten Elemente und stellen fest, dass sie auf einer zu hohen Detailebene sind. Wenn dies der Fall ist, ist die Korrektur offensichtlich. Es kann eine Menge Arbeit sein, aber Sie werden sich später bedanken, um den Zeitplan zu vereinfachen, indem Sie ein Level nach oben.

Manchmal ist das Bild nicht so einfach. In einigen Fällen kann der Projektmanager erst nach der Zusammenstellung des gesamten Zeitplans sehen, wie komplex er ist. Komplexe Projekte sind von Natur aus riskanter, und Risiken in der heutigen Wirtschaft sind ein wichtiger Auswahlfaktor für Projekte. Einige Fragen, die berücksichtigt werden sollten, bevor ein so komplexes Projekt in Gang kommt, könnten sein:

• Können wir es in Teilen tun? Einige riskante Projekte können in kleinere bissige Teile aufgeteilt werden, und bei kleineren Projekten sinkt ihr Risiko. Wenn Sie jedoch diese Strategie verwenden, sollte jedes einzelne Projekt seinen eigenen Wert haben, wenn es abgeschlossen ist.

• Sollten wir den Umfang überdenken? Manchmal sind die einfachsten Aktionen, zuerst zu den Designern der Arbeit zurückzukehren, die Komplexität zu erklären, die im Zeitplan offensichtlich ist, und zu sehen, ob die Arbeit neu erstellt werden kann. Dies führt oft zu einem innovativen Denken, das nie eine Chance gehabt hätte.

Sollten wir das überhaupt tun?

Einige Projekte waren nie gedacht, und die billigste Zeit, um sie abzubrechen, ist der Tag vor dem Start. Wenn das Risiko des Projekts erst jetzt offensichtlich ist, ist es besser, es jetzt als später zu realisieren. Wenn Sie die Ergebnisse ihres Zeitplans wieder in den Projektportfolio-Management-Prozess (PPM) integrieren, stellen Sie möglicherweise fest, dass das Risiko des komplexeren Projekts die Arbeitsbewertung in einer Renditeskala viel schlechter hat.

Eine flinke... Nein, ein Agile-Projekt

Ich versprach, ein paar Dinge über Agile-Projektmanagement zu sagen, und wenn Sie ein Agile-Fan sind und Sie so weit gelesen haben, weiß ich Ihre Geduld zu schätzen. Die Verwaltung von Softwareprojekten durch die Agile-Methode ist etwas von einer Philosophie, aber es ist eine immer beliebtere Philosophie bei denen, die in massiven Softwareentwicklungsprojekten verbrannt wurden, die fehlgeschlagen sind.

In einer Agile-Softwareentwicklungswelt versuchen wir, unser Projekt in kleine, ein- bis dreiwöchige "Sprints" aufzuteilen, und das Ziel für jedes Miniprojekt ist es, am Ende mit verwendbarem Code zu enden. In diesem Fall arbeiten wir innerhalb einiger ziemlich bekannter Einschränkungen, sodass unser Auflösungsniveau für uns so ziemlich ausgewählt ist.

Wir haben ein bis dreiwöchiges Zeitfenster, die Ressourcen sind verfügbar, und wir werden jeder Ressource Arbeit zuweisen. Die Anzahl der möglichen Aufgaben, die wir in dieser Struktur definieren können, ist begrenzt, und dies eignet sich für die Beibehaltung eines angemessenen Lösungsniveaus. Ja, Sie können probleme in Agile bekommen, indem Sie Aufgaben definieren, die viel zu kurz sind. "Define Field1: 10 minutes, Define Field2: 10 minutes, Define Field3: 10 minutes" usw., aber dies ist viel seltener.

Agile wurde für eine Unternehmensentwicklungsumgebung entwickelt, in der wir Software für den internen Gebrauch erstellen, und ihre Verwendung wird häufig auf die kommerzielle Softwareentwicklung ausgedehnt. (Wir verwenden die Methode hier bei HMS für unsere eigene Entwicklung von TimeControl.) Die Agile-Methode führt zu einer wendigeren und agileren Entwicklungsabteilung, aber sie wird nicht für jede Branche oder sogar jedes Softwareunternehmen anwendbar sein. Wenn Sie Projektmanagement in einer Softwareumgebung durchführen, empfiehlt es sich, sich über Agile zu informieren, daraus zu lernen und dann die Elemente (alle, einige oder keine) zu übernehmen, die Sie am effektivsten machen.

Abschluss

Wie bei den meisten Aspekten des Projektmanagements gibt es keine festgelegte Antwort auf Fragen, die auf den ersten Blick so offensichtlich erscheinen. Wie viele Aufgaben Sie in Ihrem Projekt haben und wie lange jede dieser Vorgänge dauern sollte, müssen Sie selbst suchen, um zu entscheiden... aber entscheiden Sie, dass Sie müssen.

Die Auswahl ihrer Projektauflösungsebene ist eine Projektmanagementverantwortung, die ein wichtiger Erfolgsfaktor bei der Verwaltung des Projektzeitplans sein kann.

Informationen zum Autor

Chris Vandersluis ist Präsident und Gründer von HMS Software aus Montreal, Kanada, einem zertifizierten Partner von Microsoft. Er verfügt über einen Abschluss der Wirtschaftswissenschaften der McGill University und über 30 Jahre Erfahrung in der Automatisierung von Projektleitsystemen. Er ist langjähriges Mitglied des Project Management Institute (PMI) und hat die Kapitel Montreal, Toronto und Quebec der Microsoft Project Users Group (MPUG) gegründet. Zu den Publikationen, für die Chris geschrieben hat, gehören Fortune, Heavy Construction News, Computing Canada Magazine und PMI's PMNetwork, und er ist ein regelmäßiger Kolumnist für Project Times. Er unterrichtet Advanced Project Management an der McGill University und spricht häufig in Projektmanagement-Verbandsfunktionen in Nordamerika und auf der ganzen Welt. HMS Software ist Herausgeber des projektorientierten Timekeeping-Systems TimeControl und seit 1995 Microsoft Project Solution Partner.

Chris Vandersluis ist per E-Mail erreichbar unter: chris.vandersluis@hms.ca

Weitere EPM-bezogene Artikel von Chris Vandersluis finden Sie auf der HMS EPM Guidance Site (https://www.epmguidance.com/?page_id=39).