www.pm-camp.org

Management hat von der begrifflichen Bedeutung viel mit Verwaltung und Steuerung nach Parametern zu tun. Die Überhöhung des Manager-Begriffs im deutschen Sprachraum hat keine deckungsgleiche Entsprechung in der Herkunftssprache. Im englischen Sprachraum gibt es auch den Facility Manager den man in Deutschland vielleicht Hausmeister nennen würde. Sicher ist die Übersetzung etwas überzogen, dennoch zeigt sie auf, dass der Begriff Management ursprünglich anders verwendet wurde. Siehe Projekte leiden, leiten oder managen

Eine weitere “Unsinnigkeit” des Management-Begriffs ist mir kürzlich wieder aufgefallen als ich im Epic.graphic Blog ein Bild sah, das eindrucksvoll den Unterschied zwischen Daten, Information und Knowledge aufzeigt.

Die Daten entsprechen den reinen Zutaten, Information und Präsentation dem zubereiteten Kuchen. Knowledge hingegen ist der gegessene Kuchen. Knowledge ist in gewisser Weise die erprobte Information oder Erfahrung. Für mich ist dieses Bild eine sehr treffende Metapher. Es stellt sich im Anschluss aber die Frage: “Was kann dann Knowledge-Management sein? Verwaltung von Erfahrung, Verwaltung von Aha-Effekten, die sich beim Lernen eingestellt hatten. Verwaltung der Sinneserfahrung beim Essen eines Kuchens?

Knowledge – das heißt das Essen des Kuchens – lässt sich nicht verwalten. Nur die Zutaten und die Rezepte lassen sich verwalten. Im Laufe der Jahre komme ich immer mehr zu der Überzeugung, dass es sich mit dem Managen von Projekten ähnlich verhält. Materielle Ressourcen, Planzahlen, Aufwandschätzungen lassen sich problemlos verwalten. Dass die Verwaltung dieser Aspekte wichtig ist stelle ich nicht in Abrede. Zum Erfolg eines Projektes gehört aber immer noch etwas mehr. Selbst wenn alles perfekt bereitgestellt wird, alle Zeitpläne sich als realistisch heraus gestellt haben, niemand aus dem Projektteam abgezogen wurde oder überlastet ist bleibt immer noch die “Kleinigkeit” eine fruchtbare Zusammenarbeit zu ermöglichen. Dann kommen die Begriffe Führung, Inspiration, Motivation, Leadership usw. ins Spiel. Ich fasse das alles unter dem simplen Begriff Leitung zusammen. Leiten bedeutet: Begleiten, einen Weg weisen, bei Bedarf an die Hand nehmen oder eben wenn alles läuft nur noch leise mitgehen und aufpassen. Zur Leitung gehört definitiv eine gute Vorbereitung und auch eine Portion Management. In der Sprache der Mathematik würde ich demnach Management als notwendig aber nicht hinreichend bezeichnen. Es ist bei diesem Verständnis der Begriffe auch nicht zwingend notwendig, dass der Manager das höchste Gehalt bezieht – spätestens hier schmerzt die Provokation. Ich wünsche mir, dass Management etwas kleiner wahrgenommen wird. Der Projekt-Manager im Projekt erfüllt nur einen Teil der Aufgaben im Projekt. Es gibt Projekte in denen Management sehr wichtig ist – es gibt aber auch Projekte in denen Management nur eine marginale Bedeutung hat. Die Überbewertung des Managements führt gelegentlich auch zu unpassendem Methodeneinsatz. Manche Projekte werden unter einem Berg von Management-Methoden regelrecht begraben.

Ich wünsche mir mehr Leitung und mehr Fingerspitzengefühl beim Einsatz von Management (=Verwaltung). Lasst uns Schrauben mit Schraubendrehern und Nägel mit Hämmern bearbeiten. Manchmal – so scheint es mir – werden in Projekten Nägel mit den Griffen von Bohrmaschinen eingeklopft.

Wer sich für Database Publishing interessiert und einen interessanten Vortrag über die menschliche Seite des Projektleitungs-Geschäftes hören will, sollte den priint:day 2011 besuchen. Der Titel des Vortrages, den ich zusammen mit einem Kollegen in ungewohnter Weise halten werde, lautet:

Der Faktor Mensch in Projekten – Chance statt Risiko

Es menschelt mal wieder. Mit dieser Formulierung wird im Projektalltag meistens auf Schwierigkeiten hingewiesen. Missverständnisse, Eitelkeiten, Konflikte, Rollenkonflikte und Streitigkeiten können Projekte erschweren und allzu oft wird versucht mit ausgefeilten Projektmanagement-Methoden diese Schwierigkeiten zu beseitigen. Es gibt noch einen anderen Weg: Das “menscheln” nicht zu unterdrücken sondern konstruktiv zu nutzen um den Faktor Mensch zum Erfolgsfaktor werden zu lassen.

Stell Dir vor Du willst etwas ganz großes machen, z.B. eine neue Hütte auf dem Aktivspielplatz bauen. Das ist so viel zu tun, dass du es alleine nicht schaffst. Einer von Euch wird dann ein bisschen organisieren z.B. bei den Betreuern um Erlaubnis und nach neuem Holz fragen. Wenn Ihr dann begonnen habt zu bauen wird der eine weiter darauf achten, dass Ihr gut arbeiten könnt. Er wird neue Nägel besorgen, wenn sie knapp werden oder vielleicht auch etwas zum Trinken holen wenn es zu warm ist. Vielleicht passt er auch auf, dass nichts schief geht und sich niemand verletzt. Wenn es Streit gibt versucht er zu schlichten und bekommt manchmal als erstes den Stress mit Betreuern ab, wenn es Ärger gibt. Dieser Eine ist der Projektleiter.

Kann das auch ein Mädchen machen? Ja, Mädchen können das auch machen, ich glaube sogar, dass Mädchen das ein bisschen besser können.

Warum ich der Meinung bin, dass das Mädchen vielleicht ein wenig besser können, werde ich demnächst besprechen

Die Kernfragen der Blogparade beziehen sich zwar auf den Einsatz von Web 2.0 in Unternehmen. Da moderne Unternehmen ohne Projektarbeit oder gar Projektorganisation nicht auskommen, lohnt sich vielleicht doch der Blick auf den Einzelaspekt Web 2.0 Werkzeuge in Projekten. Angesichts des Hype um Web 2.0 Werkzeuge sollte man annehmen, dass sie im Projektgeschäft weit verbreitet sind. Manchmal drängt sich mir jedoch der kritische Gedanke auf, dass diejenigen, die Web 2.0 einsetzen auch darüber reden und den verbalen Hype verstärken wohingegen viele das Thema ignorieren und weiter arbeiten wie bisher.

Dieser gefühlte Zweifel am Verbreitungsgrad von Web 2.0 scheint sich beim Blick auf konkrete Projekte zu bestätigen. Nebenstehende Grafik zeigt wie oft Web 2.0 Werkzeuge in Projekten als Werkzeug eingesetzt werden. Die Projekte wurden im Jahr 2009 durchgeführt, die Anteile könnten ggf. dieses Jahr etwas höher sein, eine gewisse Ernüchterung macht sich aber dennoch breit. Konkret benennbare Social Media Dienste oder Miccroblogging liegen bei 2%, Selbst der 2.0 Klassiker Blog liegt nur bei 6%, “Wiki” das Urgestein des Web 1+X liegt immerhin schon bei 23%. Diese Zahlen überraschen auch deshalb, weil der Fragebogen mit dem sie erhoben wurden ausschließlich auf Web 2.0 Kanälen kommuniziert wurde, die Teilnehmer an der Umfrage also Web 2.0 Nutzer sind. Eine tiefergehende Untersuchung zu diesem Thema, die Ende des Jahres veröffentlicht wird, bestätigt dieses Ergebnis jedoch¹.

Ich halte also den etwas provokativ formulierten Satz als Zwischenergebnis fest. “Über Web 2.0 Werkzeuge wird zwar viel geredet, sie werden aber (bis jetzt) nur sparsam eingesetzt”. Diese Sparsamkeit wird noch deutlicher, wenn man die Zahlen zum Einsatz von E-Mail (> 90%) und face-to-face Kommunikationswerkzeugen zusätzlich betrachtet. Selbst Chat Systeme, die wahrlich keinen guten Ruf in den IT-Abteilungen der Unternehmen haben werden sehr viel häufiger eingesetzt als Web 2.0 Werkzeuge. Woran liegt es? Ich stelle eine provokative These auf:

Die Zeit ist noch nicht reif!

Web 2.0 bedeutet im wesentlichen Interaktion. Kontextbezogene Netzwerke sollen idealerweise hierarchisch gegliederte Informationslandschaften ersetzten. Eine Interaktion im Facebook-Style durch Drücken eines “Gefällt mir” Links hilft hier nicht weiter. Eine Wiedergabe und Bearbeitung vorhandender Information hilft ebenfalls nicht weiter. In Projekten und im Unternehmen 2.0 kommt es darauf an, dass alle ihr Wissen preis geben. Diese Möglichkeiten bieten die modernen Werkzeuge im Überfluss. Wollen die Menschen aber ihr Wissen wirklich preis geben, wollen sie das Risiko eingehen Wissen “aufzugeben”. Dem steht zu oft die Erfahrung entgegen, dass Wissen und Information als Macht- und Steuerungsinstrument gebraucht und missbraucht werden.

Der zögerliche Einsatz von Web 2.0 Werkzeugen spiegelt meines Erachtens den zögerlichen Umbau von hierarchischen, Konkurrenz-orientierten Strukturen zu kooperativen Strukturen wieder. Ein Unternehmen, das in hierarchischen Kontrollstrukturen verhaftet ist, wird durch Web 2.0 nicht automatisch zu einem 2.0 Unternehmen.

1. Stefan Panek, Einsatz von Web 2.0 Werkzeugen in der Projektkommunikation, persönliche Mitteilung, September 2009

• Umsetzung der erhobenen Anforderungen¹
• Einhaltung des Zeitrahmens
• Einhaltung des Budgetrahmen
• Zufriedenheit von Stakeholder / Kunden
• persönliche Einschätzung der Beteiligten

Ein Projekt wird als erfolgreich definiert wenn alle der folgenden Kriterien erfüllt sind:

• 80 bis 100 % der Anforderungen sind umgesetzt
• Zeit und Budget bis maximal 20% überzogen
• Stakeholder sind zufrieden oder sehr zufrieden
• Projektbeteiligte werten das Projekt als erfolgreich

Und das Ergebnis? Knapp 32% der Projekte sind erfolgreich (Stichprobengröße 106 Projekte). Keine Überraschung, alles bleibt beim Alten. Interessanter wird ein Blick auf den Einsatz von PM Standards. Folgende Antwortmöglichkeiten waren für PM-Standards vorgegeben.

• PMBOK
• ICB
• Prince2
• eigene
• keine

PMBOP und ICB liegen mit 12,4% und 10,3% in etwa gleich auf. Eigene firmenspezifische Standards, die ggf. von den vorher genannten abgeleitet sind, werden in 24,6% der Projekte eingesetzt. Etwas Ernüchterung macht sich breit, wenn man die 48,6% der Projekte bedenkt, die ohne standardisiertes PM abgewickelt werden. Eine differenziertere Sicht ergibt sich wenn man die Zahlen selektiv für die erfolgreichen Projekte ermittelt (grüne Säulen in der Grafik). Hier zeigt sich eine starke Verschiebung zwischen den “eigenen Standards” und dem Einsatz “nicht standardisierter” Vorgehensweisen. Der Einsatz einer standardisierten Vorgehensweise scheint sich also zu lohnen.

Es bleiben natürlich noch Fragen? Wie viele der “eigenen Standards” leiten sich von PMBOK oder ICB ab und wie korrelieren diese mit den erfolgreichen Projekten. Entsprechende Auswertungen sind derzeit noch mit zu großer Unsicherheit behaftet, hier muss noch etwas Geduld aufgebracht werden, bis die Stichprobengröße weiter gewachsen ist. Insofern freue ich mich über jede(n), der mitmacht oder den Link zur Umfrage noch weiter gibt.

