Was nun Neuling? Oder wer nicht fragt, bleibt dumm …

3 min.

Summary

Sie kommen in ein neues Unternehmen und übernehmen eine neue Rolle oder Sie übernehmen ein neues Projekt? Wie Sie eine gute Übergabe planen hatte ich in Übergabe eines Programmes in 6 Phasen beschrieben. Nun sind Sie in einem Gespräch mit einem Ihrer neuen Mitarbeiter, um festzustellen, wo der Schuh drückt oder was als erstes angegangen werden muss. Da Sie in der Regel nicht nur ein Gespräch mit einem Kollegen führen werden, um einen gesamten Blick auf die Lage zu haben, empfiehlt es sich diese Gespräche strukturiert zu führen. Hierfür habe ich ein paar Fragen über die Jahre gesammelt, die für jedes Gespräch geeignet sind und interessante Aspekte heben können.

Wie gestalte ich die Gespräche?

Sie sollten immer gliedern zwischen teambezogenen und individuellen Fragestellungen, denn am Anfang fällt es leichter über das Team oder die Gesamtsituation zu sprechen, als direkt über seine eigenen Befindlichkeiten.

  • Team bzw. Gesamtsituation
    • Was ist die größte Herausforderung, vor der wir gerade oder in nächster Zukunft stehen?
    • Warum stehen wir vor dieser Herausforderung?
    • Was sind die vielversprechendsten und noch nicht ausgeschöpften Wachstumsmöglichkeiten?
    • Was müssen wir tun, um deren Potenzial auszuschöpfen?
    • Wenn Sie an meiner Stelle wäre, worauf würden Sie sich konzentrieren?
  • Individuell
    • Wie zufrieden mit Ihrer Aufgabe? In welche Richtung soll es weitergehen?
    • Was erwarten Sie von Ihrer Tätigkeit kurzfristig / mittelfristig?
    • Was erwarten Sie von mir?
    • Was sind Ihre Stärken / welche möchten Sie in das Team einbringen?
    • Welche Arbeitsabläufe können verbessert werden?
    • Wie ist die Zusammenarbeit/Produktivität im Team/die Teamatmosphäre?
    • Was benötigen Sie / das Team / die Abteilung, um bessere Leistung zu bringen.
  • Wünsche an die Fee?
    Eine Frage, die oft noch nicht geäußerte Ideen an den Tag bringt ist die Frage nach den drei Wünschen an die Fee. Konkret meint dies, welche 3 Wünsche würden Sie an die Fee stellen in dem gegeben Kontext. Überraschende und oft sehr hilfreiche Antworten kommen auf. Diese runden oft das Bild ab oder bringen ganz neue Aspekte hervor.

Wie frage ich nach?

Wenn der Gesprächsfluss ins Stocken kommt, Sie wollen eine klare Priorität erkennen oder Sie wollen etwas noch genauer herausfinden, dann bieten sich folgende Fragen an.

  • Gesprächs-Fit
    Ganz wichtig um herauszubekommen, ob dem Gegenüber gerade etwas bedrückt und somit das Gespräch zum jetzigen Zeitpunkt gar nicht sinnvoll ist.
  • Alternativfragen bzw. Vergleichsfragen
    • Was ist besser: Dies oder das? So oder so? Hier oder dort?
    • Wenn das, dann was? Falls nicht so, wodurch dann?
    • Skalierungsfragen: Auf einer Skala von 0 bis 10, wie geht es Ihnen in dieser Situation ein?
  • Ursachen-Feststellung
    Wenn Sie glauben, dass die genannte Ursache oder Grund noch nicht wirklich substanziell angesprochen ist, dann fassen Sie wie ein kleines Kind mit 5 mal „Warum?“ nach. Falls Sie sich nicht trauen diese anzuwenden: die 5-Why-Methode ist auch bei Wissenschaftlern beliebt.
    Das Fragen nach dem „Warum“ kann auch die Begründung des jeweiligen Verhaltens aufzeigen und die Motivation des Verhaltens offenlegen.
  • Paradoxe Fragen bzw. Verschlimmerungsfragen können helfen im Falle, dass kreative Lösungen gebaucht werden oder ein neuer Blickwinkel eingenommen werden soll. Beispiel ist, was muss ich tun, dass das Produkt ein Flop wird?
  • Zirkuläre Fragen helfen die Situationen aus verschiedenen Blickwinkeln zu betrachten. Z. B. Was würde Herr Müller dazu sagen?
  • Alternativ zur Fee-Frage können Sie auch die Wunderfrage platzieren: Ausgangssituation ist, dass wie durch ein Wunder alle Probleme gelöst sind und Sie Fragen was wäre anders, woran merkt man, dass das Problem weg ist, wie veränderte sich die Zusammenarbeit oder welche andere Veränderungsfrage hilfreich sein kann.

Regelmäßigkeit erreichen

Führen Sie derartige Gespräche unverzüglich nach Eintritt in die neue Rolle oder Aufgabe durch und vor allem auch regelmäßig durch. So bleiben Sie am Ball. Wollen Sie Veränderungen frühzeitig und über die gesamte Belegschaft oder das gesamte Team erfassen bietet sich mein Beitrag zur Teamstimmung und Frühindikation an. Die Fragen bieten sich auch recht gut als Grundlage für ein Mitarbeitergespräch an.

Stakeholder-Management als Element der Sechs Interdependenzen

4 min.

Summary

Um die richtigen Stakeholder des Projektes zu identifizieren wird die Umfeldanalyse als Vorläufer durchgeführt.  Die sozialen Umfeldfaktoren werden in die Stakeholderanalyse übernommen und es ist empfohlen diese nach folgenden Dimensionen zu betrachten: Macht und Konfliktpotential. Zielsetzung der Stakeholderanalyse ist es die Stakeholder zu gruppieren in den einzelnen Quadranten eines 4-Quandrantenportfolios um nachher eine entsprechende Anzahl von Stakeholderstrategien darin abzubilden. Konsolidiere ich die Stakholder in einem Stakeholderportfolio-Quadranten, habe ich die Chance über die gemeinsame Strategie des Quadranten auch eine konsolidierte Maßnahme zu planen. Es werden verschiedene Fehlerquellen bei der Erstellung der Stakeholderanalyse aufgezeigt.

Was ist ein Stakeholder?

Wie bereits in meinen „Sechs Interdependenzen“ angemerkt stellt die Betrachtung der Stakeholder eine wesentliche Komponente zum Projekterfolg dar. Stakeholder sind Einzelpersonen, Personengruppen, Organisationen oder die Gesamtheit all derer, die am Projekt beteiligt, von ihm direkt oder indirekt betroffen oder an diesem berechtigt interessiert sind.

