Wenn eine Aufgabe als Projekt endet

Es gibt Aufgaben, die klingen anfangs einfach und überschaubar, doch kaum hat man sie begonnen, zeigt sich, wie komplex sie sind. Der Rollout einer neuen Software, die Einführung neuer Tools oder die Neugestaltung der Firmenwebseite sind solche Aufgaben. Weil sie häufig zusätzlich zum Tagesgeschäft bewältigt werden müssen, stoßen Verantwortliche schnell an ihre Grenzen. Denn Projekte wie diese müssen sorgfältig geplant, souverän gesteuert und laufend überwacht werden. Das kann ein Vollzeitjob sein.

Wann wird aus einer Aufgabe ein Projekt?

Peter Kaiser ist Geschäftsführer eines mittelständischen Unternehmens im Anlagenbau mit rund 250 Mitarbeitern. Herr Kaiser hatte erkannt, dass die Unternehmenswebseite völlig veraltet war. Die Inhalte waren nicht mehr korrekt, das Design war aus der Mode gekommen und die Funktionalität musste verbessert werden, um Interessenten leichter zu Kunden zu machen. Also beauftragte Herr Kaiser eine Agentur zur Überarbeitung der Webseite.

Recht zügig legte diese einen übersichtlichen und gut strukturierten Meilensteinplan vor. Ziel: die neue Webseite ist in 2,5 Monaten online. Herr Kaiser war erfreut, dass das so schnell gehen sollte. Er gab den Meilensteinplan frei und die Agentur begann mit der Umsetzung.

Die erste Hürde

Alles verlief reibungslos, bis die Agentur den ersten Entwurf des Layouts zur Freigabe schickte. Herr Kaiser war zu diesem Zeitpunkt mit seinem Vertriebsleiter auf Geschäftsreise in China und hatte keinen Freiraum, eine fundierte Entscheidung zu treffen. Folgerichtig delegierte er das Thema an seine Assistentin, Tanja Walter. Sie war, nach ihm und dem Vertriebsleiter, am ehesten vertraut mit dem Projekt. „Bitte treiben Sie das Projekt weiter voran und führen Sie eine Entscheidung herbei“, lautete sein Auftrag.

Bei der Besprechung nach Herrn Kaisers Rückkehr eröffnete ihm seine Assistentin: „Wir haben uns leider auf kein Design einigen können. Jeder Beteiligte hat andere Vorstellungen, wie die Seite aussehen soll. Die Diskussion war uferlos! Was machen wir jetzt?“ „Keine Sorge, Frau Walter, wir finden bestimmt eine Lösung“, beruhigte sie der Geschäftsführer. „Welche Punkte sind denn konkret offen?“ „Nun, wir müssen entscheiden, welche Inhalte auf die Seite sollen und wer die Produktbeschreibungen und die Unternehmensdarstellung textet. Vertrieb und Marketing waren sich hier überhaupt nicht einig. Außerdem hatten die Kollegen vom Außendienst noch einige gute Ideen für den Webshop, die allerdings Auswirkungen auf das Design haben. Und an die Karriereseite hatten wir nicht gedacht, bis uns die Personalleiterin darauf hinwies. Die Agentur verlangt von uns eine schnelle Entscheidung, sonst kann sie die Termine nicht einhalten“, schloss Tanja Walter, sichtlich außer Atem.

Läuft das Projekt aus dem Ruder?

Herrn Kaiser war der Kern der vielen Fragen von Frau Walter klar: „Wer koordiniert intern das Projekt?“ Er ging im Kopf die Möglichkeiten durch: Der Vertriebsleiter wäre die beste Wahl, aber er und sein Team sind aktuell mit der Vorbereitung der wichtigsten Branchenmesse völlig ausgelastet, für die auch die Webseite rechtzeitig fertig sein muss. Seine Assistentin wiederum brauchte er dringend für die Nacharbeitung der Chinareise. „Wir brauchen jemanden, der Zeit und Geduld hat, Ergebnisse und Entscheidungen einzufordern und mit der Agentur zu kommunizieren“, sprach er seine Gedanken laut aus. „Die Person muss neutral genug sein, um widersprüchliche Anforderungen zu Kompromissen zu machen.“ „Genau!“ warf Frau Walter ein. „Am besten wäre ein Projektleiter, der die Sprache der Agentur versteht und die Webseite ausführlich für uns testen kann, bevor sie online geht.“