1. Die Umsetzung der Anforderungen ist unabhängig wann und wie die Anforderungen erhoben wurden. In Zusätzlichen Fragen werden Zeitpunkt und Methoden erfragt.

“Sie kümmern sich jetzt um Projekt X”. Mit diesen Worten beginnen viele Leidensgeschichten. Die erste Diagnosefrage, die sich die/der Projektleiter(in) (PL) in spe stellen sollte lautet: “Ist X wirklich ein Projekt?” bzw. konkreter erfüllt “X” die folgenden Kriterien: Es gibt mindestens

• ein in Worten beschreibbares Ziel oder Arbeitsergebnis,
  das in dieser Form noch nicht existiert,
• eine klare Begründung warum das Projekt gemacht wird,
• einen Termin an dem mit den Arbeiten begonnen wird,
• einen Termin an dem das Arbeitsergebnis vorliegen soll,
• mindestens eine weitere Personen, die zum Arbeitsergebnis beiträgt,
• sowie mindestens eine weitere Person, an die das Arbeitsergebnis geliefert wird.

Wenn sich diese Punkte nicht klar beantworten lassen hat der / die Projektleiter In (PL) schon halb verloren. Dann bahnt sich vielleicht kein Projekt sondern eine Aufgaben-Zeit-Verschiebungsaktion oder eine halbherzige Umorganisation an. Lassen sich die grundlegenden Rollen (z.B. Empfänger des Ergebnisses) wirklich identifizieren und konkrete Ergebnisse formulieren? Bei neuen Aufgabenbereichen, die auf bestehende drauf gepackt werden, ist das oft nicht möglich auch wenn sie gerne Projekte genannt werden, das ist aber ein anderes Thema.

Gehen wir besser davon aus, dass das Ergebnis formuliert und verstanden ist. Dann steht die nächste Frage im Raum: “Wer macht mit?” Zur Erinnerung: Ein-Personen-Veranstaltungen sollten nicht Projekte genannt und mit Management überfrachtet werden. Im positiven Falle sind Mitarbeiter benannt, denen verfügbare Arbeitszeit eingeräumt wird im Projekt zu arbeiten und die zumindest in Ansätzen die notwendigen Qualifikationen mitbringen. Als ersten Schritt gilt es die Mitarbeiter(Innen) zu versammeln und sie über das Projekt ins Bild zu setzen. Als zweiten Schritt sollten sich alle Beteiligten zu einer Auftaktveranstaltung versammeln. In gutem Neudeutsch wird dies oft “Kickoff” genannt. Dieser Begriff aus dem “American Football” trifft es allerdings nicht ganz, er führt sogar ein wenig in die Irre. Bei der Auftaktveranstaltung müssen alle Beteiligten dabei sein. Dazu gehören Leitung, Auftraggeber, Team usw. Die entsprechende sportliche Metapher wäre das Treffen vor dem Spiel, bei dem der Vereinspräsident (Fußball Bundesliga) oder der Clubbesitzer (Basketball NBA) noch mal kurz vorbeischauen. Wenn der Ball zum ersten Mal gespielt wird ist das Team auf sich gestellt, der Auftraggeber sitzt dann schon auf der Tribüne. Ob der Projektleiter wie ein Trainer am Spielfeldrand oder als Spielertrainer bzw. Mannschaftskapitän agiert hängt dabei eher von Projektgröße und persönlichem Leitungsverständnis ab. Leider wird in vielen Projekten schon auf einen solchen Auftakt verzichtet. Für den/die PL der Auftakt eine erste Nagelprobe. Wenn jetzt schon Vorbehalte bzgl. der Verfügbarkeit von Mitarbeitern kommen, wie soll es dann werden wenn im Projekt wirklich gearbeitet werden soll.

Gehen wir weiter davon aus, dass der Auftakt stattgefunden hat. Damit sollten die folgenden Checklistenpunkte guten Gewissens mit “Ja” beantwortet werden können – falls nein “Gehe zurück zum Start”:

• Ist klar, warum was an wen geliefert werden soll und ist es allen bekannt?
• Sind die Projektziele (Anforderungen) zweifelsfrei definiert, klar und allen bekannt?
• Sind Termine definiert und allen bekannt?

