Wann ist der richtige Zeitpunkt um über ein Projekt zu informieren?

Carl hat eine richtig gute Idee. Eine kleine Software-Anpassung und schon würden die Abläufe in der Auftragsabwicklung seines Unternehmens viel einfacher laufen. Daten müssten nicht mehr manuell übertragen werden und die Kollegen vom Controlling bekämen ihre Auswertungen auch viel schneller. Eine richtig gute Idee, findet Carl. Er redet mit einigen Kollegen aus der IT darüber. Auch die finden die Idee gut. Er redet mit seinem Chef darüber, ob er die Anpassung in der nächsten Zeit einfach mal umsetzen soll und legt ihm einen Projektplan vor.

Doch wie das so ist, mit Projekten, die man für eine gute Idee hält, es gibt immer auch eine andere Meinung zu der Idee. Carl war so begeistert von seinem zukünftigen Projekt, dass er an diese Möglichkeit gar nicht dachte.

Der Leiter der Auftragsabwicklung war gar nicht begeistert von Carls Idee. Einer seiner Mitarbeiter hatte ihm davon erzählt, nachdem Carl am Rande eines Meetings zu einem andern Thema begeistern von seinem neuen Projekt erzählt hatte. Das Gespräch war nur kurz, obwohl Carl gerne ausführlicher über seine Idee diskutiert hätte. Doch der Kollege hatte sich ein paar Details gemerkt und berichtete dem Leiter der Auftragsbearbeitung davon. Ein kurzes Gespräch mit dem IT-Leiter, Carls Chef, und das Projekt wurde gestoppt, bevor es angefangen hatte. Carl erfuhr nie den Grund.

Seine Begeisterung hatte schlussendlich dazu geführt, dass der sich in seiner Motivation gebremst fühlte und der Leiter der Auftragsabwicklung verärgert war über eigenmächtige Eingriffe in die Abläufe seiner Abteilung.

Es hätte auch ganz anders laufen können.

Auch wenn Carl von dem Nutzen seiner Idee vollkommen überzeugt ist bedeutet das nicht automatisch, dass andere Kollegen es auch sofort sind. Daher lohnen sich ein paar Überlegungen im Vorfeld, zum Beispiel:

Über das Umfeld des Projektes:
- Wie ist das Umfeld (wer ist für / wer ist gegen das Projekt ---> das ist die klassische „Stakeholderanalyse“)
- Wer ist in welcher Form von dem Projekt betroffen und welche Reaktionen können sich daraus ergeben?
- Wen brauche ich, um mein Projekt zu unterstützen?

Über den gegenwärtigen Projektzustand:
- wo steht mein Projekt? Was habe ich schon / Was fehlt noch?
- Was ist das größte Risiko?

Über eine „geschickt eingefädelte“ Kommunikation: - wen informiere ich wann am besten über das Projekt?
- in welcher Detailtiefe?
- in welcher Form (persönlich, schriftlich, öffentlich, unter 4 Augen, etc.)?
- wann informiere ich worüber?

Zuviel Details können zum falschen Zeitpunkt für Verwirrung und Ablehnung stoßen.
Zuwenig Information oder zu späte Information kann ebenfalls zur ablehnenden Reaktionen führen.

Das sind nur ein paar Fragen, um den "richtigen Zeitpunkt" zu finden. Je nach Projekt und Umfeld, fallen Euch bestimmt noch mehr ein.

Entscheidend ist oft, die Art und Weise, wie ich über das Projekt informiere. Dabei auch immer die Reaktionen des Gegenübers beachten. Bei Themen, bei denen ich mit einer großen emotionalen Reaktion rechnen muss, muss ich sensibler vorgehen, als bei Themen, die eher nüchtern bewertet werden. Das hat übrigens nichts mit dem Thema zu tun. Auch technische Themen können sehr emotionale Reaktionen hervorrufen. Je emotionaler, desto sorgfältiger muss ich informieren, da hier die Risiken von Missverständnissen in der Kommunikation steigen.

Projekte sichtbar machen - Visualisieren Sie Ihr Projekt

Wir lieben scheinbar ungewöhnliche Methoden, die Projekte zum Ziel führen. Wie in unserer letzten Projektgeschichte erzählt, ist die Sichtbarkeit eines Projektes ein Erfolgsfaktor (hier...)
Ein Projekt wird leicht sichtbar, wenn es Inhalte gibt, die man sehen kann, im einfachsten Sinne des Wortes: Zur Sichtbarkeit gehört Visualisierung. Wir haben uns kürzlich mit den Experten von Visual Braindump dazu unterhalten.

