CK08201

Der Dreizwang (1121)

Um was geht’s?

Der Dreizwang – oder auch „magisches Dreieck“ oder auch „Triple Constraint“ – ist eines der grundlegenden Konzepte im Projektgeschäft.



Kurze Erinnerungshilfe
  • Zeit – Kosten – Inhalt und Umfang. Oder: schnell – günstig – gut.
  • Es gibt immer eine Reihenfolge. Und die Reihenfolge entscheidet, wie das Projekt gemanagt wird.
  • Wenn zwei Aspekte bedient werden, neigt der Dritte dazu sich ins Gegenteil zu verkehren.
  • Qualität kann eine vierte Dimension sein, aber die Produktqualität wird üblicherweise über den Inhalt und Umfang abgebildet.
  • Projektqualität hingegen ist die Harmonie aller drei Seiten.
  • Wird eine Dimension geändert, ändert sich mindestens eine weitere mit.


Kurze Erinnerungshilfe
  • Der Projektleiter muss die „Zielsequenz“ des Auftraggebers (Sponsors) kennen und umsetzen.
  • Daher: Unbedingt die „Zielsequenz“ des Sponsors verstehen! Beispielsweise, indem Sie die Schmerzgrenzen der jeweiligen Zieldimension herausfinden.
  • Aufpassen bei unterschiedlichen Prioritäten von unterschiedlichen Seiten.

Und in der Praxis?

Dieses kleine Gedankenmodell ist von alles entscheidender Bedeutung für das Gelingen eines Projekts. Vor allem, weil in der Praxis sogar zwei Dreiecke gleichzeitig existieren: Das Dreieck der eigenen Firma und dann das des Kunden in seinem Projektumfeld.

Aber nicht nur dieser Punkt schafft spezielle Herausforderungen. Meist bekommen Sie vom Kunden auch den Eindruck, dass der Termin und das Budget (also known as „Preis“) ganz oben auf der Agenda stehen. Aber mal Hand aufs Herz: Wurden Sie vom Kunden beauftragt, damit Ihr Produkt der dritte Schenkel des Dreiecks ist?


Reflexionsfragen
  • Kennen Sie die Sequenz in Ihrem Projekt?
  • Richten Sie Ihre Managementhandlungen nach dieser Sequenz aus?
  • Sind Sie auch zur Korrektur Ihrer Einstellung bereit, wenn sich herausstellt, dass die Sequenz doch eine andere ist?

Copyright Gita GmbHAlle Rechte vorbehalten

Der Dreizwang (1121) Read More »

Strategie und Projekt (1119)

Um was geht’s?

Wie hängen Projekte mit der Verfolgung der Unternehmensstrategie zusammen? Gibt es überhaupt einen Zusammenhang? Und wenn ja, wie lässt sich dieser leicht ermitteln?



Kurze Erinnerungshilfe
  • Strategie ist die Absicht des Unternehmens, Projekte sind der Weg für die Umsetzung.
  • Projekte sind daher kein Selbstzweck: Ändert sich die Strategie, ändert sich das Projekt.
  • Projekte sind und bedeuten immer „Change“.
  • Jedes Projekt muss seinen Strategiebeitrag nennen können.

Und in der Praxis, speziell, wenn Projekte im Kundenauftrag gemacht werden?

Wie sieht diese Strategiediskussion denn nun bei Kundenprojekten aus?

Einerseits die Kundensicht: Der Kunde hat eine Strategie (oder sollte sie haben). Unser Projekt beim Kunden ist ein Teil der Umsetzung seiner Strategie.

Andererseits unsere eigene Sicht: Wir selber (unsere Firma) hat ja auch eine Strategie, in der dieses Kundenprojekt einen wertvollen Beitrag leistet. Unser Projekt beim Kunden ist damit auch ein Teil der Umsetzung unserer Strategie.

Es ist hilfreich, beide Strategien zu kennen, um sich mit seinem Projekt auch verorten zu können.
In der Regel hat der Vertrieb für die Kundenstrategie ein sehr offenes Ohr gehabt, da er die Lösung seines Hauses als passgenau in die Kundenstrategie einbauen konnte.
Das heißt: Meist liegen diese Kunden-Informationen schon vor, man muss sie sich nur holen. Wir können nun diskutieren, ob das eine Hol- oder Bringschuld ist, aber da wir aus Sicht des Projektmanagements mit dem Kunden klar kommen möchten, müssen und wollen, liegt es in unserem Interesse, sich um diese Informationen zu kümmern…


