Chaos und Durcheinander oder Klarheit und Orientierung im Projekt

Manchmal erinnert mich ein komplexes und großes Projekt an einen Wald. Große Bäume stehen neben kleinen, alte neben jungen. Äste werden morsch, brechen ab und bleiben liegen. Moos bildet sich und dann, ganz plötzlich, wächst an dieser Stelle etwas Neues. Büsche und Sträucher versperren uns die Sicht. Der Wind bläst von Nord nach Süd, kurz darauf stecken wir mitten in einem heftigen Sturm aus Richtung Westen. Wir suchen Schutz und Deckung hinter einem dicken Baum. Es wird neblig und noch undurchsichtiger. Finden wir unseren Weg im großen Wald?

Welche Möglichkeit haben wir, um Orientierung, Klarheit und gangbare Wege zu entdecken? Im Wald und vor allem in unseren Projekten? Es gibt verschiedene Möglichkeiten, um nicht im Chaos des Projektes zu enden. Ich möchte Ihnen hier 3 einfache, aber sehr wirksame Möglichkeiten vorstellen. Den Blick auf das Ziel, den Blick auf den Weg und den Blick auf die Situation. 

Orientierung durch Ziele

Ohne ein Ziel ist kein Weg der Richtige sagt ein Sprichwort. Aber was genau ist das Ziel? Was ist das Ziel des Projektes?

Häufig habe ich erlebt, dass ein Projekt aufgesetzt war und alle schon mal „irgendwie“ über das Ziel des Projektes gesprochen hatten. Alle waren „bereits auf dem Weg“, die Aufgaben waren klar. Für die, die später ins Projekt kamen, konnte keiner mehr so richtig über das Ziel des Projektes Auskunft geben. Neue Teammitglieder wurden einfach „mit auf diesen Weg gesetzt“. Frei nach dem Motto: „Die gehen mit und werden schon dafür sorgen, dass wir alles erledigen und ankommen.“ Aber wo? Wo genau sollen sie ankommen?

Es schafft viel Klarheit, wenn in der Planungsphase die Ziele des Projektes definiert und schriftlich festgelegt werden. Die Beschreibung der Ziele kann im Projektplan, in der Projektbeschreibung oder wo auch immer dokumentiert sein.

Die Ziele sollten so realistisch, so spezifisch und so messbar wie möglich beschrieben werden. Dabei helfen die folgenden Fragen:

• Was genau ist das Ziel?
• Woran ist erkennbar, feststellbar, messbar, dass das Ziel erreicht wurde?

Hier zwei einfache Beispiele für Zielbeschreibungen:

Nicht: “Wir gestalten einen kundenfreundlichen, großen Parkplatz in der Nähe des Einkaufmarkts.”
Sondern: “Wir gestalten auf dem Grundstück des Einkaufsmarkts einen Parkplatz für 1500 Autos bis zum 31.12.2016.”

Es sorgt ebenfalls für Orientierung zu wissen, was nicht zu den Zielen gehört: “Es gehört nicht zum Ziel des Projektes, die unförmigen Hecken auf dem angrenzenden Nachbargrundstück zu pflegen.”

Je genauer die Ziele beschrieben sind, umso

• eher entsteht eine einheitliche Vorstellung des Ziels
• klarer wird die Aufgabenstellung für alle Projektbeteiligten
• deutlicher werden die Ergebnisse des Projektes sichtbar
• leichter können neue Teammitglieder integriert werden
• eindeutiger lässt sich zum Projektabschluss die Erreichung der Ziele nachweisen.

Klar beschriebene und messbare Ziele bieten also Orientierung in der komplexen Projektlandschaft.

Chaos oder Orientierung im Projekt?

Orientierung durch Prozessbeschreibungen

Prozesse gehören für jedes Unternehmen, für jedes Projekt dazu. Ein Kollege erzählt mir: Bei ihm gibt es viele Prozesse. Sein Unternehmen legt größten Wert auf die Einhaltung dieser Prozesse. Meist funktioniert das sehr gut, aber ausgerechnet sein Prozess unterliegt ständigen Änderungen. Er arbeitet im Bereich der strategischen Entwicklung und ganz oft wird sein Prozess durch Entscheidungen seines Chefs beeinflusst. Mit vielen Erklärungen und “gut zureden” versucht er sich bei den anderen Prozessbeteiligten zu entschuldigen und sie dazu zu bewegen, auch dieses Mal wieder dem veränderten Prozess zu folgen. Das bedeutet Unruhe und Ärger auf vielen Seiten. Er ist dafür verantwortlich, dass die Prozessziele erreicht werden. Es ärgert ihn, dass sein Prozess ständig für Unruhe sorgt und ihn ganz viel Zeit, Aufwand und Nerven kostet.