Umfeldanalyse als Grundlage für die Stakeholderanalyse

Um die richtigen Stakeholder des Projektes zu identifizieren wird die Umfeldanalyse als Vorläufer durchgeführt. Die Projektumfeldanalyse ist eine bereits in der Initiierung einzuleitende und vorausgerichtete systematische Betrachtung, Beobachtung und Analyse der positiven (unterstützenden) und negativen (störenden) Einflüsse des Projektumfelds auf das Projekt. Dabei wird unterschieden in die sozialen und sachlichen Umfeldfaktoren. Eine weitere Unterscheidung kann getroffen werden in projektinterne, projektexterne oder unternehmensinterne oder unternehmensexterne Faktoren. Eine Differenzierung ausschließlich in intern und extern ist nicht spezifisch genug. Aus den sachlichen Umfeldfaktoren können Chancen und Risiken im weiteren Verlauf der Projektplanung ermittelt werden und Schnittstellen des Projektes bewusst gemacht werden.

Stakeholderanalyse und deren Ermittlung

Die sozialen Umfeldfaktoren werden in die Stakeholderanalyse übernommen und es ist empfohlen diese nach folgenden Dimensionen zu betrachten: Macht und Konfliktpotential. Andere Dimensionen wie Einfluss, Interesse können qualitative aber nicht zwangsläufig klar gruppierende Dimensionen sein. Interesse und Einfluss können jeweils positiv, negativ, jeweils mit hoher oder niedriger Ausprägung. Der Vorteil bei Macht und Konfliktpotential ist, dass diese hohe und niedrige Ausprägungen einnehmen können, aber nicht gleichzeitig positive oder negative. Wieso wollen wir nur hohe und niedrige Ausprägungen erfassen der beiden Dimensionen und nicht z. B. Werte mit sehr hoch, sehr niedrig etc.? Niedriges Konfliktpotential steht dabei vereinfachend für (potentielle oder tatsächliche) Promotoren und hohes Konfliktpotential dagegen für (potentielle oder tatsächliche) Opponenten. Eine weitere Differenzierung in potentielle und tatsächliche Gruppierungen würde die rasche und einfache Erfassung im Stakeholderportfolio verhindern. In der Praxis ist ohnehin eine ständige Betrachtung der (potentiellen) Opponenten und Promotoren erforderlich.

Zielsetzung der Stakeholderanalyse ist es die Stakeholder zu gruppieren in den einzelnen Quadranten eines 4-Quandrantenportfolios um nachher eine entsprechende Anzahl von Stakeholderstrategien darin abzubilden. Die Gruppierung der Stakeholder in einem Portfoilo erfolgt daher sinnvollerweise in hohe und niedrige Macht, hohes und niedriges Konfliktpotential. Eine direkte Zurordnung der Stakeholderstrategien kann dann direkt erfolgen.

Stakeholderstrategien und deren Zuordnung im Portfolio

Folgende Strategien können in einem Stakeholderportfolio vorgesehen sein:

  • partizipative Strategie, die auf Beteiligung und aktive Einbeziehung, Kommunikation und Information der Projektumfeldakteure setzen, z. B. gemeinsame Workshops zur Entscheidungsfindung,
  • diskursive Strategie, die (meist reaktiv) auf die sachliche Auseinandersetzung mit dem Projektumfeld, z. B. mittels Konfliktlösungsinstrumenten, ausgerichtet sind,
  • repressive Strategien, die durch Machteinsatz organisatorischer, informatorischer oder faktischer Art, z. B. Vorgaben des Managements oder selektive Information gekennzeichnet sind.

Für den vierten Quadranten empfiehlt es sich rein informatorische Maßnahmen vorzusehen, welche aber als sich keine wirkliche Strategie darstellt und daher auch nicht als solche bezeichnet wird.

Ein sinnvolles Stakeholder-Portfolio sieht somit wie folgt aus:

Stakeholderportfolio

Stakeholderstrategien – warum denn das?

Wieso möchte ich denn nun Strategien und nicht nur einfach Maßnahmen zu jedem Stakeholder betrachten. Maßnahmen pro Stakeholder sind zeit- und kostenintensiv. Sehe ich nun für jeden Stakeholder jeweils einzelne Maßnahmen vor, habe ich ein aufwendiges Maßnahmenbündel. Konsolidiere ich dagegen die Stakholder in einem Stakeholderportfolio-Quadranten, habe ich die Chance über die gemeinsame Strategie des Qudranten auch eine konsolidierte Maßnahme zu planen.

Typische Fehlerquellen bei der Stakeholderanalyse

Werden Stakeholderstrategien anhand anderer Dimensionen als Macht und Konfliktpotential abgebildet, besteht die Gefahr, dass die Stakeholder nicht eindeutig eingruppiert werden. Wird zum Beispiel anstatt der Dimension Macht das Interesse des Stakeholders beleuchtet werden insgeheim positive, negative, hohe und niedrige Gruppierungen möglich und daher dann eine Mehrfachzuordnung zu Portfolio-Quadranten wahrscheinlich. Dies konnte ich in sehr vielen fehlgeleiteten Stakeholderanalysen beobachten.

Ein weiteres Problem kann das Versäumnis einer kontinuierlichen Stakeholderanalyse sein. Stakeholder sollten Sie immer wieder neu betrachten. Durch Machtverschiebungen im Unternehmen kann die Dimension Macht, aber vor allem die Ausprägungen auf der Dimension Konfoliktpotential kann sich immer wieder verändern. Durch veränderte Einstellungen gegenüber dem Projekt aufgrund von Projektentwicklungen kann sich das Konfliktpotential des Stakeholders gegenüber dem Projekt verändern.

Ein Verzicht der kombinierten Angabe von Namen oder Rollen bereits in der Umfeldanalyse und dann auch in der Übernahme in die Stakeholderanalyse kann zu einer Pauschalierung und zu einem Übersehen von wichtigen Ausprägungen führen. Herr Mayer-Schulze kann ein pedantischer, konfliktreicher Mitstreiter sein, aber dagegen seine Rolle Anwender lässt darauf nicht unbedingt schließen.

Gruppierte Umfeldfaktoren wie z. B. „Lenkunsauschuss“ anstatt der Aufführung aller einzelnen Lenkungsauschuss-Mitgliedern verleitet eventuell zu Pauschalisierungen und damit dem Übersehen von spezifischen Interessen und Einflüssen.

Was gehört in den Statusbericht?

2 min.

Summary

