Schlagwort-Archive: Hebel

An den Schalthebeln des Projektmanagements

Lassen sich Turbulenzen in Migrations- und Intergrationsprojekten (MIP) über die im Eintrag Wann sind Projekte instabil? vom 3. August 2008 genannten Faktoren tatsächlich mindern? Natürlich nicht, denn der Projektmanager kann keinen der Faktoren beeinflusst. Es sind keine Hebel des Projektleiters, sondern reine Randbedingungen des Projekts. Sie beschreiben das Projektumfeld, das der Projektleiter hinzunehmen und in die Planung einzubeziehen hat. Achten Sie bei der Planung Ihrer Projekte auf solche Randbedingungen? Fiel Ihre Planung bisher tatsächlich anders aus, wenn im Projekt z.B. Personen aus drei verschiedenen Nationen mitarbeiteten, als wenn alle demselben Sprachraum zugehören, in welchem das Projekt durchgeführt wird?

Was sind Hebel?

Hebel sind Projektparameter, die Sie als Projektmanager aktiv beeinflussen können. Zwar nicht immer mit Erfolg, das gebe ich zu, aber Sie können in jedem Fall Einfluss nehmen. Der Faktor von Nittbaur und Ernst, auf den ich im Nachtrag noch aufmerksam machte, ist ein solcher Hebel. Es liegt im Ermessen des Projektleiters, ob er ein Kickoff machen will und wen er dazu einlädt. Selbstverständlich können Sie darüber diskutieren, ob viele Teilnehmer förderlich oder kontraproduktiv sind. Selbstverständlich könnten Sie auch von allen Eingeladenen Absagen erhalten, so dass das Kickoff in’s Wasser fällt. Aber Sie können etwas tun.

Welche Resultate soll das Projekt ergeben?

Schreiben Sie einmal auf, welche Resultate oder Zielsetzungen Sie in Ihrem Projekt erreichen müssen und wie der aktuelle Stand eines jeden Resultats ist. Klar, da sind einmal die drei Resultate des magischen Dreiecks, oft auch als magisches Viereck dargestellt, nämlich

  • Termintreue
  • Kostentreue
  • Optimale Qualität
  • Ablieferung und Installation der geforderten Inhalte

Zusätzliche Resultate können sein:

  • Kundenzufriedenheit
  • Vertrauensbildung beim Kunden in das Lieferunternehmen und seine Produkte
  • Befriedigung der Interessen aller Stakeholders

Welche Hebel haben Sie?

Und jetzt machen Sie eine Liste aller Hebel, die Ihnen zur Verfügung stehen, also all derjenigen Faktoren, die Sie als Projektmanager direkt beeinflussen und regeln können. Schreiben Sie auch dazu, welche Ist- und welche Soll-Einstellung die einzelnen Hebel gerade haben. Ich weiss, das ist gar nicht so einfach, wie man zunächst glaubt. Aber überlegen Sie, welche Mitigations Sie bei erkannten Risiken angeben. Dort finden Sie Ihre Hebel. Sie werden schnell einsehen, dass es in MIP gar nicht so viele Faktoren gibt, auf die Sie wesentlichen Einfluss nehmen können. Diese Tatsache lässt alle gut gemeinten Ratschläge für ein aktives Projektmanagement hinter sich. Die Liste kann für Entwicklungsprojekte lang sein, aber in MIP gibt es weniger Hebel. Beispiele für Hebel können sein:

  • Durchführungsentscheid Kickoffmeeting
  • Teilnehmerzahl Kickoffmeeting
  • Aktualität des Projektplans
  • Detailreichtum des Projektplans
  • Zeitpunkt für das Vorlegen eines Projektplans
  • Häufigkeit von Projektmeetings
  • Teilnehmer an den Meetings
  • Zeitpunkt und Inhalt von Eskalationen
  • Insistierungsgrad bezgl. Ressourcen (wer am lautesten bellt, erhält den grössten Knochen)
  • Beantwortungspolitik von Change Requests

etc. etc. (Schreiben Sie weitere in Kommentare zu diesem Eintrag!)
Was fällt Ihnen auf, wenn Sie die beiden Listen vergleichen? Kein Resultat erscheint auf der Liste der Hebel und kein Hebel ist ein Resultat. Schlimmer noch: Die Hebel sind nur indirekt und oft über mehrere Ecken mit den Resultaten verbunden1. Mit anderen Worten: Sie können die Ereignisse überhaupt nicht direkt beeinflussen. Wenn Sie 10 Projektmeetings machen, kann das die Kundenzufriedenheit vielleicht fördern, aber es könnte ihr auch abträglich sein.