Reflexionsfragen
  • Für beide Ebenen (also intern und extern):
  • Kennen Sie die Strategie, in die Ihr Projekt passt?
  • Kennen Sie den Strategiebeitrag Ihres Projektes? Zentral? Oder nur Nebenbühne?
  • Gibt es weitere, parallel laufende andere Projekt, die die Strategie ergänzen oder um sie konkurrieren oder gar torpedieren?

Copyright Gita GmbHAlle Rechte vorbehalten.

Strategie und Projekt (1119) Read More »

Was ist ein Projekt? (1118)

Um was geht’s?

Um die Abgrenzung von einem Projekt zu anderen betrieblichen Tätigkeiten. Was genau macht denn ein Projekt aus? Und was sind die Konsequenzen dieser Erkenntnis?



Kurze Erinnerungshilfe
  • Projekt: zeitlich begrenzt, einmalig, hat ein Ergebnis.
  • Anfang und Ende: Wann genau beginnt ein Projekt? Wann genau endet es?
  • Anfang und Ende: Der Projektlebenszyklus beschreibt es.
  • Achtung! Zombieprojekte!
  • Was sind die Projektziele?
  • Was genau bedeutet einmalig?
  • Einmaligkeit bedingt situative Dynamik und Verantwortung.
  • Gegenteil von Projekt?

Und in der Praxis?

Wie wir eben gesehen haben, ist die Projektdefinition einerseits trivial, andererseits aber herausfordernd genug für den Projektalltag. Wie kann man nun die Standarddefinition eines Projektes für Projekte im Professional Service verstehen bzw. umsetzen?
Erste Erkenntnis: So viel anders ist das auch im Professional Service eigentlich gar nicht. Vielmehr ist es entscheidend zu verstehen, wann und wo genau das Projekt beginnt. Und hier haben Kunde, Vertrieb und Professional Service unterschiedliche Interpretationen, die es erst einmal zu synchronisieren gilt.
Diese Synchronisation darf nicht zu Lasten des Kunden gehen und es kann auch sein, dass der Vertrieb aus taktischen Gründen Zusagen gemacht hat, die zwar den Auftrag „gerettet“ haben, aber dem Professional Service nun eine starke Hypothek für die Projektdurchführung aufbürdet.
Genau so ein ähnliches Problem existiert am Projektende: Ist das Projekt wirklich beendet, wenn es zu Ende ist? Oder hat der Projektmitarbeiter noch endlos lange mit der Wartung und Betreuung zu tun? Er / sie bekommt den Kunden nicht mehr los, weil er/sie der Einzige ist, der sich mit dem Thema auskennt?


Reflexionsfragen
  • Ist der Projektstart klar erkennbar?
  • Gibt es einen definierten Übergang vom Vertrieb (oder generell aus der Zeit vor Projektstart) zum Projekt bzw. Projektstart?
  • Sind die vagen Zusagen im Vorfeld (Vertrieb?) unrealistisch und/oder bürden dem Projekt Hypotheken auf?
  • Bekommt der „Projekteur“ das Produkt/Projekt/den Kunden am Ende wieder los und kann die Nachfolgebetreuung in eine andere Einheit abgeben?

Copyright Gita GmbHAlle Rechte vorbehalten.

Was ist ein Projekt? (1118) Read More »

Change planen und managen (1159)

Um was geht’s?

Jetzt geht es um Change, also Änderungen am Projekt. Es ist zu unterscheiden: Projekte bringen selbst immer Change in die Trägerorganisation. Davon soll hier aber nicht die Rede sein.

Es geht um Änderungen innerhalb des Projektes , also um Änderungen an den Zielgrößen. Nachlässiges Changemanagement kann ein an sich gut aufgestelltes Projekt schnell ruinieren.