Das EBH - Team ist der Ansprechpartner für Ihre Aufgaben, die als Projekt enden. Egal, ob es um Ihre neue Webseite, den Rollout eines neuen EDV-Systems oder die Einführung neuer Tools geht: Wir helfen Ihnen, Ihr Projekt zu führen. Wir reden mit allen Beteiligten im Unternehmen, stimmen uns mit Ihren Lieferanten in Ihrem Sinne ab und sorgen dafür, dass Meilensteine erreicht und Entscheidungen getroffen werden.

Was ist das richtige Projektteam?

Folgende Frage diskutierte ich vor einiger Zeit mit einem Projektleiter:

"Ich habe ein neues Projekt bekommen. Das Thema ist technisch sehr interessant, es ist neu, das Unternehmen betritt hier Neuland, obwohl wir ähnliche Dinge schon mal entwickelt haben. Ich würde das Projekt gerne übernehmen, weil mich die Herausforderung reizt.
Doch weil die Technik neu ist, bin ich auf ein gutes Team ganz besonders angewiesen.

Woher weiß ich, dass ich die richtige Mannschaft habe?"

Das war die Kernfrage vor dem Start des Projektes. Nicht, ob das Thema technisch lösbar ist, oder das Budget richtig berechnet. Die meisten Dinge sind technisch lösbar und lassen sich berechnen.
Nicht, ob er die Unterstützung seines Auftraggebers bekommt. Die meisten Auftraggeber unterstützen ihr Projekt, wenn sie merken, dass es gut läuft.

Damit das Projekt gut läuft, braucht der Projektleiter ein Team, in dem die notwendige Kompetenz (technischer undvor allem kommunikativer Art) ausreichend vorhanden sind.

Wir haben uns dann gemeinsam überlegt, welche Fähigkeiten, Kenntnisse und Ressourcen im Team vorhanden sein müssen, damit das Projekt die Grundvoraussetzung für Erfolg bekommt.
Bei unseren Überlegungen waren technisches Wissen und Kommunikationskompetenz und soziale Fähigkeiten gleichermaßen wichtig.
(Warum? nun - die Frage ist mehrere eigene Projektgeschichten wert.)

Mit dieser Erkenntnis, welche Fähigkeiten erforderlich seien, haben wir ein Diagramm erstellt und uns die Verteilung im Team angesehen. Auf einer Skala (y-Achse) von 0 (fehlt) bis 5 (perfekt) wurden die notwendigen Fähigkeiten (x-Achse) aufgelistet und die einzelnen Team-Mitglieder eingetragen.
Dabei wurde sichtbar, an welcher Stelle Kompetenz fehlt oder schwach ausgeprägt war.

Im nächsten Schritt hat der Projektleiter das Diagramm mit dem Team bearbeitet. Die Selbsteinschätzung jedes einzelnen wurde miteinbezogen und in der anschließenden Diskussion hat sich ein Team entwickelt, das seine Stärken genau kannte und wusste, wie es am besten zusammenarbeitet.

Und Achtung: die wahre Stärke von Projekt-Teams liegt in den Unterschieden und der Fähigkeit, sich zu ergänzen, nicht in den Gemeinsamkeiten.

Projektkostenfalle: vom Umgang mit Wissen im Projekt

Was kostet fehlendes Wissen?

Das kommt darauf an ...  hier ist ein gar nicht so seltenes Beispiel dazu:

Da ist Peter in seinem Projekt volle 5 Tage mit der Recherche von Informationen beschäftigt. Die beiden Kollegen Hans und Dieter im „Nachbarprojekt“ haben schon 4 Wochen zuvor nach den fast gleichen Informationen gesucht. Das wusste Peter nicht und machte die fast identische Arbeit noch einmal. Wertvolle 5 Tage Zeit, die er für sein Projekt auch anders hätte nutzen können. Auf diese Weise wird in Projekten ein oft 5-stelliger Betrag des Projektbudgets nur für die Suche nach notwendigen Informationen und Wissen ausgegeben, ohne dass diese Aufwände wirklich zu steuern wären.

Die Kosten für Projekte verstecken sich oft in Aufwänden, die die Suche nach Informationen erfordert. Dazu gehören auch Meetings, zu denen eingeladen wird, weil Informationen fehlen. "Oh, das Konzept steht doch auf dem Laufwerk", ist dann die Bemerkung des Kollegen in der Besprechung, der sich wundert, warum die anderen im Team die Details nicht kennen.

Wissen ist in Unternehmen ausreichend vorhanden, doch es zum richtigen Zeitpunkt zu finden, ist oft zeitraubend und teuer. Laut einer Studie des Gallup-Institutes sind 42% des Wissens eines Unternehmens nur in den Köpfen der Mitarbeiter – und oft ist es völlig ungeklärt, wie ein Projekt an dieses Wissen gelangen soll, wenn es benötigt wird. 