Wie finden Sie Hebel?

Sie erinnern sich an das Grundmodell von Migrations- und Integrationsprojekten? Siehe Komplexität im Projektmanagement. Dort hatten wir den Feedbackloop

anatomie_mip

Tasks to do liegt in Form einer Issuelist vor. Sie beeinflusst direkt die Termintreue, während von Work in Progress ein direkter Pfeil zu den totalen Projektkosten führt. Welche Hebel Sie für das Wissen haben, zeigte ich in Investieren Sie in Expertenwissen. Jetzt wollen wir dasselbe Schema des Growth and Underinvestment Archetypus anwenden, um einen Hebel für die Issuelist zu finden. Ist das Projekt längst überfällig, mag der Kunde toleranter gegenüber kosmetischer Mängel sein. Er ist qualitätstoleranter, was sich derart auswirkt, dass er nicht mehr gleich für jeden Schönheitsfehler des Produkts oder des Services einen Issue auf die Liste setzt. Das heisst, je grösser die Qualitätstoleranz, desto kleiner die Issuelist.
Ist der Endtermin des Projekts längst überschritten, kann das der Projektmanager des Lieferanten eskalieren. Dies ist sein Hebel! Dadurch erreicht er vielleicht, dass das Management die Notwendigkeit wahrnimmt, mehr Ressourcen aufzubauen, so dass das Projekt schliesslich doch noch fertig gestellt werden kann. Das Gesetz von Brooks gilt bei MIP nicht zwingend (Brooks‘ Gesetz: „Adding manpower to a late software project makes it later“2). Unsere Feedbacks sehen nun so aus:

termintreue

Der Kreis R ist schlecht für die Termintreue. Sie würde zwar durch den Kreis B1 eingedämmt, aber leider erst, nachdem das Projekt bereits aus dem Ruder gelaufen ist. Mit dem Kreis B2 hingegen, könnte der Termin gehalten werden, wenn er von Anfang an greifen würde. Allerdings besteht eine beträchtliche Verzögerung zwischen der Allokation von Ressourcen und ihren effektiven Auswirkungen auf die terminlichen Belangen. Der einzige Hebel in diesem Zusammenhang ist die Eskalation. Das zeigt, dass der Projektmanager mit der Eskalation nicht zu lange warten sollte. Meistens zögern Projektmanager, zu eskalieren oder denken, dass sie den Dingen noch ein wenig zuschauen wollen. Das ist ein Fehler.

1Denis Sherwood. Den Wald vor lauter Bäumen sehen – Reduktion von Komplexität – Anleitung zum systemischen Denken im Management. Wiley VCH Verlag. Weinheim 2003.
(Leider spricht auch Sherwood von Komplexitätsreduktion. Aber ich glaube, das ist bloss eine Verkaufstrick. Er soll dem potentiellen Käufer, der nicht weiss, was Komplexität ist, ein beruhigendes Gefühl geben)
2Frederick P. Brooks. Vom Mythos des Mann-Monats : Essays über Software-Engineering. Mitp-Verlag. Bonn 2003

Wann sind Projekte instabil?

Aber was macht denn nun wirklich das aus, was wir gemeinhin, aber fälschlicherweise mit Projektkomplexität bezeichnen, also das Chaotische, das Fluktuative? Wie wir gesehen haben, beginnt das System aus dem Ruder zu laufen, wenn sich die Kontrollparameter ändern. Mit unseren Managementmassnahmen, halten wir das System „über Wasser“ bis es eine neue Mode ausgebildet hat und einigermassen stabil wird, also in ruhigere Gewässer treibt, um bei dem Bild zu bleiben. Die Frage ist somit: welches sind gängige Kontrollparameter in einem Projekt? Ich habe in den letzten Jahren eine Liste derjenigen Faktoren geführt, die mir in meinen Projekten jeweils zu schaffen gemacht haben, also Ursache für Mehraufwand waren. Folgende Faktoren habe ich bisher in zufälliger Reihenfolge identifiziert. Sicher gibt es noch mehr. Bitte schreiben Sie Ihre Erfahrungen in einem Kommentar zu diesem Eintrag.

1. Anzahl Subcontracors
Es ist allgemein bekannt, dass mit der Anzahl der Subcontractors die Stabilität des Projekts sinkt. Hierin sind sich sicher alle einig.

