Open Loops

Die Anforderungen an Projektmanager/innen steigen in dem Maße, in dem die Komplexität von Projekten zunimmt. Je komplexer das Vorhaben, desto höher sind die Ansprüche an die Führungsfähigkeit der Person, die das Projekt leitet. Denn mit der Komplexität steigen Anzahl, Verschiedenartigkeit und Verwobenheit der sozialen Beziehungen, die gemanagt werden müssen. Eine Fähigkeit wird Projektmanager/innen dabei ganz besonders abverlangt: Politisch denken – systemisch handeln. Was genau heißt das?

In Projekten politisch zu denken bedeutet, dass Sie als Projektleiter/in darauf achten, einen Interessenausgleich zwischen den verschiedenen Anspruchsgruppen zu ermöglichen. Dies setzt voraus, dass Sie wissen:

• welche Anspruchsgruppen es überhaupt gibt,
• welche Interessen bei den jeweiligen Gruppen (wirklich) bestehen,
• welchen Einfluss die jeweilige Gruppe auf den Projekterfolg hat,
• in welchen Abhängigkeits- und Wechselwirkungsverhältnissen die Anspruchsgruppen untereinander stehen,
• welche Rahmenbedingungen (z.B. gesetzliche Regelungen, vorhandene Technologie) ggf. eine Rolle spielen.

Das klingt logisch, ist in der Praxis aber alles andere als trivia. Als Hilfsmittel können Sie mit Systemdiagrammen arbeiten, die die Beziehungen abbilden und so einen Überblick vermitteln. Darüber hinaus benötigen Sie als „politisch denkende/r“ Projektleiter/in aber auch Know-how über:

• die Dynamik von Machtprozessen und den Umgang mit Machtmitteln
• die Entstehung, den Verlauf und die Bewältigung von Konflikten
• die Einführung und Gestaltung von sozialen Regeln

Die Kunst des systemischen Handelns besteht nun darin, die eigenen Aktionen mit Bedacht auf ihre Auswirkungen im Gesamtsystem (Projekt) auszuwählen. Als Projektleiter/in müssen Sie sich im Klaren darüber sein, welche vernetzten Wirkungen aus Ihrem Handeln resultieren können. Soziale Systeme sind nur bedingt steuerbar (wie bedingt, darüber streiten die Gelehrten), doch wer geschickt bestimmte Stellschrauben bewegt und erkennt, welche Dynamiken sich daraus ergeben, hat einen guten Stand und kann gezielt Einfluss nehmen. Im Grunde ist das doch die Aufgabe einer jeden guten Projektleiterin und eines jeden guten Projektleiters: vernetzte Prozesse zu initiieren und mit einander zu versöhnen.

Die Schaffung von Projektstrukturen erfolgt stets in Abhängigkeit von der Größe der zu lösenden Herausforderung. In Großprojekten sind z.B. Lenkungskreis, Expertenkreis, Teilprojektleiter, Projektmanagementoffice, Programmmanagement, Soundingboard etc. mögliche Strukturierungselemente, die hilfreich sein können. Die Strukturierung dient der Bewältigung der vorhandenen Komplexität. Unabhängig von der Strukturierung hat die Projektleitung jedoch immer einen Engpass: die am Tag (Nacht) zur Verfügung stehende Zeit.

Mit der Schaffung der Struktur wird in der Regel der Teil der Kommunikation von der Projektleitung abgedeckt, die nach oben geht (Auftraggeber, wichtige Personen im Umfeld etc.) sowie die unmittelbare Kommunikation mit den Teilprojektleitern. Dies ist auf der einen Seite der gewünschte Zustand, um nicht mit “allen” sprechen zu müssen. Auf der anderen Seite ist es aber notwendig, als Projektleiter zu jedem beliebigen Zeitpunkt eine klare Beschreibung der Lage/Situation des Projektes liefern zu können. Üblicherweise geschieht dies auf Basis der aggregierten Berichte der Teilprojektleiter. Der Projektleiter selbst fasst die Berichte zusammen und berichtet sie den entsprechenden Stellen.

Dieses Vorgehen stellt die Handlungsfähigkeit der Projektleitung sicher, jedoch habe ich festgestellt, dass schnell eine Art “Elfenbeinturmeffekt” entsteht. Die Beschreibungen der Lage des Projektes basieren fast ausschließlich auf den vereinbarten Kommunikationskanälen. Selbst mit sehr sorgfältig durchgeführten Stakeholder und Umfeldanalysen treffe ich immer eine Unterscheidung was system-/projektrelevant ist und was nicht. Eine Möglichkeit diesen Effekt abzuschwächen ist die Planung des Nicht-Planbaren, d.h. ich organisiere mir Zeit, um mit Menschen aus dem Projekt und auch mit Menschen außerhalb des Projektes in Kontakt zu kommen. Dabei handelt es sich nicht um fixe Termine, sondern um mehr oder weniger zufällige Begegnungen, die ich während meines “Rundgangs” treffe. Meine Erfahrung ist, dass die auf diese Weise gesammelten Informationen einen guten Beitrag zur Beschreibung der Projektsituation liefern und damit zum Projekterfolg beitragen. Nicht selten sind es sogar gerade diese Informationen, die sich anbahnende Schieflagen oder unterschwellige Konflikte ans Licht bringen.

Auf den DSAG Technologietagen mit dem Schwerpunkt “Komplexität - erkennen, beherrschen, vermeiden” waren wir in der letzten Woche sicherlich Exoten: Unser Vortrag “Komplexität beherrschen - Agil arbeiten” am 24.02.2010 war aber dennoch gut besucht. Es gibt offensichtlich ein starkes Interesse daran, auch in SAP-Projekten alternative Vorgehensmodelle auszuprobieren.

Die DSAG Technologietage werden seitens SAP genutzt, um technische Neuerungen vorzustellen und einen Ausblick auf zukünftige Entwicklungen zu geben. Als Kontrapunkt gibt es eine Vielzahl von Kundenvorträgen, die ihre jeweils ganz eigenen Erfahrungen mit SAP-Systemen und -Technologien präsentieren. Das inhaltliche Themenfeld umfasste dabei so unterschiedliche Bereiche wie Geschäftsprozessmanagement, Solution Manager, Identity Management, Application Integration und Master Data Management.

Im Rahmen der Arbeitsgruppe “SAP Netweaver Development - ABAP und Java” haben wir unsere Adaption agiler Methoden auf das SAP-Projektumfeld vorgestellt. Als besondere Herausforderung sehen wir im SAP Umfeld hierbei

• modulübergreifende und eigenverantwortlich arbeitende Projektteams,
• die Pflege eines integrierten Product-Backlogs mit fachlichen Anforderungen, die in einer Iteration umgesetzt werden können,
• häufige Releases und der damit u.a. verbundene Schulungsaufwand sowie
• Testautomatisierung.

In der Diskussion kristallisierten sich neben den “üblichen” Herausforderungen rund um Festpreisverträge und Skalierung von Scrum auch SAP-spezifische Stolpersteine heraus:

• Mangelnde Toolunterstützung für das Refactoring von ABAP-Code
• Wenig verbreitete Testautomatisierung
• Kaum ausgeprägte Integration der Fachabteilungen während der Umsetzung

Über Austausch zu diesen Themen würden wir uns sehr freuen. Wie sind Ihre Erfahrungen?

Die SWOT-Analyse ist ein Instrument zur Situationsanalyse und Strategiefindung. Sie erfasst zunächst die innerbetrieblichen Stärken (Strengths) und Schwächen (Weaknesses) sowie die durch die Unternehmensumwelt bestimmten Chancen (Opportunities) und Risiken (Threats). Da Stärken und Schwächen relative Größen sind, können diese erst im Vergleich mit den Wettbewerbern des Unternehmens beurteilt werden. Deshalb verknüpft die SWOT-Analyse die unternehmensinterne Perspektive, also seine Stärken und Schwächen, mit der Umweltentwicklung, definiert durch Chancen und Risiken, in einer Matrix. Auf diese Weise liefert die SWOT-Analyse eine Informationsgrundlage für die Ableitung geeigneter strategischer Optionen.

Eine SWOT-Analyse wird in 4 Schritten durchgeführt:

Schritt 1: Stärken-Schwächen-Analyse
Mit einer Stärken-Schwächen-Analyse werden die Bereiche identifiziert, in denen das Unternehmen Wettbewerbsvorteile besitzt. Das geschieht durch Vergleich der spezifischen Stärken und Schwächen des Unternehmens mit jenen der Wettbewerber basierend auf einer Potentzial- und einer Konkurrenzanalyse.

Schritt 2: Chancen-Risiken-Analyse
Im Rahmen einer Chancen-Risiken-Analyse werden diejenigen Umweltentwicklungen identifiziert, die Chancen bzw. Risiken für den Unternehmenserfolg darstellen und die deshalb für die Unternehmensstrategie relevant sind.

Schritt 3: SWOT-Analyse
Die eigentliche SWOT-Analyse integriert die Ergebnisse aus Schritt 1 und Schritt 2 mithilfe einer Matrix. Dabei werden die innerbetriebliche Achse und die Umweltachse in jeweils ein positives (Stärken bzw. Chancen) und ein negatives (Schwächen bzw. Risiken) Feld unterteilt. Daraus ergeben sich vier Felder, denen sich die in Schritt 4 beschriebenen Strategiearten zuordnen lassen.

Schritt 4: Ableitung von Strategien aus der SWOT-Analyse
Abschließend wird versucht, den Nutzen aus Stärken und Chancen zu maximieren und die Verluste aus Schwächen und Risiken zu minimieren.

• SO-Strategien
  Durch den Einsatz der Stärken des Unternehmens sollen die identifizierten Chancen genutzt werden.