Schnelle Abhilfe nur über Tools oder eine weitere Methode ist oft sehr aufwändig und nicht wirklich effizient. Wichtiger ist der Willen, Informationen und Wissen im Projekt teilen zu wollen. Und ein paar Grundregeln gibt es trotzdem:

1) ein paar wenige Regeln zur Dokumentation einführen und diese konsequent einhalten auch wenn es langweilig ist.
2) ein Tool festlegen, in dem alles wichtige dokumentiert wird, sei es nun Jira, Sharepoint oder etwas anderes. 
3) Derjenige der das Wissen hat, hat auch die Verpflichtung, es mit den anderem im Team zu teilen. Das vermeidet so wunderbar effiziente Dialoge wie "Warum hast Du denn nichts gesagt?" - "Du hast ja nicht gefragt." ....

Frag doch mal ....

Vor einiger Zeit habe ich mit einem Projektteam, das ich eine zeitlang begleitet habe, einen Planungs-Workshop durchgeführt. Nach kurzer Zeit stellte sich diese merkwürdige Gefühl ein, wenn scheinbar alles stimmt, Dinge aber trotzdem nicht stimmig erscheinen.
Sichtbar wurde es daran, dass alle 7 Beteiligten des Projektteams ganz unterschiedlich über das Projekt sprachen. Ohne "Insiderwissen" über die Projektorganisation hätte man die Leute nicht dem gleichen Projekt zugeordnet. Entsprechend schwierig war die Zusammenarbeit im Team. Regelmäßig gab es ausufernde Diskussionen über die Umsetzung von Meilensteinen, Akzeptieren von Entscheidungen oder Zurodnung von Aufgaben.

Um der Sache auf den Grund zu gehen, bekam in der nächsten Projektsitzung jeder im Team ein leeres Blatt Papier mit der Aufgabe, das Projektziel aus dem Gedächtnis aufzuschreiben. Ich erhielt 5 verschiedene Projektziele. 3 von 7 nannten das gleiche Ziel.

Bei der Analyse dieses Ergebnisses kamen die Team-Mitglieder zu dem Schluss, dass sie nicht genug Fragen gestellt hatten.
Fragen über das Projektziel, über den Nutzen, den Scope und die Risiken des Projektes.
Die Erkenntnis löste heftige Diskussionen aus. Der Projektleiter erstellte spontan eine Liste von Leuten, mit denen er zur Vorbereitung des Projektes gesprochen hatte. Die Liste war beeindruckend lang. Das brachte die Diskussion zunächst zum Verstummen.

Die nächste Überlegung war: Waren denn in Bezug auf das Projektziel überhaupt die richtigen Fragen gestellt worden?
Wieder nachdenkliche Stille. Wie kommt man an die richtigen Fragen?

Die Erkenntnis des Workshops war, dass man eine Planung erst erstellen kann (schließlich war das die ursprüngliche Absicht des Workshops gewesen), wenn man über das Projektziel und sein Umfeld genügend Fragen gestellt hat.
Das Team hat den Zweck des Workshops anschließend geändert. Es wurde eine "kreative Arbeitssitzung zum Fragenfinden" daraus. Der Titel entstand spontan in der Diskussion.

(Allein die Umbenennung von Workshop in Arbeitssitzung hatte einen Effekt, aber das ist eine andere Projektgeschichte...)

Das Team erarbeitete eine Liste von sehr individuellen Fragen, die es als notwendig erachtete, um Projektziel und Projektumfeld genau zu identifizieren und zu klären. Allein das gemeinsame Nachdenken über gemeinsame Fragen führte zu einem besseren Verständnis des Projektes und des Teams untereinander. Grundlagenarbeit für erfolgreiche Projektteams.

Wie kommt man denn nun an die Fragen, die weiterführen? Dazu ein kleinr Tipp. Erst einmal geht es darum so viele Fragen wie möglich zu finden, unabhängig davon, ob es die richtige Fragen sind.

Klassiche W-Fragen sind schon mal ein guter Anfang:

• Wer möchte das Projekt?
• Was genau soll umgesetzt werden ?
• Wie soll das geschehen?
• Wann soll das Projekt umgesetzt sein?
• Wofür soll das Projekt umgesetzt werden?
• Wo kann die Umsetzung erfolgen?
• Was hält uns davon ab, das Projekt umzusetzen?
• Was unterstützt das Projekt?
•   ... und so weiter ....