Hier ist ein Auszug unseres Gesprächs als Experten-Interview:

In welchen Situationen im Projekt ist die Visualisierung für Projektleiter nützlich?

Die Frage möchte ich zuerst zurückgeben: Wann ist die Visualisierung für Projektleiter nicht nützlich? Genau dann, wenn alle Inhalte zu Thema, Ziel und Ablauf allen Beteiligten klar sind. Da das in einem Projekt in den seltensten Fällen zutrifft, lautet die Antwort auf die ursprüngliche Frage: so oft wie möglich! 

Visualisierung im Projekt besticht durch klare Vorteile:

1. Als Projektleiter schaffe ich es, durch Visualisierung Inhalte schnell und effektiv zu transportieren. (Prozess)-Beschreibungen mit grafischen Stilelementen, Kanban, Ziel-Bilder…  auch die Ausgestaltung klassischer Power-Point-Folien ist möglich. 
2. Die Methode der Visualisierung ist eine Kreativmethode. Die Erarbeitung von Inhalten im Team erfolgt durch Visualisierung in einer (von Natur aus) kreativen Art. Als Projektleiter kann ich mit ihr Lücken und Unklarheiten identifizieren und eliminieren. 
3. Eine Visualisierung dient der Verinnerlichung von Inhalten. Eine grafische Aufbereitung komplizierter Themen liefert einen Gesamteindruck zu spezifischen Themenkomplexen auf den ersten Blick, bleibt im Kopf und lädt bei Interesse zu Detailsichtungen weiterer Inhalte (textuell, verbal oder anhand weiterer Bilder) ein. Schnell und unkompliziert.

Welche Vorurteile/Bedenken gegenüber Visualisierung haben Projektleiter?

Beim Einsatz im Projektteam gibt es vorrangig zeitliche Bedenken. Eine Zeichnung zu erstellen, erfordert Zeit. Dem gegenüber steht die zumeist geforderte Erstellung von Texten durch den Kunden (Dokumentationen, Meeting-Protokolle anhand Vorlagen, Reports…).

Stakeholder, bzw. das klassische Management reagieren in Ausnahmefällen differenziert. Zeichnungen werden gerne aus eigener Unsicherheit heraus als „Überflüssig“ bezeichnet. Meistens sind Reporting-Sheets oder technische Dokumentationen in Unternehmen standardisiert. Zum Zwecke der Vergleichbarkeit wird oft auf diese Formalie bestanden. 

Die Einführungsmaßnahme ist denkbar einfach: machen. Dabei gilt es, die richtige Dosierung der grafischen Gestaltung zu finden, die Dosierung stückweise zu erhöhen und einen schonenden Wechsel zu finden. Der Mehrwert der grafischen Darstellungsweise wird überzeugen. Seien Sie in den Bereichen mutig, in denen keine Standardisierung vorliegt. Beispiele:

• Das Meeting-Protokoll ist standardisiert -> Ergänzen Sie durch eine weitere Seite mit der visuellen Zusammenfassung.
• Es existiert eine Vorlage zur Dokumentation von Inhalten (Format, Deckblatt, Überschriften…) -> Ergänzen Sie Einzelbilder im Dokument
• Die Projekt- oder Aufgabenstellung ist noch nicht klar. Perfekt! Zeichnen Sie ein gemeinsames Bild mit Ihrem Auftraggeber. Halten Sie dann die Ergebnisse in einem „klassischen“ Pflicht- und/oder Lastenheft fest. Doppelter Erfolg: Ein gemeinsames Ziel-Bild wurde geschaffen und dient Ihnen und Ihrem Auftraggeber als Aushängeschild zur weiteren Erklärung vor Dritten.
• Konkret: Welche Fragen können Sie als Projektleiter im Laufe Ihres Projektes zweifelsfrei mit „ja“ beantworten?
• Sind die fachlichen Inhalte als Voraussetzung zur schriftlichen Darstellung klar?
• Ist das kollektive Verständnis zum Thema/Ziel/Scope/Umfang vorhanden?
• Ist die Schriftform die „beste“ Variante zur Verteilung von Wissen in Kontext des Projektauftrages?

Falls Sie eine der Fragen mit „Nein“ beantworten: Versuchen Sie die grafisch/bildliche Darstellung. 