Ein regelmäßiger Statusbericht ist wichtig im Projekt. Der Statusreport ist die grundlegende Information für die Mitglieder des Lenkungsausschusses. Es ist ratsam sich eine Liste der typischen Inhalte eines Berichtes anzulegen, welche egal in welcher Präsentationsform zu verwenden sind. Auch die Ampelfarben müssen wohl definiert sein um den Wassermelonen-Effekt zu verbannen.

Adressaten und Anlass

Ein regelmäßiger Statusbericht ist wichtig im Projekt. Regelmäßig bedeutet, dass dies ein vordefinierter Turnus oder zu bestimmten vordefinierten Anlässen erstellt und den festgelegten Empfängern zugestellt wird. Zielsetzung ist es den Projektfortschritt darzustellen, Entscheidungsbedarfe zu adressieren und Risiken und Probleme aufzuzeigen. Der Statusbericht ist die grundlegende Information aller Mitglieder des Lenkungsausschusses.

Inhalte des Berichtes

Jeder Statusbericht sollte folgendes umfassen:

  • Management Summary
  • Statusampel
  • Definierte Indikatoren (oft Leistung, Termin und Kosten) und optional deren Entwicklung in einer Earned Value Analyse
  • Erreichtes in der Berichtsperiode
  • Geplantes, aber Nichterreichtes in der Periode
  • Eingeleitet oder geplante Maßnahmen
  • Geplantes für die nächste Berichtsperiode / bevorstehende Meilensteine
  • Top-(3)-Risiken
  • Notwendige Entscheidungen

Statusampel-Farben und der ewige Streit

Immer wieder gibt es energiegeladene Diskussionen darüber, welche Farbe die Ampel haben sollte. Sich daran zu beteiligen macht oft keinen Sinn und man sollte als Projektleiter eine klare und vor allem einfache, leicht verständliche und für alle Ebenen gültige Definition zur Hand haben, um auch den Wassermelonen-Effekt (innen rot, außen grün) abwenden zu können. Folgende Definition kann von Hilfe sein:

  • Rot = Probleme vorhanden, welche nicht mehr auf der Ebene des Berichtenden gelöst werden können und sich negativ auf die definierten Indikatoren (meist Leistung, Termin, Kosten) auswirken oder bereits ausgewirkt haben. Maßnahmen waren nicht wirksam oder nicht möglich. Entscheidungs- oder Handlungsbedarf der übergeordneten Ebene (Ebene über der des Berichtenden) liegt vor.
  • Gelb = Die definierten Indikatoren zeigen Planabweichungen. Probleme vorhanden, welche durch den Berichtenden geplant gelöst werden. Maßnahmen wurden bzw. werden ergriffen (Liste der Maßnahmen erforderlich). Entscheidungs- oder Handlungsbedarf der übergeordneten Instanz ist absehbar, falls die getroffenen Maßnahmen nicht wirken.
  • Grün = Keine Probleme auf der Ebene des Berichtenden. Die definierten Indikatoren zeigen keine Planabweichungen.

Eine mögliche Dateinamenkonvention für den Statusbericht können Sie hier nachlesen.

Wie stelle ich das beste Team zusammen?

2 min.

Summary

Teamzusammensetzung und Rollenverständnis sind ein Erfolgsfaktor für eine ergolgreiche Projektdurchführung. Ein optimaler Mix an Kollegen im Team mit verschiedensten Eigenschaften kann anhand dem Modell von Belbin analysiert und definiert werden. Meine Beobachtung ist, dass in internationalen Teams durch die unterschiedlichen kulturellen Hintergründe der Mix oft einfacher erreicht werden kann. In Teams ohne klaren Führungsbefugnis ist es noch elementarer, dass die Teammitglieder gemäß Ihren Stärken eingesetzt werden und die Zusammensetzung des Teams „optimal“ ist.

Warum muss ich darauf achten?

Neben meiner festen Überzeugung, dass internationale und damit interkulturell zusammengestellte Teams die besten sind, sollten wir näher betrachten wieso das so ist. Besonders relevant ist eine Analyse in einer Umgebung in der Führung ohne Schulterklappen gegeben ist. Denn dort werden optimal zusammengesetzte Teams besonders wichtig.

Die Ursprünge der interkulturellen Effektivität bezüglich der Teamzusammenstellung ist bestimmt durch die Kulturdimensionen (zum Beispiel nach Hofstede) und damit stärkerer oder schwächerer Prägung der beteiligten Personen.

Was sagt Belbin?

Meredith Belbin stellt in 1981 neun Rollen vor, welche Berücksichtigung bei der Teamzusammenstellung finden sollten. Diese neun Rollen werden in drei Gruppen unterteilt.

  • Handlungsorientierte Rollen
    • Umsetzer (Implementer) = setzt Ideen und Pläne um
    • Perfektionist (Finisher) = Stellt qualitätsbewusstes Arbeiten sicher und sorgt für das Einhalten von Terminen
    • Macher (Shaper) = Spornt das Team zur Verbesserung an. Beseitigt Probleme.
  • Kommunikationsorientierte Rollen
    • Koordinator (Co-ordinator) = Koordiniert das Team und fördert die Ergebnisorientierung.
    • Teamarbeiter (Teamworker) = fördert die Teamzusammenstellung
    • Wegbereiter (Resource Investigator) = Fördert Hebung von Chancen und bildet Netzwerk im Projektumfeld aus.
  • Wissensorientierte Rollen
    • Neuerer (Plant) = Zeigt Ideen und Lösungsmöglichkeiten auf.
    • Beobachter (Monitor-Evaluator) = Analysiert Handlungsoptionen auf deren Umsetzbarkeit.
    • Spezialist (Specialist) = Bringt sein Fachwissen ein.

Wie findet es Anwendung?

Teammitglieder und Führungskräfte können durch Betrachtung der verschiedenen Rollen und der Reflektion daran im eigenen Team die jeweiligen Stärken und Schwächen identifizieren und damit Potentiale bei den Einzelpersonen, aber auch Potentiale für die Zusammensetzung von Teams nutzen. Durch ein gegenseitiges Verständnis und Bewusstseinsmachung der Eigenschaften kann das Team „ausbalanciert“ werden. Sicherlich werden oben genannte Rollen nie in Reinform vorzufinden sein, denn jeder nimmt unterschiedliche Rollen abhängig vom Projektkontext oder der Projektaufgabe an, aber dennoch helfen das Verständnis zumindest über die Tendenzen bei den Rollenprägungen für die Teamzusammenarbeit.

Vom „Magischen Dreieck“ zu den „Sechs Interdependenzen“

3 min.