Kombiniert mit einem Wechsel der Perspektive ergeben sich unter Umständen ganz neue Erkenntnisse:

•  Kunden-Perspektive
• Anwender-Prespektive
• Auftraggeber
• Team-Mitglied
• oder auch: "Was würde die Schwiegermutter dazu sagen?"
• oder Perspektiven, an die bisher noch niemand gedacht hat
• zum Beispiel der Barmann meiner Lieblingsbar

Von den Fragen, die Sie finden, beantworten Sie die, die Ihnen sinnvoll erscheinen. Dann beantworten Sie die, die unsinnig sind. Wenn die Antworten auf diese Fragen keine neuen Erkenntnisse bringen, war es nicht die richtige Frage.

Man kann das ganze auch in ein Schema bringen, das hilft, keine Fragen zu vergessen:

Wen wir neue Fragen stellen, erhalten wir neue Antworten. Und möglicherweise genau die Antwort, nach der wir gesucht haben.

Damit erreichen Sie zweierlei:
1) der Projektauftrag wird klar, von allen Seiten und vielen Perspektiven durchleuchtet. Klare Projektaufträge sind schon mal ein guter Start für ein Projekt

2) das Projektteam übt, den Blickwinkel zu ändern. Spätestens bei der ersten Schwierigkeit, die im Projekt auftritt, ist dies eine nützliche Haltung.

Wer hat hier eigentlich recht?

Projektleiter Hugo leitet das wöchentliche Meeting zum Projektfortschritt. Während er über die anstehenden Meilensteine referiert, fällt ihm plötzlich sein Stellvertreter ins Wort – er spricht von der seiner Meinung nach unzureichenden Detailtiefe bei der Planung der Teilziele und bringt neue Vorschläge zur Herangehensweise. Hugo weiß in der Situation erst einmal nicht, warum ihm Peter jetzt in den Rücken fällt. Das Meeting nimmt nun einen relativ unkoordinierten Verlauf. Auch bei den nächsten Punkten, die zur Klärung stehen, ergreift Peter immer wieder das Wort und spricht (vermeintliche) Aspekte an, die mit Hugo davor überhaupt nicht besprochen waren. Hugo ist sehr erleichtert, als das Meeting vorbei ist – er muss sich jetzt zuerst einmal sammeln. „Was war denn da passiert?“, fragt sich Hugo ratlos.

Nach einer Weile dämmert es ihm – Peter wollte ebenfalls diese Stelle als Projektleiter; er ist schon lange Jahre im Unternehmen und immer noch sehr ambitioniert. Hugo selbst ist erst seit einem halben Jahr dabei. Um ihm den Einstieg zu erleichtern, wählte das Management Peter zu seiner Unterstützung als Stellvertreter aus. Das fühlte sich für Peter als Rückschritt an, weil er sich schon seit längerem als Projektleiter sieht. Hugo hatte nicht das Gefühl, dass er Peters anfängliche Einwände nicht beachtet hätte. Doch jetzt ist er ziemlich sauer, weil ihm Peter dermaßen in die Parade gefahren ist – und das auch noch vor dem ganzen Team.

Quelle: Fotolia.de

Am folgenden Nachmittag trifft er wieder auf Peter – Hugo bittet ihn um ein Gespräch. Dabei führt Peter immer wieder die fachlichen Mängel in Hugos Planung an und verweist darauf: „Das habe ich dir schon zu Anfang gesagt“. Was Peter aber eigentlich störend findet, ist, dass er zum wiederholten Male Fehler ausbügeln muss, die nicht auftreten würden, wenn er selbst die Leitung für das Projekt hätte. Auch findet er es ungerecht, dass ihm immer wieder so ein Anfänger vor die Nase gesetzt wird, er aber in der Pflicht steht wenn es kritisch wird. Grundsätzlich hat er nichts gegen Hugo, aber seiner Meinung nach wäre es sinnvoller wenn Hugo als sein Stellvertreter langsam in die Führungsposition eingeführt würde. Hugo vertraut Peters Erfahrung und argumentiert in der Aussprache damit, dass er Peters Rat sehr wohl schätzt und ihn nicht als „Untergebenen“ betrachtet, doch die Präsentation im Meeting seine Aufgabe gewesen sei. Die Einwände von Peter empfand er in dem Moment als unfair. Peter hat seine Einwände nicht im Vorfeld angeführt, das hat Hugo geärgert. Auch betont er nochmals, wie wichtig es für ihn ist jemanden an seiner Seite zu haben, der so viel Erfahrung wie Peter hat. Er schlägt ihm vor, dass die Präsentationen für die Teammeetings in Zukunft gemeinsam ausgearbeitet werden, damit eventuelle Unstimmigkeiten im Vorfeld sichtbar werden. Hugo betont nochmals, dass er Peters Meinung schätzt, und dass er sehr froh ist einen so erfahrenen Stellvertreter zu haben. Auch erwähnt er, dass er für zukünftige Projekte Peter als Projektleiter unterstützen möchte und sie dann ja auch durchaus die Rollen tauschen könnten. Peter scheint sich nun deutlich wohler zu fühlen und die gemeinsame Arbeit im Projekt wird wieder konstruktiv. Was Hugo getan hat: Er ist nicht auf die Sachthemen, die Peter anführte eingegangen, sondern hat die für Peter schwierige Beziehungsseite angesprochen und ihm seine Wertschätzung mitgeteilt. Dadurch konnte er den eigentlichen Ärger Peters besänftigen und zu einer konstruktiven Lösung kommen.

Fazit:

• Konflikte haben stets mehrere Ebenen. Häufig wird die Sachebene vorangestellt, obwohl sich dahinter ein emotionaler Konflikt versteckt. Wie bei einem Eisberg liegen mehr Themen unsichtbar unter der Oberfläche, als zunächst sichtbar. 

• Für eine Konfliktlösung ist es wichtig, dass alle Themen angesprochen werden, nicht nur die sachlichen. Dazu muss jedoch ein entsprechendes Vertrauensverhältnis bestehen. Haben Sie als Projektleiter Mut, Vertrauen zu geben. Dann wird es Ihnen auch entgegengebracht. 

• Da jeder eine Situation anders wahrnimmt und interpretiert, ist es wichtig, eine Lösung zu entwickeln, die die Perspektiven aller Beteiligten berücksichtigt. Jeder hat seine eigene Wahrnehmung einer Situation, und die muss nicht zwangsläufig mit der des anderen übereinstimmen. Hinterfragen Sie als Projektleiter öfter mal konfliktreiche Situationen: „Wie sieht denn dieser Punkt aus der Perspektive der Gegenseite aus?“

Einfach mal die Leute direkt fragen

 Es gibt Projektsituationen, da ist das Team ratlos. Zum Beispiel fehlt gerade die zündende Idee, um die Stakeholder zu überzeugen. Oder es ist unklar, ob diese eine Anforderung so ganz richtig verstanden wurde. Oder es kommt kein Feedback der zukünftigen Anwender auf den letzten Projektnewsletter. Obwohl da doch klar drinstand, dass das Projekt gerne eine Rückmeldung hätte. Aber keiner antwortet.

Es gibt dafür eine ganz einfache Projektweisheit:
Einfach mal hingehen und ganz direkt und persönlich fragen.

Im Gespräch klärt sich dann vieles wie von alleine. Möglicherweise müssen die Stakeholder gar nicht mehr überzeugt werden, nur regelmäßig informiert. Möglicherweise war diese eine unklare Anforderung doch ganz einfach, sie war nur umständlich formuliert. Und möglicherweise hatten die zukünftigen Anwender nicht verstanden, dass man auf den Newsletter einfach antworten sollte. Dafür helfen direkte Fragen. Ganz einfach.

Besonders schön können das übrigens gerade die Schweizer:

Was ist, wenn es doch kein Projekt ist?

Hugo, unser Projektleiter für besondere Fälle hat ein Problem: Was tun, wenn man entdeckt, dass das Projekt, mit dem man als Projektleiter beauftragt wurde, bei genauerer Betrachtung gar kein Projekt ist?

Die klassische Projektmanagementlehre würde sagen: "Dann, lieber Projektleiter, lehne die Durchführung ab." Nur, die Organisation des Unternehmens sagt: "nein bitteschön, ich weiß zwar, dass das kein *echtes* Projekt ist, aber unsere Unternehmensleitung wünscht sich zu diesem Thema einen Lösungsvorschlag. Bitte, lieber Projektleiter, arbeite ihn aus, sonst ..."
Nun ja, wer gewinnt? Die Projektmanagementlehre oder die Organisation des Unternehmens?
Wahrscheinlich gewinnt die Organisation. Sie gewinnt auch ein bisschen, wegen dem Argument am Schluss: "sonst ...."

Und Hugo beginnt, das beste aus der Situation zu machen. Das Projekt hat zwar ein Ziel, aber das Ziel ist so abstrakt, dass man es kaum zu fassen kriegt, ganz zu schweigen davon, es in handhabbare Arbeitspakete zu unterteilen. Denn die genauen Anforderungen bleiben im Dunkeln. Aus ganz verschiedenen Gründen.