Ein Bild mag keine technische Dokumentation vollständig ersetzten. Ein Bild bietet dagegen eine wesentliche Ergänzung. Einsatzmöglichkeiten sind auch hier: Bildelemente in Dokumentationen; die Darstellung von Kernelementen in Meetings; grafische Elemente als visueller Anker oder visuelle Darstellungen von Produktinformationen, Abläufen und Prozessen. Selbst gezeichnete Bilder, sind etwas Einzigartiges, laden zur Betrachtung ein und – sofern an der richtigen Stelle platziert – garantieren die Aufmerksamkeit die Ihr Projekt erfordert.

Warum Sichtbarkeit für Projekte wichtig ist

Es gibt Projekte in Unternehmen, über die weiß scheinbar jeder Bescheid und es gibt Projekte, die kennt kein Mensch. Stimmt´s? Das hat interessanterweise gar nichts mit der strategischen Bedeutung der Projekte für das Unternehmen zu tun.

Georg leitet ein großes Infrastrukturprojekt in seinem Unternehmen, einer Versicherung. Die Netzwerk-Struktur soll an die gestiegenen Anforderungen angepasst werden. Ein längst fälliges Vorhaben und für die Zukunftssicherung wichtig. Also durchaus strategisch zu nennen. Das Projekt läuft, die Meilensteine werden pünktlich erreicht, es gibt immer mal wieder kleinere Abweichungen, Fehler treten auf und werden beseitigt. Georg ist ein eher ruhiger Projektleiter („Fragen stören eh nur“ ist seine Lieblingseinstellung), ein sehr genauer Fachmann, der das auch von seinem Team erwartet. Außerdem gilt er als QS-Fanatiker, der sich gerne mal in Details verliert. Das Team spricht sich untereinander ab, und ist es gewohnt, selbständig nach Lösungen zu suchen, bevor jemand von außen hinzugezogen wird. Daher wissen auch relativ wenige Kollegen im Unternehmen über dieses Projekt Bescheid.

Hans leitet ein ähnliches Projekt im gleichen Unternehmen. Das Projekt hat einige Abhängigkeiten zu Georgs Projekt. In Hans´ Projekt gibt es laufend Verzögerungen: die Hardware wurde zu spät geliefert, Zusagen von Lieferanten wurden nicht eingehalten, Details in der Auslieferung und Installation übersehen, und so weiter. Hans ist dementsprechend laufend unter Druck und sehr überlastet. Vor lauter Überlastung übersieht er regelmäßig Aufgaben, die er leicht delegieren könnte, aber es lieber „schneller selbst erledigt“. Fragen seines Teams stören ihn eher, im Zweifelsfall kümmert er sich um kritische Dinge lieber selbst. Er gilt als QS-Fanatiker, der sich gerne mal in Details verliert. Das Team ist vorsichtig geworden und sichert sich in kritischen Situationen lieber ab. Da die kritische Situation ein Dauerzustand ist, geht die Arbeit nur zögerlich voran.

Aufgrund der Probleme bei Hans´ Projekt ist die Unternehmensleitung bestens über den aktuellen Stand informiert. Schließlich müssen laufend Entscheidungen getroffen werden, Änderungen genehmigt, Risiken diskutiert, usw. Für Georgs Projekt bleibt entsprechend weniger „Management Attention“ übrig. Einerseits nicht schlecht, dann kann Georg wenigstens in Ruhe arbeiten, sollte man meinen. Das geht so lange gut bis folgende Situation eintritt: In Hans Projekt verschiebt sich aufgrund der Verzögerungen der Fertigstellungstermin soweit, dass Georgs Projekt davon massiv betroffen ist. Im letzten Steuerkreis zu den Infrastrukturprojekten ging es letztendlich darum, welches der beiden Projekt gestoppt und auf später verschoben werden soll. Da alle Beteiligten bestens über Hans´ Projekt informiert waren und wenig über Georgs Projekt, fiel die Entscheidung gegen Georg.

Georgs Projekt lief zwar gut, war aber zu wenig „sichtbar“ im Unternehmen. Kritische Abhängigkeiten konnte Georg zu dem Zeitpunkt, als er von der anstehenden Entscheidung erfuhr, nicht mehr klar vermitteln, da insgeheim die Entscheidung schon getroffen worden war. Eine paradoxe Situation: über problematische Projekte sind Alle gut informiert, glatt laufende Projekte werden übersehen und erhalten nicht die Aufmerksamkeit auf Entscheider-Ebene, die sie bräuchten.