Wir finden heraus, dass die Ursachen für die Abweichung vom Regelprozess auf Entscheidungen des Managements basieren. Das Management wiederum reagiert kurzfristig auf Änderungen am Markt. Strategische Entscheidungen zur Anpassung des Unternehmens an den Markt sind hier also “überlebensnotwendig”.

Wir haben lange diskutiert, was dagegen spricht, einen separaten Prozess zu beschreiben, der genau diese kurzfristigen strategischen Anpassungen berücksichtigt. Einen Prozess, der den tatsächlichen Ablauf der Vorgänge beschreibt. Einen Prozess, dem man z.B. den Namen geben kann: “Änderung aufgrund strategischer Anpassungen an den Markt”.

Wochen später schreibt mir der Kollege eine Mail. Endlich kann er wieder in Ruhe arbeiten, er ist froh. Denn er hat eine Prozessbeschreibung erstellt, die genau auf diese Abweichungen eingeht. Der Prozess wurde vom Qualitätsmanagement geprüft und ist seit einiger Zeit gültig. Alle haben jetzt wieder Handlungsanweisungen, an die sie sich halten können. Die Kommunikation und die Zusammenarbeit funktionieren wieder deutlich entspannter.

• Prozesse sind richtig und wichtig. Wenn aber die tatsächlichen Abläufe im Unternehmen oder im Projekt wesentlich von der Prozessbeschreibung abweichen, ist es nicht zweckmäßig auf Einhaltung der “alten” Prozesse zu bestehen.
• Hier macht es Sinn, den tatsächlichen Prozess in einer aktuellen Prozessbeschreibung darzustellen und zu einem gültigen Prozess zu erklären.

Auch daraus ergibt sich Orientierung, Klarheit und Handlungssicherheit im Projekt.

Orientierung durch Rollenverständnis

Seit einem Jahr ist Albert Abteilungsleiter. Er ist von Hause aus Tester, hat selbst viele Jahre lang im Testmanagement gearbeitet und nun eine noch verantwortungsvollere Aufgabe übernommen. Eigentlich macht ihm sein Job Spaß, wären da nicht immer die Diskussionen mit dem Projektleiter Peter. Es gibt häufig Streit zwischen den beiden. Peter beklagt sich, dass er sich nicht vernünftig mit Albert unterhalten kann und darüber, dass sich Albert in alles einmischt, um sich zu profilieren.

Es ist Albert aber wichtig, nicht nur mit den Mitarbeitern in seiner Abteilung gut zusammenzuarbeiten, sondern auch mit seinen „internen Kunden“, mit den Projektleitern. Albert holte sich Hilfe bei einem kurzen Boxenstopp in meiner Projektwerkstatt.

Als erstes haben wir Alberts Werdegang und seine Position im Unternehmen beleuchtet. Er ist seit rund 10 Jahren im Unternehmen, hat viele Jahre als Tester gearbeitet, sich weitergebildet und ist nun seit einem Jahr der Leiter der Testabteilung. Seine 25 Mitarbeiter stehen den einzelnen Kundenprojekten zur Verfügung. Sie erstellen Testfälle und führen einen großen Teil der Tests in eigenen Laboren durch. Nach seiner Aussage gestaltet sich das alles prima, so stellt er sich seinen Job vor. Wenn da nicht Peter wäre . . .

Es stellt sich heraus, dass Albert zusätzlich direkt in Peters Projekt mitarbeitet. Er tut das nicht in seiner Funktion des Abteilungsleiters, sondern als „normaler“ Projektmitarbeiter. Für dieses Kundenprojekt ist Albert beauftragt, Testszenarien zu entwickeln und die entsprechenden Testfälle zu schreiben. Darin ist er der Experte, dort kommt ihm sein langjähriges Wissen und seine Erfahrung zu Gute.

Ganz nebenbei hat er als Abteilungsleiter sofort Zugriff auf die projektübergreifende Ressourcenplanung. Deswegen erstellt er direkt für Peters Projekt die Ressourcenzuteilung. Peter weist Alberts Ressourcenzuteilung sofort zurück und fordert Tester und Labore zu einem anderen Zeitpunkt wieder an. Genau das ist dann der Punkt, an dem sich Peter beklagt und sie ständig Konflikte austragen.

Orientierung durch funktionale Rollen

Wir klären, ob es eine Beschreibung seiner Tätigkeit, eine Beschreibung seiner funktionalen Rolle = eine Arbeitsplatzbeschreibung für ihn als Abteilungsleiter gibt. Ja, die liegt vor. Darin sind genau seine Aufgaben, seine Kompetenzen und seine Verantwortungen beschrieben und geregelt. Zu seinen vielfältigen Aufgaben gehört unter anderem, auf Anfrage der jeweiligen Kundenprojekte, die Ressourcenzuteilung seiner Mitarbeiter und Testlabore zu erstellen.

Auch für die Mitarbeit im Projekt liegt ihm eine funktionale Aufgabenbeschreibung vor. Dazu gehören die Entwicklung von Testszenarien und die Erstellung umfassender Testfälle. Die inhaltliche Beschreibung seiner Aufgaben und Verantwortungsbereiche ist erfolgt.

• Arbeitsplatzbeschreibungen = Beschreibungen funktionaler Rollen sind die erste Notwendigkeit, die Klarheit und Handlungssicherheit für den Rolleninhaber bringen.

Orientierung durch situative Rollen

Beide funktionale Beschreibungen liegen vor und dennoch gibt’s Probleme in der Zusammenarbeit. Hier war es also erforderlich noch genauer, noch detaillierter zu schauen. Wir haben den Focus auf die Situation und damit auf die situativen Rollen, die Albert im Projekt einnimmt, gelegt.

In Peters Projekt ist er nicht der „Albert Abteilungsleiter“ sondern der „Albert Testcase-Ersteller“. Sein Projektleiter Peter erwartet von ihm, dass er Testszenarien entwickelt und die entsprechenden Testfälle dazu schreibt. Genau dazu ist „Albert Testcase-Ersteller“ im Projekt beauftragt und genau das erwartet sein Projektleiter von ihm. Der Inhalt dieser Tätigkeit erfüllt soweit die Erwartungen von Peter.

Als nächstes erstellt „Albert Testcase-Ersteller“ sofort den Testzeitplan und die Ressourcenzuteilung fürs Projekt. Es gehört aber nicht zu seinem Auftrag als „Albert Testcase-Ersteller“ einen  Testzeitplan zu erstellen. Dieser Testzeitplan wird in allen anderen Projekten direkt vom Projektleiter erstellt und an die Rolle „Albert Abteilungsleiter“ übergeben.

Hier überschreitet Albert unbewusst die Grenzen seiner Rolle als „Albert Testcase-Ersteller“. Albert übernimmt damit einen Teil von Peters Job. Könnte man jetzt denken: „Na soll doch Peter froh sein, dass ihn hier jemand entlastet und unterstützt.“ Peter hingegen empfindet Alberts Verhalten als Einmischung in seinen Aufgabenbereich und er wehrt sich massiv dagegen.

In der weiteren Analyse finden wir heraus, dass Peter auch weitere gute Gründe für sein Verhalten hat. In seinem Projekt finden zusätzlich sehr viele Tests direkt vor Ort beim Kunden statt. Mit dem Kunden ist vertraglich vereinbart, dass dieser auch an internen Tests in Alberts Laboren teilnehmen darf. Dadurch ergibt sich für Peter ein hoher Abstimmungsaufwand. Diese Kundentermine können nur in Peters Testzeitplanung berücksichtigt sein. Das ist ein weiterer Grund für Peters Ablehnung.

Albert hat 2 funktionale Beschreibungen für seine Tätigkeit im Unternehmen und damit auch 2 unterschiedliche Rollen. Sein „AHA-Effekt“ entstand, als ihm klar wurde, dass er bisher aber beide Rollen „miteinander vermischt“ hat. Genau das führte zu den Problemen und Diskussionen mit Peter.  Jetzt nimmt er seine Rollen bewusst wahr und prüft je Projektsituation, welche Rolle er einnimmt.

Dazu wird er in der Zukunft:

• den Focus auf die jeweilige Projektsituation legen
• seine situativen Rollen erkennen
• diese mit den Funktionsbeschreibungen abgleichen
• die Grenzen der jeweiligen Rollen beachten
• und sich entsprechend der Rollen verhalten und kommunizieren.

Das Verständnis für situative Rollen sorgt für Orientierung und Handlungssicherheit.

Fazit

Einfluss auf Naturgewalten wie Sturm oder Nebel haben wir nicht. Aber wir können die Dinge, die zu unserem eigenen Arbeitsumfeld gehören, verändern. Ganz oft sind es die kleinen Dinge, die Veränderungen ermöglichen. Sauber definierte und gut beschriebene Projektziele, einfache und reale Prozesse sowie das Verständnis für die eigenen Rollen helfen uns, den eigenen Weg im großen Wald zu finden. Wir sind selbst in der Lage für Klarheit, Sicherheit und Orientierung zu sorgen.

Hinweise:

Informationen zur Projektwerkstatt von Annette Berger finden Sie unter http://www.pm-berger.de/.
Frau Berger bietet ein kostenloses, sehr positiv bewertetes Webinar zu “Wo kommt nur dieses Durcheinander im Projekt her?” an. Dort erzählt sie die Geschichte von Carl, der vollkommen unabsichtlich eines seiner Projekte ins Chaos stürzt. Im Webinar erfahren Sie etwas über die möglichen Gründe der Unruhe im Projekt. Sie erleben, wie Rollenverständnis für sehr viel Klarheit im Projekt sorgt und wie Carl in seinem nächsten Projekt erfolgreich sein kann.