Kurze Erinnerungshilfe
  • Wieder ein Planungsthema: Wie möchten wir in unserem Projekt Change Management durchführen?
  • Aspekte eines Change Management Plans könnten sein:
    • Für welche Änderungen gilt der Change-Prozess?
    • Wie wahrscheinlich sind Änderungen ?
    • Welchen Aufwand wird das Änderungsverfahren an sich benötigen?
    • Wer hat welche Rolle, welche Verantwortlichkeit, welche Befugnisse?
    • Wie zeichnen wir die Changes auf, wie berichten wir sie?
    • Welche Arten, Kategorien von Changes gibt es?
    • Wie werden Änderungen evaluiert?
    • Wie und wann wird die Projektdokumentation aktualisiert?
    • Wie wird das Projektteam über Änderungen informiert?
  • Wichtig: Nicht alles muss für jedes Projekt zutreffen.


Kurze Erinnerungshilfe
  • Wenn wir einen Change vorliegen haben:
    • Change analysieren und bewerten.
    • Bewertung der Gesamtauswirkung zur Entscheidung vorlegen.
    • Entscheiden lassen.
    • Entscheidung umsetzen.
    • Gesamtsystem konsistent halten.
  • Zur Konsistenz:
    • Alle Projektmanagementartefakte müssen zueinander passen.
    • Was muss ich also alles ändern, wenn sich irgendwo ein Change ergibt?
    • Das Konsistent-halten kann auch als Konfigurationsmanagement (Welche Version von welchem „Teil“ passt zu welcher Version eines anderen „Teils“ und bilden zusammen eine gültige Gesamtkonfiguration?) gesehen werden.

Und in der Praxis?

In Bezug auf Change und Berichtswesen gibt es einen einfachen Zusammenhang, der schnell erkennen lässt, ob das Change Management funktioniert: Nehmen Sie in den Statusbericht eine Metrik auf, die zeigt, wie viele Changes bearbeitet wurden und ob die augenblickliche Projektsituation diese Changes widerspiegelt. Sowohl aus Sicht des Projektprozesses (angepasste Zeitpläne etc.) als auch administrativ (Change Request liegt unterschrieben vor).


LernLetter

LernLetter sind ergänzende PDF-Dokumente, die ein Themengebiet noch weiter behandeln und ein Stück tiefer in die Materie eindringen.


Reflexionsfragen
  • Wie handhaben Sie in Ihrem Projekt das Change Management? Gibt es einen mit dem Auftraggeber abgestimmten Ablauf? Welches Gremium wird über Veränderungen informiert und bewertet diese?
  • Wie aktuell ist Ihre Projektdokumentation? Sind da alle Changes eingebaut?
  • Können Sie auch nach einem Change wieder eine verlässliche Standortposition abgeben?

Copyright Gita GmbHAlle Rechte vorbehalten

Change planen und managen (1159) Read More »

Steuerungsregelkreis (1158)

Um was geht’s?

Wie wird gesteuert? Da gibt es einen Regelkreis der Steuerung, der hier kurz vorgestellt wird und in diesem Zusammenhang sprechen wir auch über Plan-Abweichungen.



Kurze Erinnerungshilfe
  • Eng verbunden mit dem PDCA-Zyklus.
  • Aspekte und Aktivitäten:
    • Wo liegt meine tatsächliche Projektleistung im Vergleich zur Planung?
    • Bewertung der erbrachten Leistung über den Fertigstellungsgrad.
    • Sind Korrekturmaßnahmen notwendig?
    • Pflege einer zeitnahen Informationsbasis.


Kurze Erinnerungshilfe
  • Was bedeutet denn Abweichung vom Plan eigentlich?
  • Wenn wir nicht genau im Plan sind, muss das keine Abweichung vom Plan bedeuten:
    • Wir sind immer noch in den vereinbarten Varianzen, in den akzeptierten Schwankungsbreiten.
    • Oder: Wir haben eine echte Abweichung und führen eine Korrektur durch, um zurück zum Plan zu kommen.
    • Oder: Wir habe eine echte Abweichung – und planen ab jetzt neu für den Rest.
      • Völlig in Ordnung, solang nicht ständig neu geplant wird, ohne nach den Ursachen zu suchen.
      • Eine Möglichkeit, um das festzustellen: Immer mal wieder auf den ursprünglichen Basisplan schauen.

Und in der Praxis?