Summary

Die Projektzielgrößen, das magische Dreieck, Tripple Constraint oder auch Objectives Triangle genannt ist eine konsolidierte Darstellung der Projektziele. Im Laufe der Zeit ist eine weitere Zielgröße hinzugefügt worden, die Stakeholderzufriedenheit, im speziellen die Auftraggeberzufriedenheit. Das Projekt wird im Kontext von Organisationen durchgeführt. Zumindest eine Organisation stellt Ressourcen in Form von Projektpersonal und sachlichen Einsatzmitteln zur Verfügung. Eine einfache Einsatzmittelplanung des Projektes, optimiert für das Projekt, isoliert vom Kontext ist nicht zielführend. Jedes Projekt hat nicht nur positive Aspekte, sondern verursacht auch einen Schaden. Dies sind die „Sechs Interdependenzen“, welche auch auf agile Projektmanagementansätze zutreffen.

Ursprung und die Entwicklung

Die Projektzielgrößen, das magische Dreieck, Tripple Constraint oder auch Objectives Triangle genannt ist eine konsolidierte Darstellung der Projektziele anhand den Messgrößen

  • Ergebnis bzw. Leistung,
  • Aufwand (Stunden bzw. Personentage und Kosten) und
  • Zeit (Dauern und Termine).

Im Laufe der Zeit ist eine weitere Zielgröße hinzugefügt worden, welche die Stakeholderzufriedenheit, davon vor allem die Auftraggeberzufriedenheit, darstellen soll. Eine Erweiterung zum magischen Viereck ist dabei nicht erfolgt, sondern wurde als Erweiterung des magischen Dreiecks gesehen.

Ein magisches Viereck im Zusammenhang mit Projektmanagement hielt fälschlicherweise Einzug in die Literatur, in der die Qualität separat aufgenommen wurde. Hiervon ist aber klar Abstand zu nehmen, da die Qualität inhärent in den vorgenannten Zielen verankert ist.

Wir können also festhalten, dass zunächst mindestens vier Messgrößen für den Projekterfolg sind: L, T, K und Stakeholderzufriedenheit.

Der Projekterfolg im Kontext des Umfeldes

Das Projekt wird im Kontext von Organisationen durchgeführt. Zumindest eine Organisation stellt Ressourcen in Form von Projektpersonal und sachlichen Einsatzmitteln zur Verfügung. Auch diese sind limitiert und es ist ein Bestandteil der Planungspflichten und damit Kriterium des Projekterfolges, wie effektiv das Projektpersonal und wie schonend/begrenzt die Projektressourcen für die Gesamtorganisation eingesetzt werden. Denn das Projektpersonal ist oft in der Linie mit anderen Aufgaben betraut und / oder die Mitarbeiter sind in anderen Projekten ebenso dringend gesucht. Die sachlichen Einsatzmittel wie ein Bagger werden z. B. auf einer anderen Baustelle ebenso wichtig für den Projektverlauf. Eine einfache Einsatzmittelplanung des Projektes optimiert für das Projekt isoliert vom Kontext ist nicht zielführend. Die Optimierungsbedarfe, welche der Projektdirektor, die Projektportfolio-Manager oder die Fachabteilungen vorgeben für Projekteinsatzmittel sind nicht nur ein einseitiger Prozess. Vielleicht würde die Berücksichtigung der Interdependenz Ressourcenoptimierung beim Projekterfolg auch den Gedankenkonstrukt „von Projektmitgliedern nur als Einsatzmitteln zu denken“ im Keim zu ersticken.

Jedes Projekt hat nicht nur positive Aspekte, sondern verursacht auch einen Schaden. Z. B. führt eine Implementierung einer Software eventuell zum Abbau von Arbeitsplätzen. Oder ein Umweltschutzprojekt zur Anlage eines neuen Naturschutzgebietes führt zum Verlust einer Ackerfläche eines Bauern. Hier entsteht ein Schaden für den Bauer, auch wenn er dafür sicherlich entschädigt wird. Hier haben wir also einen klaren Beitrag zum Projekterfolg in diesem Falle mit negativem Vorzeichen. Wir können diesen negativen Zahlbeitrag nicht einfach von der Leistung abziehen. Hier würden wir es uns zu einfach machen, denn die Leistung ist die gewünschte Dimension des Auftraggebers und berücksichtigt nicht zwangsläufig den Schaden.

Damit haben wir nun neben L, T, K und Stakeholderzufriedenheit zwei weitere Erfolgskriterien wie Ressourcenoptimierung und Projektschaden festgehalten.

Damit haben wir die „Sechs Interdependenzen“ umrissen.

Sechs Interdependenzen

Agilität und die Spiegelung der sechs Interdependenzen

Nun könnte man denken, das magische Dreieck war für mich als agiler Product Owner sowieso nie von Relevanz, da die Leistung durch die Zahl der Storypoints die in einem Sprint abgearbeitet werden können ohnehin „fix“ ist. Dies ist trügerisch und nicht wirklich zutreffend, da durch die Priorisierung des Backlogs selbstredend die wichtigste Leistung als „Bestandteil“ des Vorhabens definiert wird. Eine Umpriorisierung, eine Hinzunahme oder auch Wegnahme von Storys zu jedem Sprintbeginn verändert bewusst die Leistung des Vorhabens. Also dürften die sechs Interdependenzen auch in der agilen Praxis von Relevanz sein.

Für die Blogparade von Stephan Grabmeier #FutureBusiness

Vorgangsliste – warum denn das?

3 min.

Summary

Nach Abschluss der Arbeitspaketsplanung wird die Vorgangsliste als Tabelle erstellt. Sie ist die nachfolgend anzuwendende Methoden nach dem Projektstrukturplan. Die Vorgangsliste ist das Bindeglied zwischen dem Projektstrukturplan und dem Ablauf- und Terminplan.
Den wirklichen Mehrwert spielt die Vorgangsliste aus, als Mittel zur Reduzierung der Projektdauer, indem das Kernteam mit seiner Expertise und der Projektleiter möglichst viele sachlogische Abfolgen identifiziert die zu einer Reduzierung der Projektdauer beitragen können. Auch im agilen Umfeld wollen Abhängigkeiten wohl identifiziert sein und berücksichtigt werden. Das Aufsplitten von User Stories ohne die Schaffung von zusätzlichen Abhängigkeiten ist eine wichtige Fähigkeit des SCRUM-Teams.

Was ist die Vorgangsliste?

Nach Abschluss der Arbeitspaketsplanung wird die Vorgangsliste erstellt. Sie ist eine Tabelle aller Arbeitspakete und enthält wesentliche Informationen aus der Arbeitspaketsplanung aus der sich im weiteren Verlauf die Terminplanung ableitet.