Das Projekt fühlt sich an wie glatter Marmor, 3 Kubikmeter am Stück, und kaum eine Chance, dem Block irgendwie beizukommen. Ganz zu schweigen davon, die Statue aus dem Marmor herauszuholen, die sich darin versteckt.

Nur - der Auftraggeber möchte die Statue unbedingt. Und zwar zum festgelegten Termin. (das Argument "sonst ..." schwebt irgendwo in den Hinterköpfen aller Beteiligten).
Leider kann der Auftraggeber unserem Hugo nicht genau sagen, wie die Statue aussehen soll, noch nicht mal, ob Männlein oder Weiblein, ganz zu schweigen davon, ob die Statue jemanden abbilden soll und wen denn dann genau.

Das Prinzip, das beim Projektabschluss zum Tragen kommt, um zu entscheiden, ob das Ziel erreicht wurde oder nicht lautet "Ich weiß es, wenn ich es sehe." Gefährliche Sache für Hugo.

Was kann er tun?

Nun, Hugo hat ein paar Ideen, wie man die Sache angeht. Ganz unerfahren ist er schließlich nicht. Er beherrscht auch seine Werkzeuge. Im Prinzip kann er eine Statue schon aus dem Marmor herausholen. Das einzige was ihm fehlt sind die genauen Informationen darüber, wie sich der Auftraggeber die Statue denn vorstellt. (Die Sache mit den ungenauen Auforderungen...) Da kann er nur vermuten. Das darf er eigentlich nicht. Die Projektmanagementlehre blickt ihm streng über die Schulter und sagt: "So geht das nicht!" und die Organisation hält dagegen: "Ich will das aber so."

Also macht er sich nach Abwägung aller Konsequenzen doch an die Arbeit. Und er legt einen Schwerpunkt seiner Arbeit auf - das Projektmarketing. Dabei möchte er im Projekt trotzem weder die Qualität noch die Sorgfalt im Projekt vernachlässigen, das ist klar. Nur diesmal hat das Marketing oberste Priorität.

Denn um dem Prinzip "Ich weiß es, wenn ich es sehe" etwas entgegenzusetzen, sorgt er nun dafür, dass die Statue, die da entsteht in all ihrer Schönheit, Perfektion, und besonderen Ausführung betont wird. Die Präsentation des Projektergebnisses wird ein kleiner Event, der sich von üblichen Präsentationen von Projektergebnissen unterscheidet. Unterhaltsam, informativ und perfekt vorbereitet - das sind seine Vorgaben für den Präsentationstermin bei der Unternehmensleitung. Das ist der Auftraggeber.

Hugo hat sich zuvor in die Lage der Unternehmensleitung versetzt. Dort laufen viele Fäden zusammen. Projekte (oder scheinbare Projekte) wie das seine werden dort vielfach beauftragt. Monate später nach der Beauftragung kommt dann das Ergebnis zurück und wird im Lenkungskreis präsentiert. Die Unternehmensleitung erinnert sich vor diesem Termin kurz an den Auftrag den sie da vergeben hat und wartet ab, was denn da so kommt. Details sind erstmal Nebensache. Und im 30-Minutentakt kommt da eine ganze Menge.

Da die Projektleiter, die dort präsentieren, keine Entertainmentprofis sondern Experten ihres Fachgebietes sind, verlangt das einiges an Zuhördisziplin von den Teilnehmern des Lenkungskreises. Das Schlagwort "Death by Powerpoint" ist dort nicht unbekannt.

Das ist die Ausgangslage für Hugo mit seiner Statue. Wenn er seine Statue nun so präsentiert, dass er die Unternehmensleitung vor den üblichen Lähmungserscheinungen klassischer Projektpräsentationen bewahrt, hat er schon zur Hälfte überzeugt. Ausgangslage, Fakten, Rahmenbedingungen interessant sind für die Zuhörer ansprechend aufbereitet.
Gibt es eine Metapher oder ein Beispiel, das den Zuhörern erlaubt, schnell zu verstehen, um was es hier geht? Nicht immer hat man so viel Zeit wie man braucht, um sich im Detail vorzubereiten.
Notwendige Detailinformationen sind als Begleitmaterial vorbereitet. Dafür muss man die Präsentation nicht mit Details überfrachten, die ohnehin aus dem Zusammenhang genommen nur schwer verständlich sind. Im schlimmsten Fall führen sie zu Missverständnissen.