• ST-Strategien
  Durch die Einsatz der Stärken des Unternehmens soll den Risiken entgegengewirkt werden.
• WO-Strategien
  Zur Überwindung von Schwächen sollen Vorteile aus den Chancen gezogen werden.
• WT -Strategien
  Durch den Abbau von Schwächen sollen Risiken gemindert werden.

Ein großer Vorteil der SWOT-Analyse liegt darin, dass sie einfach durchzuführen ist und außer dem zeitlichen Aufwand keine weiteren Kosten verursacht.

Wurde die SWOT-Analyse zunächst für die Strategiefindung von Unternehmen eingesetzt, kann diese ebenso sinnvoll für die Analyse von Teams und Abteilungen verwendet werden.

Weiterführende Beschreibungen der SWOT-Analyse finden Sie in Wikipedia sowie im Wissens- und Informationsportal zum Thema Business und Management Onpulson.

Der Begriff “Eskalation” ist häufig negativ besetzt: Man verbindet damit gewöhnlich das (unnötige) Ausufern eines Konfliktes oder eines Problemes, ohne dass damit eine Lösung in Sicht gerät. Immer wieder wird in Projekten auch mit einer Eskalation gedroht, um den Druck zu erhöhen. Diese negative Konnotation von “Eskalation” ist sehr schade, denn richtig angewandt können Eskalationen dazu beitragen, Probleme dort zu lösen, wo sie entstehen. Ich verwende bei Kunden daher gern den Begriff der Konstruktiven Eskalation als Lösung für die im Folgenden beschriebenen Situationen.

In Projekten treten fast zwangsläufig Probleme auf. “Gutartige” Probleme lassen sich in der Regel innerhalb des Projektumfeldes und damit im Wirkungsbereich des Projektleiters lösen. Es gibt jedoch immer wieder auch Probleme, die ihre eigentliche Ursache außerhalb des Projektkontextes haben, das Projekt aber extrem stören können. Solche Probleme lassen sich daher meist nicht alleine durch den Projektleiter lösen. Wenn z.B. ein Mitarbeiter der Fachabteilung nicht im zugesagten Umfang zur Verfügung steht, hat dies massive Auswirkungen auf den Fortschritt der Konzeption oder Umsetzung. Mangels disziplinarischer Macht kann der Projektleiter den Mitarbeiter in der Fachabteilung in der Regel aber nicht zu mehr Mitarbeit zwingen. Meistens möchte derjenige ja auch gerne am Projekt mitwirken, kann dies aber nicht im gewünschten Maße, da er nicht von anderen Aufgaben entbunden wird. Ein solches Problem kann nicht vom Projektleiter allein gelöst werden. Er kann aber mittels einer konstruktiven Eskalation eine Lösung des Problems bei den Verantwortlichen einfordern. Konkret sollte wie folgt vorgegangen werden:

Die eigentlichen Ursachen des Problems sind zu analysieren und zu prüfen, ob diese im Projektkontext gelöst werden können. Ist dies nicht der Fall, muss der potentielle Adressat einer Eskalation ermittelt werden: Durch wen außerhalb des Projektes kann das Problem gelöst werden? Ohne einen Adressaten oder mit einem falschen Adressaten besteht die Gefahr, dass die gewünschte Entscheidung nicht getroffen wird, weil der Angesprochene dazu schlicht nicht befugt ist. Ist der Adressat ermittelt, gilt es Lösungsszenarien aufzuzeigen. Im obigen Beispiel könnte dies sein, den Mitarbeiter der Fachabteilung von anderen Aufgaben zu entbinden oder dem Projekt einen anderen Ansprechpartner zuzuordnen. Die Szenarien sind dann mit Vor- und Nachteilen in Hinblick auf das Projekt und - soweit möglich - auf sonstige Betroffene anzureichern. Es sollten immer mindestens zwei mögliche Lösungen ermittelt werden. Zu viele Optionen wiederum führen aber ebenfalls nicht zu einer schnelleren Lösung. Anhand der Vor- und Nachteile sollte auch immer eine aus Sicht des Projektes präferierte Lösung benannt werden. Zur Aufbereitung eines Szenarios gehört auch das Aufzeigen der Konsequenzen für das Projekt. Dies gilt auch für den Fall, dass keine Lösung des Problems zustande kommt.

Mit den bewerteten Szenarien kann dann von den Verantwortlichen eine Entscheidung eingefordert werden. Dies kann im Rahmen eines Steuerungsgremiums geschehen oder auch unabhängig davon. Die Verantwortung für die Lösung liegt durch die konstruktive Eskalation wieder dort, wo auch die Ursache des Problems zu finden ist: außerhalb des Projekts. Es gilt hierbei natürlich, auch eine solchermaßen konstruktiv durchgeführte Eskalation nicht als Standardweg zur Problemlösung zu verwenden. Es besteht ansonsten die Gefahr, dass die Eskalationen nicht mehr Ernst genommen werden und sich im Ernstfall wichtige Entscheidungen nicht mehr herbeiführen lassen.