Der Projektstrukturplan (PSP) hat noch keine Informationen über die sachliche Abfolge („fachlichen“ Abhängigkeiten). Hier hilft die Vorgangsliste weiter. Sie ist im Projektmanagement ein „Brückenmedium“ zwischen PSP und dem Ablauf- und Terminplan. Die Vorgangsliste ist eine Tabelle von Vorgängen des Projekts. Auf Basis der Vorgansliste kann der Projektmanager die Start- und Endtermine der Arbeitspakete ermitteln.

Was ist der Nutzen der Vorgangsliste?

Nach Erstellen der Vorgangsliste kann ein erstes Mal abgeschätzt werden, ob es möglich ist im Rahmen der vorhandenen Ressourcen das Projektziel zu erreichen. Jetzt nämlich ist eine Addition aller Kosten und aller Kapazitäten möglich, die von den AP-Verantwortlichen als erforderlich angesehen wurden. Ein Rückschluss auf die ausreichende Verfügbarkeit der notwendigen Kapazitäten ist jetzt allerdings noch nicht möglich, da normalerweise keine gleichmäßige Auslastung gegeben ist, sondern vielmehr einzelne Kapazitätsspitzen das Problem darstellen. Außerdem kann erfasst werden, welche Vorgänger notwendig sind, um ein Arbeitspaket zu starten.

Den wirklichen Mehrwert spielt die Vorgangsliste aus, als Mittel zur Reduzierung der Projektdauer, indem das Kernteam mit seiner Expertise und der Projektleiter möglichst viele sachlogische Abfolgen identifiziert die zu einer Reduzierung der Projektdauer beitragen können. Also ein blindes Anwender der Ende-Anfang-Abfolge, weil dies so schön bequem ist und diese einfach für alle Vorgänge vorzusehen würde dem Auftraggeber Projektlaufzeit kosten und damit Projektkosten in die Höhe treiben. Dem Projektleiter helfen alternative Abfolgen wie z. B. Anfang-Anfang eine Reduzierung der Zahl der Vorgänge auf dem kritischen Pfad. Eine Steuerung des Projektes wird dadurch vereinfacht. Die Inputs für die Abfolgebeziehung sollten die Arbeitspaketverantwortlichen nicht im stillen Kämmerlein definieren, sondern ins Kernteam (Teilprojektleiter bzw. Projektleiter im Programm) kommunizieren, welches dann damit optimierte Abfolgen festlegt. Die Erstellung und Durchsprache der Vorgangsliste hebt also bereits zum frühen Zeitpunkt späteres Optimierungspotential des Ablauf- und Terminplanes.

Abgrenzung / Vorläufer zum Terminplan

Aus der Abfolge der Arbeitspakete lässt sich ableiten, wann welches Arbeitspaket beginnt. Die Arbeitspakete, welche keinen direkten Vorgänger haben, können sofort starten. Alle anderen folgen nach. Eine erste Terminplanung kann daraus abgeleitet werden. Diese ist allerdings nicht viel mehr als ein Indikation, da vielfältige Rahmenbedingungen wie Urlaub des Personals, Kapazitätsschranken von wenig verfügbaren Qualifikationen nicht berücksichtigt sind.

Was ist die Vorgangsliste im agilen Umfeld?

Auch im agilen Umfeld wollen Abhängigkeiten wohl identifiziert sein und berücksichtigt werden. Hier wird über z. B. SCRUM-Teams hinweg bereits in der übergreifenden Backlog-Planung berücksichtigt wie sich Abhängigkeiten zwischen Backlog-Items darstellen. Die Aufteilung der Backlog-Items kann durch den Product Owner initial erfolgen, sollte aber durch das gesamte agile Team validiert werden bei der initialen Sprintplanung. Auch innerhalb von SCRUM-Teams werden Abhängigkeiten ständig neu evaluiert, da die kontinuierliche Priorisierung der User Stories eventuell zu zusätzlich identifizierten Abhängigkeiten führen kann. Das Aufsplitten von User Stories ohne die Schaffung von zusätzlichen Abhängigkeiten ist eine wichtige Fähigkeit des SCRUM-Teams. Hier sollte aber berücksichtigt werden, dass die User Stories nicht nur anhand der technischen Pfade aufgeteilt werden, sondern auch die funktionalen Fragen Berücksichtigung finden. Ansonsten wird der agile Ansatz konterkariert. Denn dann ist eine frühe und kleinteilige Lieferung an Funktionen nicht mehr gewährleistet. Diesen Spagat der Aufsplittung ist wie gesagt eine Kernkompetenz des gesamten Teams.

Regeln der Eskalation

2 min.

Summary

Eskalationen sind nichts Schlimmes im Projekt oder Programm. Sie sind das Einfordern der spontan notwendigen oder bisher nicht erfolgten Entscheidungen auf definierte Weise – vorausgesetzt eine geregelte Governance ist etabliert.

Regeln

Der Sachverhalt sollte immer von beiden Parteien (Kunde und Auftragnehmer) gemeinsam beschrieben werden und abgestimmt sein.

Inhalte der Eskalation

  • Genaue Beschreibung des Sachverhalts, so dass er von Dritten direkt verstanden werden kann.
  • In welchem Bereich und zu welchem Zeitpunkt ist der Sachverhalt entstanden?
  • Wer hat den Sachverhalt in welchem Reporting-Medium (z.B. wöchentlicher Statusbericht) auf die Tagesordnung gebracht?
  • Was ist getan worden, um das ursprüngliche Risiko bzw. Problem zu verhindern,  es  bei Auftreten zu lösen bzw. es abzumildern?
  • Wer war an der Lösungssuche beteiligt?
  • Wie zeitkritisch ist der Sachverhalt bzw. bis wann wird eine Lösung benötigt?
  • Benennung des Risikogrades und Bewertung der Auswirkung (Impact).
  • Welche Aktivitäten werden zur Lösung vorgeschlagen?
  • Beschreibung des Lösungsansatzes mit Schätzung der Zeitschiene (Timeline), der Ressourcen und der Benennung des Verantwortlichen für die Lösung.

Kommunikation

  • Eskalation immer über E-Mail.  Mails, die nicht alle obigen Sachverhalte beinhalten, sollten zurückgesendet werden.
  • Deutliche Nennung des Wortes “ESKALATION” in der Betreffzeile wie auch in der Mail selbst.

Nähere Informationen zu den Kommunikationsregeln finden Sie auch hier.

