Open Loops

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.

Unentbehrlich sein zu wollen ist menschlich. Wer möchte nicht gerne gefragt sein und im Mittelpunkt stehen? Das gilt auch für Manager. Besonders externe Berater haben ein Interesse daran. Das hat ganz sicher auch finanzielle Vorteile.

In Großprojekten und Turnarounds hingegen wirkt dieses gelernte und verinnerlichte Muster kontraproduktiv. Zieht man zuviel Arbeit an, kann man nicht schnell genug delegieren. Als Kopf wird man zum Flaschenhals - unentbehrlich zu sein führt in diesen herausfordernden Umgebungen unweigerlich zu Überlastung und Misserfolg.

Ich möchte erfolgreich sein. Da stellt sich die Frage: Wie wird man entbehrlich? Meiner Erfahrung nach gelingt dies durch das Schaffen von Strukturen und Abläufen in Projekten und Organisationen. Ich habe dabei die folgenden Erfahrungen gemacht:

Die Strukturen dürfen auf keinen Fall zentralistisch sein. Statt “alle berichten an einen”, berichtet vernetzt jeder an jeden, für den die Information wichtig ist. Dafür müssen Gremien geschaffen werden. Statt “alle bitten eine Person um eine Entscheidung”, bereiten die Personen, die am meisten zur Entscheidung beitragen können, die Entscheidung vor, so dass sie schon “getroffen ist”. Das impliziert: Strukturen werden dynamischer, gelten vielleicht nur für Phasen im Projekt, ggf. sogar nur für wenige Tage. Und es strengt an, ist aber effizient und fördert Redundanzen und damit die Reaktionsfähigkeit des Projektteams auf unvorhersagbare Ereignisse. Nicht mehr einzelne Personen sind wichtig, sondern die vernetzte und dynamische Struktur.

Verlässlichkeit und Ordnung schafft man hingegen durch Abläufe. Meetings finden immer zum gleichen Zeitpunkt, für die gleiche Dauer und den gleichen Teilnehmerkreis statt. Sie haben eine feste Struktur und werden in immer der gleichen Weise effizient moderiert. Beispiele sind die morgendliche Telko und die wöchentliche Projektleiterrunde. Aus diesen festen Abläufen ergeben sich häufig auch die angesprochenen virtuellen Strukturen, quasi kleine Projekte im Projekt: “Sorgt ihr drei bitte binnen vier Wochen dafür, dass die benötigten Daten da sind”.

Meine These: In großen und komplexen Projekten werden Strukturen dynamischer und Abläufe fester. Für mich ist diese Erfahrung wichtig, um entbehrlich sein zu können und Erfolg zu haben.

Und wenn das alles bei Ihnen nicht klappt oder Sie der These nicht zustimmen mögen, lesen Sie doch noch den Artikel Verschnaufpausen für Unentbehrliche von Monika Setzwein.