2. Geographische Distanz zu den Subcontractors
Auch in einer globalisierten Zeit spielt eben die geographische Distanz durchaus eine Rolle. Wenn sich irgend ein Inzident ereignet, dann ist der zuständige Subcontracter nicht zur Stelle. Ist er in einer anderen Zeitzone, kann man ihn vielleicht nicht einmal telefonisch erreichen. Kommt er aus einem anderen Kulturkreis, versteht er nicht immer alle Umstände, die ein Eingreifen regeln. Dadurch kann es zu einer Unruhe kommen, die das Projekt destabilisiert.

3. Ist der Auftraggeber ein Kunde oder eine interne, bzw. konzerneigene Stelle?
Das ist ein grosser Unterschied. Der Kunde bezahlt, so dass das Projekt zum Unternehmenserfolg beiträgt. Ein internes Projekt verursacht nur Kosten. Das Ziel eines internen Projekts kann z.B. sein, organisatorische Massnahmen einzuführen, die es erlauben, künftige Kundenprojekte effizienter abzuwickeln, was zu Einsparungen führen könnte. Mit anderen Worten: mit Kundenprojekten verdient man, mit internen Projekten spart man. Das hat auf das Laufzeitverhalten eines Projekts zumindest kognitive Auswirkungen.

4. Sind Verträge zwischen Kunden, Lieferant und Unterlieferanten vorhanden?
Es gibt verschiedene Szenarien, warum Verträge nicht oder nur lückenhaft vorhanden sind. Z.B. kann manchmal der Kunde gewisse Spezifikationen (für ein Folgeprojekt) erst zu einem späteren Zeitpunkt machen. Sie müssen aber ihre Subcontractors bereits jetzt binden. Deren Offerten laufen ab, bevor die Kundenspezifikationen vorhanden sind.
Hierhin gehört auch die Frage, ob der Kunde tatsächlich eine Bestellung gemacht hat und machen konnte, die dem entspricht, was im Vertrag/der Offerte steht1

5. Auf welchen Berechnungen basieren Offerten und Verträge?
Denken Sie z.B. an die Schwierigkeiten, die Menschen mit Verzögerungen haben. Projektpläne und Aufwandberechnungen berücksichtigen Verzögerungen meistens falsch. Das zeigt sich erst während des Projekts und kann dann zu heftigen Instabilitäten führen.

6. Welche organisatorische Distanz besteht zwischen dem jeweilige CEO und den Projektmanageren sowohl des Kunden als auch der Lieferanten?
Natürlich kann sich der CEO nicht um jedes Projektchen kümmern. Bei den Lieferanten sind Kundenprojekte aber Tagesgeschäft und müssten den CEO interessieren. Wenn der Projektmanager in fluktuativen Phasen eskalieren muss und der CEO keine Ahnung hat, worum es geht, verpufft die Eskalation und das Projekt dümpelt steuermannslos im seichten Wasser.

7. Anzahl Sprachen
Gemeint sind sehr wohl die gesprochenen Sprachen der Projektstakeholders. Wenn in einem Projekt die Leute über die ganze Welt verteilt sind und alle in einer anderen Sprache denken, dann ist es schon dann schwer, wenn sich alle auf Englisch unterhalten können. Auch wenn alle Beteiligten hervorragend Englisch sprechen, dann ist und bleibt es für die meisten eine Fremdsprache, und Missverständnisse sind an der Tagesordnung.

8. Anzahl Stakeholders und beteiligte Businesseinheiten
Stakeholders sind diejenigen Leute, die am Projekt interessiert sind und daher mitreden wollen oder zumindest mitdiskutieren. Neben den eigentlichen Projektmitarbeiter reden auch Linienmanager, Vertreter vom Verkauf und vom Marketing, Qualitätsverantwortliche im Konzern oder Kontroller mit. Alle Mensche haben eine andere Welt im Kopf, alle haben andere mentale Modelle. Je mehr Leute mitreden, desto kleiner ist das Gemeinsame all dieser Modelle. Es kann zu endlosen Diskussionen über Vorgehen und Planung kommen.

9. Lieferketten und Prozesslängen
Je länger die Zwischenstationen von Material, Produkte, Informationen, Wissen, etc. ist, desto instabiler der Projektlauf. Aber zählen Sie die Stationen nicht nur zwischen den Subcontractors, Lieferanten, Zulieferer und Kunde, sondern insbesondere innerhalb der jeweiligen Lieferkettenmitglieder. Gerade innerhalb eines Unternehmens sind die Prozesse häufig ziemlich verschlungen.