Eskalationsstufen

  • Alle möglichen Maßnahmen sollten ergriffen werden, um einen Eskalationssachverhalt auf der niedrigsten Stufe zu lösen. Vor dem Start eines Eskalationsprozesses sollten die Konsequenzen deutlich artikuliert werden.
  • Auf jeder Stufe sollte zwischen beiden Parteien versucht werden, eine Lösung zu finden. Ist diese nicht möglich, sollte – nach vorheriger Abstimmung und unter Berücksichtigung der Anzahl der Eskalationstage – der Eskalationssachverhalt an die jeweilig nächste Eskalationsstufe weitergegeben werden. (Eskalationstage = Verweildauer in Arbeitstagen auf einer Eskalationsstufe)
  • Der Projektmanager ist für die Problemlösung verantwortlich und bleibt es auch bei jeder Eskalationsstufe.
Eskalationspyramide

Projektfrühwarnsystem in 10 Fragen

5 min.

Summary

In Projektportfolio-Umgebungen oder auch für Projektdirektoren selbst, ist es oft nicht einfach, klare Signale aus den Projekten zu erhalten. Dies zur Prüfung, ob diese sich auf dem richtigen Weg befinden. Oft recht umfangreiche und komplexe Projektportfolio-Steuerungssysteme werden eingesetzt um genau dies zu ermitteln. Die Praxis zeigt, dass diese aufgrund der Heterogenität der Projekte (sehr groß vs. sehr klein, in Land X bzw. Land Y, im Geschäftsbereich A oder B) nicht dieselbe Zahl an zuverlässigen Messpunkten zu den verschiedensten Projekten verfügbar sind. Dieser Bericht zeigt, wie Sie auch bei unterschiedlichsten Projektgrößen und -arten durch 10 identische einfache Fragen, zuverlässige Frühwarnungen erhalten.

Warum bedarf es eines einfachen Projekt-Frühwarnsystems?

Eine andere Frühwarnung habe ich bereits hier beschrieben, die ganz andere Messgrößen hat. Je nach Anwendungsfall sollten diese Ansätze Anwendung finden. In einem Unternehmen mit hoch standardisierten Methoden, Prozessen und Tools im Projektmanagement ist der nächste logische Schritt weiter auf dem Weg zu noch mehr Qualität für Projekte die Überprüfung der Compliance dieser Vorgaben. Das Projektmanagementhandbuch beschreibt Prozesse, stellt Vorlagen und Tools zur Verfügung um jegliche Projektarten und Projektgrößen standardisiert abzuwickeln. Selbst die spezifische Anwendung von Standardapplikationen wie z. B. MS Project ist oft im Detail zu beschrieben und vorgegeben. Compliance-Kriterien ergeben sich daher im Bereich Policies, Prozesse, Vorlagen und Werkzeuge.

Weil effiziente und vor allem einheitliche Methoden oft fehlen, welche schnell Kernprobleme von Projekten aufzeigen können (und diese schnell abwenden können), wird das Senior-Management – trotz hoher Standardisierung im Projektmanagement – häufiger überrascht durch Projekte, welche

  • hinter dem Zeitplan liegen,
  • das Budget überschreiten
  • und den vereinbarten Leistungsumfang nicht erreichen

was wiederum zu

  • Unzufriedenheit von Kunden und das
  • Verfehlen von Geschäftszielen

führt.

Ein Frühwarnsystem (FWS) enthält Fragen zum Projektstatus, die in Form eines Fragebogens monatlich durch die Projektleiter zu beantworten sind.

Zielsetzung des Frühwarnsystems

Zielsetzung des Frühwarnsystems ist die Entwicklung und / oder die Integration einer Reihe von Tools und Prozessen, welche schnell potentielle Projekt-Problembereiche feststellen und ein sinnvolles Mittel zur Eskalation und Problembehebung bieten, solange sie noch in einfacher Form vorliegen um Überraschungen zu vermeiden.

Die Detail-Ziele können sein:

  • Einführung eines einfachen, skalierbaren Systems, das einfach zu warten ist durch „state of the art“-Technologie.
  • Einführung eines Systems welches es ermöglicht Probleme in Projekten aufzuzeigen und die Beseitigung dieser in der Angebotsphase, Start Up Phase und Run & Maintain Phase ermöglicht.
  • Einführung von Prozessen und Tools, welche nicht umgangen und ignoriert werden können; um die Compliance zu Prozessen und Tools zu bestätigen.
  • Die FWS-Ergebnisse zu nutzen um bestehende Berichte zu erweitern mit den FWS-Informationen.
  • Sicherstellen eines engen Time-Boxing von der Problemidentifikation bis zur Lösung.
  • Entwicklung eines Management-Kommunikationsplanes um das Senior-Management kontinuierlich zu informieren über die konsistente Implementierung und Durchsetzung der FWS Tools, Prozesse und Reporting im gesamten Unternehmen.

Die Erfolgsfaktoren des Frühwarnsystems

Um ein globales Frühwarnsystem sicherzustellen müssen folgende Erfolgsfaktoren eingehalten werden:

  • Zeitnahe und genaue Bewertung von Programm-/Projektstatus bezogen auf Schlüsselkennzeichen.
  • Das Linienmanagement mit Profit & Loss-Verantwortung für die Programme und Projekte ist verantwortlich auf negative Antworten zu reagieren und Maßnahmen zu verfolgen bis diese abgeschlossen sind.
  • Die Fragen müssen intensiv geprüft werden durch das Senior Management.
  • Die Fragen müssen global in allen eventuell vorhandenen regionalen Systemen unverändert verwendet werden.
  • Programm- und Projektmanager beantworten diese Fragen monatlich für jedes Projekt.
  • Standardreports werden den Programm-/Projekt-Sponsoren zur Verfügung gestellt um Maßnahmenverfolgung zu unterstützen.

Die Frühwarnsystem-Fragen

Folgende Fragen stellen eine Auswahl dar für ein Frühwarnsystem. Bei der Adaption für spezifische Organisationen werden auch die relativen Abweichungen in Form der Zahlenwerte angepasst. Die sogenannte Riskoantwort gibt die Antwortmöglichkeit an, welche zu einer Zwangskommentierung des Eintrages führt und in einer konsolidierten Auswertung als „Alarmsignal“ dient.

Nr.FrageRisikoantwort
1Ist die letzte Kundenumfrage mit mehr als 3,5 Punkten (von 5 Punkten) bewertet worden?
Nein
2 Wird der Projektplan wöchentlich mit geleisteter Arbeit und Restaufwänden aktualisiert und neu berechnet?
Nein
3 Sind alle genehmigten Änderungsanträge im Projektplan abgebildet?
Ja
4Verläuft die Personalbesetzung entsprechend der Planung im Projektplan?Ja
5Ist eine gemeinsame Projekt-Governance verabschiedet worden?Ja
6Wurde ein Lenkungsausschuss in den letzten 30 Tagen abgehalten?
Nein
7 Ist die Planabweichung (Schedule Variance) > 10%?
Ja
8 Ist die Kostenabweichung (Cost Variance) > 10%?
Ja
9Hat das Projekt Arbeit außerhalb des genehmigten Projektdefinitionsumfangs geleistet?Ja
10 Sind alle bisher erbrachten Leistungen abgenommen worden? Nein

In einem Datenbanksystem sind die Fragen im Feld „Antwort“ jeweils mit „Ja/Nein“ zu beantworten.

Ist eine Frage positiv beantwortet dann ist diese Frage abschließend beantwortet, also fertig.

Ist eine Frage negativ beantwortet dann wird von den Projektleitern die Eingabe von Maßnahmen zur Lösung der negativen Situation angefordert.

  • Feld „Maßnahme“: Maßnahme zur Lösung der negativen Situation eintragen
  • Feld „Verantwortlicher“: Den Namen des für die Maßnahme Zuständigen auswählen
  • Feld „Plan-Datum“: Datum angeben, bis zu dem die Maßnahme erledigt sein soll / muss (Plan-Datum)
  • Feld „Status“: Status der Maßnahme auswählen.

Die Ergebnisse werden idealerweise in ein unternehmensweites webbasiertes FWS-Tool dargestellt um zentrale Reports und Auswertungen erstellen zu können.

Das Zusammenspiel mit einem Projektmanagementhandbuch-Fragebogen

Sind (weltweit) einheitliche Richtlinien, Prozesse, Tools und Templates im Projektmanagementbereich verfügbar ist eine Erweiterung des Fragebogens in Betracht zu ziehen.

Eine detaillierte Befragung der Projektmanager sollte initial bei Projektstart und bei wesentlichen Projektänderungen durch einen ausführlichen Self-Assessment-Fragebogen erfolgen, welcher deutlich über folgende mögliche FWS-Ergänzungsfragen hinausgeht.

Nr.FrageRisikoantwort
1Wurde die Projektdefinitions-Vorlage aus dem Projektmanagementhandbuch verwendet?nein
2Wurde das Schätzverfahren und die Schätztemplates verwendet gemäß Projektmanagementhandbuch?nein
3Wird wöchentlich eine Earned Value Berechnung basierend auf dem aktuellen Projektplan durchgeführt?nein
4Werden Probleme, Risiken, Abnahmen, Change Requests kontinuierlich im Template aus dem Projektmanagementhandbuch festgehalten?nein

Persönliche Beobachtungen zum FWS

Folgende Beobachtungen konnte ich bei der Betreuung von Projektmanagern zum Thema FWS und den Auswertungen feststellen:

  • Trotz sehr präziser und eindeutiger Fragen ist häufig eine zusätzliche Erläuterung (idealerweise durch eine Handbuch) gegenüber den Projektmanagern und in anderer Richtung eine Kommentierung spezifischer Sachverhalte durch die Projektmanager erforderlich. Einheitliche Vorgaben durch die von zentraler Stelle für spezifische nicht standardisierte Fälle sind sicherzustellen. Damit kann die Qualität auch für diese Fälle bezüglich der Aussagekraft des Frühwarnsystems sichergestellt werden.
  • Bei den Projektmanagementhandbuch-Ergänzungsfragen hat sich bestätigt, dass nur durch bereits ausgebildete Projekt- und Programmmanager sprechende Antworten gegeben werden konnten. Es ist besser auf eine Muss-Antwort zu verzichten um die Qualität der Aussagen nicht zu verwässern.

Bei der Analyse zur Adaptierung eines vergleichbaren Systems in einer Organisation ergeben sich folgende grundsätzlichen Überlegungen:

  • Die ersten Fragen lassen sich nahezu vollständig auf andere Unternehmen übertragen.
  • Ein derartiges ergänzendes (paralleles) Reporting ist nur durch globale Vorgaben durchzusetzen. Regionale oder gar abteilungsbezogene Initiativen würden zu viel Widerstand erfahren.
  • Eine automatische Benachrichtigung und Erinnerung zur Anlage des FWS-Berichtes ist vorzusehen.
  • Eine monatliche Frequenz kann sich, bei anderen Unternehmen mit durchschnittlich kleineren Projekten, als zu gering erweisen.
  • Eine automatische Analyse der Ergebnisse ist erforderlich unter Berücksichtigung der manuellen Zusatzkommentare. Eine Analyse ohne Berücksichtigung der Zusatzkommentare ergibt ein falsches Bild auf die Gesamtauswertung.
  • Wie bei allen anderen Reporting ist auch hier zu beachten, dass bei besonders vertraulichen Projekten / Kundenumfeldern ein Frühwarnsystem ebenfalls ausgeschlossen sein kann.
  • Die Berichte müssen IT-technisch so abgebildet sein, dass sie (nahezu) nicht umgangen und ignoriert werden können; um die Compliance zu Prozessen und Tools zu bestätigen. Diese sollten z. B. mit der Ablage des offiziellen Statusreports verbunden sein.
  • Die FWS-Ergebnisse sollten in bestehende Reports eingebunden sein um die klassischen Adressaten des Projektstatusberichtes ebenfalls über den Zusatzstatus des Frühwarnsystems zu informieren. Somit ist sichergestellt, dass auch dieser Empfängerkreis eine direkte oder indirekte Qualitätssicherung der Angaben durchführt.
  • Die Ergebnisse des Frühwarnsystems sollten regelmäßig mit vollständigen Projekt- oder Programmaudits verglichen werden um die Aussagekraft zu validieren und kontinuierlich zu verbessern.
  • Das Frühwarnsystem darf in einem Projekt nicht erst durch die erstmalige Ablage eines Projektstatusberichtes, sondern z. B. durch die Anlage von Projektnummern oder Projektcodes initial ausgelöst werden.
  • Das Frühwarnsystem sollte in Stufen eingeführt werden. Zuerst sollten ausschließlich Projekte mit hohem Projektvolumina oder Komplexität in den Umfang eingeschlossen werden (wichtig ist hierbei harte Kriterien anzuwenden). Dies erlaubt auch den Betreuungsaufwand der Projektmanager durch die Analysten besser zu managen.

Übergabe eines Programmes in 6 Phasen

2 min.

Summary