Das Thema Steuerung und dann auch Change ist in vielen Projekten ein sehr unbeliebtes Thema. Ein Change zerstört zuerst einmal die Grundplanung, ist also so gesehen nicht willkommen, zumindest nicht aus Sicht des Projektpersonals. Dabei macht es keinen Unterschied, ob der Change bezahlt wird oder nicht.

Hier treffen dann auch verschiedene Interessen aufeinander. Ein bezahlter Change kann aus Sicht der Serviceorganisation hochwillkommen sein. Oftmals ist der Business Case beim Kundenprojekt darauf gebaut, dass es genügend Changes gibt, die erst den Deckungsbeitrag für das Projekt liefern.

Andererseits erfordert jeder Change vom Projektleiter erhöhte Nachplanungsarbeit, die von den Beteiligten oftmals nicht gesehen oder gewürdigt wird.
Die große Gefahr, die hier lauert, ist simpel: Vor lauter Tagesgeschäft hat das Projektpersonal gar keine Zeit, die Planung nachzuarbeiten.
Ergebnis: Schnell sind alle bisher getroffenen Überlegungen Makulatur…


Reflexionsfragen
  • Was sind aus Ihrer Sicht die Ursachen für Abweichungen im Projekt?
  • Welche Maßnahmen helfen Ihnen, diese zu entdecken und zu bewerten?
  • Wie steuern Sie in Ihren Projekten Änderungen?

Copyright Gita GmbHAlle Rechte vorbehalten

Steuerungsregelkreis (1158) Read More »

Berichtswesen (1157)

Um was geht’s?

In diesem Kapitel finden sich ein paar Gedanken zum Thema Berichtswesen. Was sind essentielle Inhalte? Aber vor allem: Für wen sind diese Berichte gemacht?



Kurze Erinnerungshilfe
  • Wer benötigt welche Information?
  • Weitere Fragen, die es zu klären gilt:
    • Verstehen die Stakeholder die Berichte überhaupt? Oder trauen Sie sich bloß nicht nachzufragen?
    • Sind die Kennzahlen selbsterklärend? Was bedeutet eine Kennzahl? Ist die Kennzahl sinnvoll im Sinne der Zielerreichung? 
    • Sind die verwendeten Metriken auch korrekt?
    • Haben wir wirkliche Zustimmung zu den Berichten erfahren?
  • Es ist Aufgabe des Projektleiters, die Verständlichkeit der Berichte sicherzustellen.
  • „Not everything that counts can be counted, and not everything that can be counted counts.“ Albert Einstein


Kurze Erinnerungshilfe
  • Information an die Stakeholder im Bezug auf den Plan:
    1. Wo kommen wir her?
    2. Wo stehen wir gerade?
    3. Erreichen wir unsere Ziele?
  • Ganz wichtig ist die #3 – die aber häufig zu gering gewichtet wird.
  • Ideale Gewichtung eines Statusberichts ist:
    1. Erreichen wir unsere Ziele?
    2. Wo stehen wir gerade?
    3. Wo kommen wir her?


Und in der Praxis?

Berichtswesen geht über Statusreports und Berichtsampeln hinaus. Schauen Sie auf Ihren Kommunikationsplan und überlegen Sie, wie alle angedachten Kommunikationselemente im Laufe des Projekts auch untergebracht und durchgeführt werden können.


Reflexionsfragen
  • Kennen Sie die Reporting-Erwartungen Ihrer Stakeholder?
  • Wie halten Sie es in Ihrem Projekt mit dem Reporting?
  • Welche Kennzahlen erheben Sie und werden diese von allen im Team und vor allem vom Auftraggeber verstanden?
  • Erstellen Sie regelmäßige Statusberichte? Ist das für Sie ein notwendiges Übel oder Pflichtaufgabe?
  • Wie erheben Sie die Kennzahlen für Ihre Statusberichte?
  • Erhalten Sie verlässliche Angaben aus dem Team zur Arbeitsleistung?
  • Sind diese transparent und teilen alle dieselbe Definition der Statuswerte?

Copyright Gita GmbHAlle Rechte vorbehalten

Berichtswesen (1157) Read More »

Fertigstellungsgrad (1155)

Um was geht’s?

Der Fertigstellungsgrad ist eine der Grundmetriken im Projektmanagement. Im Prinzip mal wieder ganz einfach – in der Praxis aber mit ein paar kniffligen Details gewürzt. Vor allem die Bewertung angefangener Arbeit kann Stoff für Diskussionen geben.