Und: Hugo hat sich ausnahmenweise die Mühe gemacht, seine Präsentation einer Generalprobe vor unbeteiligten Kollegen zu unterziehen. Dann fühlt er sich sicher und kann gekonnt das Ergebnis eines Projektes präsentieren, das eigentlich gar kein Projekt war.

Und die Organisation sagt zur Projektmanagementlehre "Siehste!" Und die Projektmanagementlehre sagt zur Organisation: "Aber ohne mich wäre das nicht gegangen, und außerdem beim nächsten Mal..." "Ja,ja." sagt die Organisation.

Wie war das nochmal mit dem Projektplan?

Sie haben Ihr Projekt „eigentlich“ klar geplant, trotzdem geht nichts voran, bzw. es passieren immer „Dinge“, die so nicht eingeplant waren. Das kann verschiedene Ursachen haben. Eine davon ist ein scheinbar unvollständiger Plan.

Herr P. hatte ein neues Projekt übernommen. Zusätzlich zu seinen Aufgaben in der Abteilung (Teamleiter IT-Sicherheit) sollte er noch die geltenden Datenschutz-Regelungen des Unternehmens auf den neuesten Stand bringen und an alle relevanten IT Abteilungen kommunizieren. Eigentlich keine große Sache, dachte er. Es war auch nicht sein erstes Projekt. Ein kurzer Plan war schnell erstellt. Die zuliefernden Abteilungen waren auch klar und die Arbeitspakete mit den notwendigen Ressourcen sehr übersichtlich. Trotzdem konnte kaum ein Termin eingehalten werden und es lagen nach Wochen immer noch keine greifbaren Ergebnisse vor. Mehr als ein ungehaltener Abteilungsleiter drohte mit Eskalationen des Projektes, da Herr P. sein Projekt offenbar nicht im Griff hatte.

Eine Analyse mit dem Projektcoach ergab innerhalb 1 Sitzung, dass die Planung noch einmal mit den wichtigsten Schlüsselpersonen im Projekt überarbeitet werden sollte und deren Zeitplanung mit berücksichtigt werden musste. Keine große Sache, wenn man herausgefunden hat, an welcher Stelle etwas nicht passt. Die "Kunst" (manche sagen auch "Erfahrung") ist, unvoreingenommen die richtigen Fragen zu stellen, um schnell auf den Kern des Problems zu kommen. Das Projekt wurde innerhalb 1 Woche neu geplant, neue Absprachen zu Arbeitspaketen und Terminen getroffen und der Projektplan wurde für alle verbindlich und transparent vereinbart.

Diese schnelle Hilfe sorgte dafür, dass der ursprünglich geplante End-Termin gehalten werden konnte und kein weiterer Aufwand in Eskalationsmeetings gesteckt werden musste.

Mehr Informationen dazu gibt es auch hier

Wie erzeuge ich einen Projektunfall?

Probleme - oder Projektunfälle - sind in Projekten nicht die Ausnahme, sie sind die Regel. Zwar hoffen wir meistens, dass das Projekt an so wenig Klippen wie möglich vorbeikommt, doch an ein paar Klippen verunfallt das Projekt doch meistens. Mit steigender Erfahrung weiß der Projektleiter oft schon im Voraus, was mögliche Klippen sein können. Es bleiben aber immer noch einige Überraschungs-Klippen für Projekt-Unfälle übrig.

Eine Methode, um sich mögliche Projektunfälle bewusst zu machen, ist das Umkehr-Diagramm: Statt sich zu fragen, was alles für eine erfolgreiche Umsetzung des Projektes notwendig ist, drehen Sie die Frage um: Was müssen Sie tun, um das Projekt möglichst schnell und gründlich scheitern zu lassen? Was müssen Sie tun, um eine Situation im Projekt noch schlimmer werden zu lassen?

Redet halt mal miteinander ......

Im letzten Projektcoaching-Workshop sind mal wieder die wichtigsten Merkmale klassischer Teamarbeit zu Tage getreten: Es gibt Arbeitsweisen, die sich optimal ergänzen, wenn sich die Menschen persönlich verstehen und Einsicht in die andere Denkweise des anderen haben.
Das ist oft der entscheidende Punkt, an dem sich auch gerne Konflikte entzünden: ".. Verständnis für andere Denkweisen.."
Ein Konflikt hat auch zu einem guten Teil etwas mit mir persönlich und mit meiner Haltung zum Thema Konflikt zu tun. Nicht nur die Sicht auf den anderen und den Konflikt, der gerade zwischen zwei Streithähnen gepflegt wird.

Die Erkenntnis, dass der Streithahn gegenüber den Konflikt in der Regel nicht vom Zaun bricht, um mich (den anderen Streithahn) zu ärgern, sondern weil aus seiner Sicht die Welt ganz anders aussieht als bei mir - allein diese Erkenntnis hilft oft schon, wieder einen klareren Blick zu bekommen und das Sachliche vom Emotionalen zu trennen.

Und erst dann - nach der Trennung von Emotion und Sache - besteht eine Chance, ein Argument nach dem anderen aufzuräumen und den Konflikt zu klären.

Zum Beispiel folgende Projektgeschichte:
Der Kollege Huber, seines Zeichens ausgewiesener Datenbank(DB)-Experte im Unternehmen und zuständig für Releaseplanung bestehender Datenbanken und treibende Kraft beim Testen neuer Technologien für die zentrale IT, hat zu einer Besprechung eingeladen. Zu einem Thema, das ihm wichtig ist und von dem er weiss, das einige IT-Projekte dringend auf eine technische Lösung warten. Eingeladen hat er die DB-Adminstratoren Frau Semmler und Herrn Maier, um mit Ihnen praktische Probleme bei der Migration auf eine neue DB-Version zu besprechen und deren Erfahrungen miteinzubinden.
Er, der Herr Huber hat sich viel Arbeit mit der Vorbereitung gemacht und ein Dossier erstellt, in dem er alle Tatsachen, offenen Punkte und den Entscheidungsbedarf klar geschildert hat. In der Besprechung möchte er eigentlich nur noch zusammen mit den beiden Kollegen die notwendigen Entscheidungen treffen und die weitere Vorgehensweise besprechen.
Soweit der Plan.
Dann kommt die Realität. Herr Maier ist pünktlich. Frau Semmler nicht. Herr Huber nimmt das persönlich, denn er selbst ist immer pünktlich ("das macht sie extra... klar, sie will mich nicht unterstützen...")
Dann kommt Frau Maier doch noch. Eine dringende Angelegenheit im laufenden IT-Betrieb hat sie aufgehalten. Ein Notfall. Trotzdem nimmt sie sich Zeit für die Besprechung ("... auch das noch, hier brennt doch im laufenden Betrieb überall, für so was habe ich diese Woche überhaupt keine Zeit, auch wenn´s wichtig ist..."). Leider hat sie das Dossier von Herrn Huber nicht gelesen....
Und das Unheil nimmt seinen Lauf....
Überflüssig zu erwähnen, dass es in der Besprechung zu keinerlei Entscheidung kommt.

Im Gegenteil, um der Sache den offenbar notwendigen Druck zu verleihen, schaltet Herr Huber seinen Vorgesetzten ein. Der soll dem Chef von Frau Maier mal erklären, dass sie (eigentlich: ihren Job nicht macht) .... sich auf Meetings vorbereiten soll....

Der Vorgesetzte redet mit dem Vorgesetzten, beide müssen etwas klären, von dem sie im Detail nicht genau wissen, um was es geht..... Das macht die Sache nicht leichter.

Und der Herr Huber ist sauer und frustriert. Die Frau Maier auch. Eigentlich stünden sie auf der gleichen Seite, wenn es nur um die Sache ginge. Geht es aber nicht mehr. Leider haben sie auch verpasst, sich genau anzuschauen, wo es um die Sache und wo es um die Emotion ging.

Und nun? viel Gesprächsarbeit ist notwendig, um dem verknoteten Konflikt überhaupt auf den Grund zu kommen. Sachlich lässt sich das blöderweise nicht mehr lösen. Da müsste man auch ansprechen, wer warum verärgert oder beleidigt ist .... Für manche Führungskräfte ist das nicht ganz leicht.

Mit dem Wissen über den Herrn Huber, dass er immer gründlich vorbereitet und ein akribischer Herr ist, kann sich Frau Maier leichter vorstellen, wie der Kollege reagiert, wenn sie unvorbereitet kommt. Und sie kann sofort darauf reagieren.
Andererseite, wenn der Herr Huber weiss, dass die Frau Maier eben so was wie ein Hans Dampf in allen Gassen ist, die auch kurzfristig einspringt um Probleme zu lösen und einfach nicht der Typ ist, vorher lange Dossiers zu lesen ... dann ist seine Erwartungshaltung an Frau Maier in dem Punkt nicht so hoch. Er kann eine kurze Zusammenfassung zu Beginn des Meetings geben. Und wenn´s später drauf ankommt, ist die Kollegin ja zur Verfügung...
Das könnte so klappen, wenn jeder im Team weiss, der andere arbeitet und denkt eben "anders".

 Mehr Infos ....