Sobald Sie ein Programm übergeben, sollten Sie einige Dinge bei der Vorbereitung und Übergabe selbst beachten. Hier hat sich für mich ein 6-Phasen-Ansatz bewährt welcher bei mir immer wieder eingesetzt wird.

1. Preparation (so früh wie möglich!)

  • Abstimmung mit den Stakeholdern
  • Überblick über den Wissenstransfer-Plan
  • Budget für Wissenstransferperiode vereinbaren
  • Suche nach einem Nachfolger und Erhalt der Zustimmung zu einer bestimmten Person von Stakeholdern
  • Endgültiges Startdatum des Nachfolgers bestätigen (Zeitleiste des Wissenstransferplans anpassen)

2. On-Boarding (-3 Wochen)

  • Nachfolger startet im Projekt als zusätzliche Ressource
  • Projektvereinbarung definieren
  • Nachfolger in allen regulären Administrationstätigkeiten wie Zugriffsrechte, Kalendereinladungen, Übergabeprozessdokumentation etc. einbinden
  • Nachfolger im Newsletter vorstellen

3. Shadowing (-2 Wochen)

  • Nachfolger war Ihr bisheriger Stellvertreter, wenn möglich.
  • Der Nachfolger nimmt auch in Ihren besuchten Meetings teil.
  • Der Nachfolger beobachtet alle Ihre Kernaktivitäten.
  • Nachfolger aktualisiert und ändert gemeinsamen Plan für den Wissenstransfer und leitet Aktivitäten ein.

4. Re-Shadowing (-1 Woche)

  • Nachfolger übernimmt Verantwortung
  • Räumen Sie Ihren Schreibtisch und übergeben Sie ihn an den Nachfolger
  • Der Nachfolger leitet alle Ihre früheren Meetings
  • Der Nachfolger ist für alle Ihre bisherigen Prozesse verantwortlich
  • Stehen Sie zur Verfügung für alle Fragen Ihres Nachfolgers

5. Backup (beginnt mit dem Tag der Übergabe)

  • Weniger Präsenz zeigen, nur an internen Teambesprechungen teilnehmen, aber keine Kundengespräche
  • Seien Sie für jede Hilfe für Ihren Nachfolger da
  • Bereiten Sie sich darauf vor, einige operative Tätigkeiten zu übernehmen um den Nachfolger bei der Einarbeitung zu entlasten
  • Senden Sie alle noch eingehenden Anfragen / Fragen an Ihren Nachfolger

6. Phase Out (+1 Woche)

  • Erledigen Sie alle Off-Boarding-Aktivitäten selbst
  • Projektvereinbarung auflösen
  • Seien Sie da, um Ihrem Nachfolger zu helfen
  • Nehmen Sie keine Betriebsaufgaben mehr an
  • Geben Sie eine Abschiedsparty und verabschieden Sie sich im Newsletter
  • Senden Sie alle noch eingehenden Anfragen / Fragen an Ihren Nachfolger
  • Gehen Sie! (+2 Wochen)

Erfolgsfaktoren für eine ordnungsgemäße Übergabe

  • Binden Sie Kunden und alle Stakeholder frühzeitig ein.
  • Ordnen Sie Prozesse nicht programm- / personenzentriert an, sondern prozess- / verantwortungsszentriert.
    • Seien Sie nicht selbst Single Point of Contact für mehrere Prozesse,
    • Machen Sie stattdessen jedes Ihrer Teammitglieder von Anfang an für einen oder mehrere Prozesse verantwortlich (Management by Objective).
  • Planen und bereiten Sie Ihre Übergabe als eigenes Projekt vor.
  • Erstellung eines Wissenstransferplans, der von allen Beteiligten abgestimmt werden muss.
    • Aufschlüsselung des Wissenstransfers in granulare Aktivitäten (1-3 Stunden).
    • Bitten Sie Ihren Nachfolger, diesen Plan zu pflegen und jede abgeschlossene Aktivität abzuhaken.
    • Behandeln Sie diesen Plan und aktualisieren Sie ihn wie jeden anderen Projektplan.
  • Kommunizieren Sie Ihren Weggang dem gesamten Team spätestens zu Beginn der Wissenstransferphase.
  • Sehen Sie nach erfolgreichem Wissenstransfer eine Backup-Phase vor von bis zu zwei Wochen.
  • Definieren Sie ein klares Übergabedatum im Wissenstransferplan.

Viel Spaß in Ihrem neuen Projekt / Programm!

Projektplanungssoftware – alles nur Mist?!

1 Minute


Summary

Die Projektplanungs- und Steuerungssoftware nur als visuelle Darstellung des Planungsstandes zu nutzen ist vergeudete Zeit. Einige wenige Tipps sind zu befolgen und MS Project und Co sind auch für die Projektüberwachung und -steuerung sehr sinnvoll einzusetzen.

Ich höre immer wieder von angehenden Projektmanagern, aber auch von erfahrenen Projektmanagern, dass ein Projektsteuerungstool wie z. B. MS Project nicht praktikabel einzusetzen ist. Es sei zu kompliziert und die eigentliche Steuerung sei damit auch nicht wirklich möglich.

Wenn Du folgende Tipps beachtest geht nichts mehr schief

  • Stelle in den Optionen ein, dass MS Project oder das Tool Deiner Wahl die Planung auf „feste Arbeit“ basiert
  • Die Verfügbarkeiten (Stundenkapazität und Urlaube) der Ressourcen/Qualifikationen müssen im Projektkalender eingetragen werden.
  • Kein manuelles Datum (Termin) setzen, außer Projektstart oder Endtermin.
  • Für jeden Vorgang / Arbeitspaket muss ein Vorgänger (zumindest der Projektstartmeilenstein) und Nachfolger (zumindest der Projektendmeilenstein) eingetragen werden.
  • Keine Dauer eingeben, sondern nur Aufwand für den Vorgang / Arbeitspaket.
  • Für jeden Vorgang sollte nur eine Ressource/Qualifikation eingetragen werden.
  • Den kritisch Pfad im Ablauf- und Terminplan (Gantt) immer anzeigen lassen. Dieser muss durchgängig über die gesamte Projektlaufzeit ohne Unterbrechung angezeigt werden. Ansonsten liegt ein Fehler vor, wie z. B. manuelles Datum gesetzt.
  • Plane nur maximal 2-3 Monate rollierend im Detail (Ressourcen und Aufwände) voraus.

Und das letzte Hemmnis ist dann immer wieder, dass Dein Unternehmen keine MS Project Lizenz für Dich investiert. Dann besorge Dir ProjectLibre als Opensource oder eine andere Freeware.