Kurze Erinnerungshilfe
  • Fertigstellungsgrad ist Positionsbestimmung.
  • Gerechnet wird immer gegen den Basisplan.
  • Auch wenn wir mehr Zeit/Geld brauchen als geplant, wird das Arbeitspaket nur zu den geplanten Werten bewertet.
  • Nicht begonnene und fertiggestellte Arbeit ist einfach zu bewerten: 0% bzw. 100%.
  • Für „in Arbeit“ befindliche Pakete gibt es mehrere Methoden
    • 20/80-Methode oder Varianten davon
    • Schätzung 

Und in der Praxis?

Es ist eines der wichtigsten Fragen aus dem Bereich des Berichtswesens: „Wie fertig ist das Projekt?“ oder alternativ „Schaffen wir’s?„.

Leider wird diese Frage zu oft „aus dem Bauch“ beantwortet oder die Verantwortlichen der Arbeitspakete melden schnell die berühmten 80%. Leider wird in der Praxis auch oft vermieden, den Gesamtumfang (zumindest versuchsweise) anzugeben, um daraus eine Prozentzahl abzuleiten.

Die Praxis zeigt leider, dass viele Projektbeteiligte viel zu optimistisch unterwegs sind, was dann am Ende in teure Feuerwehreinsätze mündet.


Reflexionsfragen
  • Wie ermitteln Sie den Fertigstellungsgrad?
  • Welche Erfahrung haben Sie mit dem Reporting von Fertigstellungsgraden gemacht? Waren die Angaben verlässlich?
  • Gibt es in Ihrem Projekt ein gemeinsames Verständnis, was zum Abschluss eines Arbeitspakets gehört? Kennen Sie das Problem, dass ein Fertigstellungsgrad von 95% sehr lange stehen kann?

Copyright Gita GmbHAlle Rechte vorbehalten

Fertigstellungsgrad (1155) Read More »

Projektlebenszyklus (1132)

Um was geht’s?

Das Konzept des Projektlebenszyklus hilft, den Start und das Ende eines Projekts zu definieren. Das gilt dann auch umgekehrt: Was innerhalb des Projektlebenszyklus ist, ist innerhalb des Projekts und damit in der Verantwortung des Projektleiters.



Kurze Erinnerungshilfe
  • Der Projektlebenszyklus definiert Projektstart und Projektende.
  • Was ist vor dem Projekt? Wann genau beginnt das Projekt?
  • Wie beenden wir das Projekt auch richtig?
  • Projektlebenszyklen bestehen üblicherweise aus Phasen.
  • Phasen enden üblicherweise mit Meilensteinen.
  • Achtung! Auch ein agiler Ansatz unterliegt der gleichen Logik.


Kurze Erinnerungshilfe
  • Sauberes Aufsetzen eines Projektstarts, „Reinschmieren“ ins Projekt vermeiden.
  • Phasengrenzen einhalten und Phasenübergänge (Quality Gates) sauber hinbekommen.
  • Entwicklungsprozesse und Projektmanagementprozesse auseinanderhalten.
  • Projektmanagementprozesse sind immer iterativer Natur – also immer wieder durchzuführen.
  • Projekt (erfolgreich) beenden, Zombieprojekte vermeiden.

Und in der Praxis?

Projektlebenszyklen helfen dabei, ähnliche Projekttypen schon vorab zu strukturieren und den Stakeholdern eine verlässliche Standortbestimmung zu ermöglichen. Da sich viele Projekttypen ähneln, kann ein Vorgehen einigermaßen standardisiert werden, ohne das Einmaligkeitsgebot des Projekts zu verletzen.


Reflexionsfragen
  • Gibt es bei Ihnen definierte Projektlebenszyklen?
    • Nur einen?
    • Oder für verschiedene typische Projektarten?
    • Wo sind die bei Ihnen dokumentiert?
    • Wissen alle Beteiligten darüber Bescheid?
  • Wenn nicht, würden Ihnen dokumentierte Projektlebenszyklen den Start ins Projekt erleichtern?

Copyright Gita GmbHAlle Rechte vorbehalten

Projektlebenszyklus (1132) Read More »

Nach oben scrollen