Das Projekt beginnt und alles geht seinen Gang. Die Anforderungen werden in Arbeitspaketen in Aufgaben umgesetzt (wie auch immer) und abgearbeitet. Jetzt gibt es nur noch das eine oder andere Risiko das im Weg steht. Hier hilft eine einfache Liste, die wöchentlich bearbeitet und ggf. aktualisiert wird. Risiken haben noch mehr als Projektziele die Eigenschaft sich laufend zu verändern. Für die Aktualisierung der Liste helfen die folgenden Punkte:

• Sind die (aktuell am) größten Risiken bekannt?
• Hat jeder im Team das aus seiner Sicht größte Risiko benannt?
• Welche Risiken sind in der letzten Woche hinzugekommen?
• Welche Risiken wurden bisher entschärft?

Wenn alle diese Punkte mit gutem Gewissen beantwortet und abgehakt werden können ist das Projekt auf einem guten Weg. Aufgabe des / der PL ist es dafür zu sorgen, dass alle (!) Häkchen erhalten bleiben auch wenn sich im Laufe des Projektes die Rahmenbedingungen, Anforderungen oder was auch immer ändern. Wenn ein Projekt in Schieflage gerät ist meistens eines der Häkchen klammheimlich verschwunden. Der kritische Blick welches der Häkchen genau verschwunden ist hilft bei der Einleitung wirkungsvoller Maßnahmen.

Nochmal zurück zum Sport. Von der Tribüne lässt sich das Spiel gut verfolgen. Im Projektgeschäft läuft das ein wenig anders, hier ist der/die PL gefragt. Der Blick von der Tribüne wird durch das Berichtswesen im Projekt ersetzt. Ein pragmatisches Berichtswesen habe ich hier schon beschrieben – Das Schweizer Taschenmesser des Projektberichtwesens – (zugegeben das sind nochmal ein paar Worte zusätzlich). Die Projektberichte müssen immer auch die Risiken enthalten. Wenn Risiken verschwiegen werden (egal in welche Richtung) ist die destruktive Saat des schon Misstrauens gelegt.

Das ist eigentlich schon alles. Damit gelingt sicher nicht jedes Projekt automatisch und es gibt noch manche Details zu beachten wenn diese Punkte nicht erfüllt sind kann man sich alles andere sparen. Und “Hand auf Herz” in manchen Projekten, in denen gigantischer Management-Aufwand verbraten wird, lassen sich diese einfachen Punkte nicht einmal beantworten. Kann z.B. irgendjemand im Milliarden Projekt “Gesundheitskarte”, mit wenigen Worten das Ziel beschreiben. Das ist letztendlich genauso fatal wie das Miniprojekt einer kleinen Firma “Ich will eine neue Software, weiß aber nicht wozu”.

EPILOG: Ich habe bis jetzt kein Wort über konkrete PM Vorgehensweisen, Frameworks, Methoden, Vorgehensmodelle oder sonst etwas geschrieben. Es ist auch unerheblich ob es in dem gewählten Ansatz den Begriff des PL überhaupt gibt. Das hat einen guten Grund: “Es ist aus meiner Sicht weitgehend egal”. Nahezu jeder Ansatz, der verantwortungsbewusst eingesetzt wird, liefert positive Antworten auf obige Fragen. Es ist egal ob ein Scrum-Master die im “daily scrum” aufgetauchten “impediments” beseitigt oder ein klassisches Risikomanagement im Rahmen eines PMP gemacht wird. Das Ergebnis ist dasselbe. Ein Scrum-Master, der die “impediments” nicht beseitigt ist gleich schädlich wie ein Placebo-Risikomanagement, das die Rückmeldungen der Mitarbeiter nicht aufnimmt. Was letztendlich zählt und zum Erfolg führt ist das Vertrauen in die Menschen. Alle Methoden sind nur Hilfsmittel, die den Menschen helfen sollen.

Dieser Text ist unter Creative Commons BY NC ND (Namensnennung – Nicht Kommerziell – Keine Bearbeitung) lizenziert. Er ist Teil des Buchprojekts “Menschen im Projekt”. Er gehört zum Abschnitt 3, siehe Mindmap zu Inhalt und Struktur.