10. Hierarchiestufen im Unternehmen
Kommt es zu Uneinigkeiten, kann in einer flachen Hierarchie schneller ein Schiedsurteil gefunden werden. Das hat etwas mit der Prozesslänge innerhalb eines Unternehmens zu tun. Während Anfrage und Begründung für einen Entscheid über eine lange Hierarchieleiter hinauf und wieder hinunter müssen, kann im Projekt ein Sturm wüten und Schiffe unter gehen.

11. Anzahl technischer Experten vor Ort
Sie erinnern sich an den Eintrag Investieren Sie in Expertenwissen vom 26. Juli 2008. Muss der Projektmanager ständig um technische Spezialisten kämpfen, dann trägt das nicht gerade zur Beruhigung des Projekts bei. Wenn dieser Umstand dann noch zum Kunden durch dringt und auch er findet, man nehme ihn zu wenig ernst, dann kann das Projekt wieder in sehr turbulente Zeiten geraten.

12. Routinegrad und Komplexität des Projektgegenstandes
Natürlich sind das Streichen einer Küchendiele und die Migration eines Bankensystems auch als Projekte nicht vergleichbar. Ein guter Maler sollte genügend Routine im Streichen von Küchendielen haben. Zudem ist die Komplexität, die in einer frisch gestrichenen Küchendiele stecken kann überschaubar. Ich kann mir nicht vorstellen, dass es viele Moden gibt, die das System Küchendiele-Farbe-Maler-Benutzer einnehmen kann. Die Frage ist auch, wieviel Wissen in den Produkten/Dienstleistungen steckt.

13. Vertrauensgrad des Auftraggebers/Nutzniesers in den Projektführer
Manchmal hat ein Unternehmen supergute Produkte, aber Gerüchten nach funktionieren sie einfach nicht beim Kunden. Wenn auf solche Produkte migriert werden soll, ist der fluktuative Charakter des Projekts schon vorgezeichnet. Der Kunde erwartet gleichsam, dass das Projekt schief laufen wird, was eine self-fullfilling prophecy ist..

14. Politische Distanz zwischen beteiligten Organisationseinheiten in derselben Unternehmung
Grabenkämpfe innerhalb des Kunden- oder des Lieferantenunternehmens können Projekte enorm destabilisieren. Manchmal kommt das Projekt überhaupt nicht mehr weiter, bis organisatorische oder finanzielle Fragen innerhalb des Konzerns entscheiden sind. Wenn sich dann das Management nicht für das Projekt interessiert und keine Schiedsrichterrolle übernehmen will, dann kann das Projekt aus allen Rudern laufen.

15. Anzahl Schnittstellen zu oder von anderen Projekten
Wieviele andere Projekte, Organisationseinheiten , etc. hängen vom Projekt ab? In welchem Mass hängt das Projekt selber von wie vielen anderen Projekten und Organisationseinheiten ab? Wie sind die Endbenutzer verteilt?

Den meisten dieser Parametern können Sie eine Zahl zuordnen, Sie können sie also leicht messen. Daraus liesse sich ein Stabilitätsfaktor (oder – nicht ganz richtig – Komplexitätslevel) für ein Projekt errechnen. Wer ein Projekt beruhigen will (oder – fälschlicherweise ausgedrückt – wer die Komplexität reduzieren möchte, s. Ammenmärchen) weiss nun, an welchen Rädchen er drehen kann. Diese Parameter sind sozusagen die Hebel des Projektmanagers. Sind es wirklich alles Hebel? Wir kommen später noch auf Hebel zurück.

1Adrian W. Fröhlich. Mythos Projekt – Projekte gehören abgeschafft. Ein Plädoyer. Galileo Press. Bonn 2002. Über das Buch werden wir uns hier wohl noch unterhalten müssen.

Nachtrag vom 4. August 2008: In diesem Zusammenhang ist der Artikel von Gunter Nittbauer und Andreas Ernst, Team Synthegrity: Lösungen finden bei komplexen Fragen, interessant. Nicht so sehr wegen Stafford Beers Open Space ähnlichem Synthegrity-Ansatz, sondern weil Nittbaur/Ernst glauben, einen weiteren Kontrollparameter gefunden zu haben. Sie behaupten, dass an ein Projektkickoff um die 30 Teilnehmer gehören, einfach um die Komplexität in den Griff zu bekommen und den Benutzer genügend eingebunden zu haben. Ich habe einmal in einem Projekt in der Tat Meetings mit ca. 30 Telnehmer gemacht, um von allen ein Commitment zu haben. Resultat: paar Tage nach den Meetings wurden überall in den Kaffeeecken bilaterale Absprachen gemacht, die den Meetingbeschlüssen entgegen liefen.