Eine einzige, wichtige Projektleiter-Aufgabe hatte Georg schlicht unterschätzt: für angemessene Sichtbarkeit seines Projektes sorgen.

So habe ich das nicht gemeint ....

"Die Basis erfolgreicher Projekte ist eine gute persönliche Beziehung zu Auftraggeber und Stakeholdern." Das war das Ergebnis eines intensiven Erfahrungsaustausches zwischen Geschäftsführern der IT-Branche in Augsburg, den wir kürzlich moderiert haben. Dabei kam ein ganz typischer Fall eines Projektes zur Sprache, in dem der Projektleiter formal alles richtig gemacht hat, und das Projekt trotzdem in Schieflage zu geraten droht.

„Meine Projektleiter setzen manchmal Sachen um, ohne Verstanden zu haben, was der Kunde damit tun möchte.“ Peter, Geschäftsführer eines mittelständischen Software-Dienstleisters, versteht die Welt nicht mehr. „Der Kunde wollte einen Button, mit dem alle Aktionen zur Bestellbearbeitung auf einmal rückgängig gemacht werden sollen. Das habe ich ihm programmieren lassen und jetzt beschwert er sich, dass diese Funktion kompletter Unsinn ist.“, berichtet Projektleiter Hans in der internen Projektleiter-Runde seinem Chef. „Ist ja klar, dass wir so mit den geplanten Aufwänden niemals hinkommen. Ich kann mich auf die Aussagen beim Kunden offenbar überhaupt nicht verlassen.“

Peter, der Geschäftsführer, rauft sich die Haare. Das Projekt sollte schon längst fertig sein und Hans sollte das nächste Projekt begonnen haben. Das geht aber nicht, weil ein „normaler“ Kunde auf einmal zum verärgerten Kunden zu werden droht. Und offenbar weil er etwas verlangt hat, was er anschließend nicht mehr haben wollte.

Ist Ihnen eine derartige Szene auch schon vorgekommen?

„Hast Du gefragt, was der Kunde mit der Funktion beabsichtigt hat“, möchte Peter von seinem Projektleiter wissen. „Nein, er hatte ja alles ausführlich beschrieben, dann habe ich es umsetzen lassen. Die Anforderungs-Dokumentation war komplett ausgefüllt. Außerdem war die Zeit zu knapp. Das nächste Projekt steht ja schon an.“ Hans findet, er hat alles richtig gemacht.

Das hat er auch, nur reicht das nicht. Solange der Projektleiter Hans nicht genau verstanden hat, was für den Kunden der Sinn und Nutzen der Software ist, die er beauftragt hat, werden solche Szenen immer wiederkehren. Peter möchte das verständlicherweise abstellen. Sein erster Impuls ist, für seine Projektleiter eine neue Regel aufzustellen: „Hinterfrage jede Anforderung immer genau nach Sinn und Nutzen für den Kunden.“ Dann stellt er fest, dass im Formular für die oben erwähnte Anforderungsdokumentation bereits ein entsprechendes Feld dafür vorhanden ist. Füllen es die Projektleiter aus? Ja, typische Standard-Antwort: „Kunde hat gesagt, er braucht das.“

Ok, Regeln scheinen nicht weiter zu helfen. Was dann?

In der Projektleiter-Runde kommt ein anderer Lösungsansatz zur Sprache, und zwar ganz intuitiv. Einer der neuen Projektleiter, Micha, fängt an, Hans` Situation zu hinterfragen, weil er als Neuer die Zusammenhänge und Arbeitsweisen noch genauer kennenlernen möchte. Und je genauer Micha nachfragt, umso mehr wird die Lösung für Hans klar: dieses Gespräch hätte er vor der Programmierung der Bestellbearbeitung mit dem Kunden führen sollen. Michas Fragen haben ihn darauf gebracht, den Nutzen der Funktion nochmal genauer zu durchdenken. Und es fällt ihm auf, dass er tatsächlich eine andere Annahme darüber hatte als der Kunde. Peter und seine Projektleiter beschließen, dass der regelmäßige Bericht an den Kunden über den Projektfortschritt eine andere Qualität bekommen muss. Es soll nicht nur ein Bericht über den Stand des Projektes sein, sondern auch ein Dialog mit dem Kunden, um ihn und die Absichten „hinter der Software“ besser zu verstehen. Projektkommunikation eben.

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: