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.

Als “Antwort” auf das Gravitationsprinzip der Arbeit möchte ich heute über eine Möglichkeit schreiben, damit umzugehen: Das Priorisieren von Aufgaben mithilfe des Eisenhower-Prinzips.

Das Eisenhower-Prinzip ist eine Möglichkeit, anstehende Aufgaben in Kategorien einzuteilen. Dadurch sollen die wichtigsten Aufgaben zuerst erledigt und unwichtige Dinge aussortiert werden. Es wurde vom US-Präsidenten und Alliierten-General Dwight D. Eisenhower praktiziert und gelehrt. Das Eisenhower-Prinzip gilt heute als bewährtes Instrument des Zeitmanagements. Dieser Begriff ist allerdings irreführend, da man Zeit an sich nicht managen kann, sondern nur den eigenen Umgang damit. Insofern ist das Eisenhower-Prinzip ein Instrument der Selbststeuerung.

Alle Aufgaben werden demnach anhand der Kriterien wichtig/unwichtig und dringend/nicht dringend in vier Quadranten verteilt. Alle Aufgaben im Quadrant unwichtig/nicht dringend werden (vorerst) nicht erledigt.
Die Einteilung erfolgt so:

- Die Y-Achse beschreibt die Wichtigkeit einer Aufgabe. Wenn eine Aufgabe oben angesiedelt ist, so ist sie wichtig. Ist sie unten angesiedelt ist sie unwichtig.
- Die X-Achse beschreibt die Dringlichkeit einer Aufgabe. Ist eine Aufgabe rechts angesiedelt, so ist die Aufgabe dringend (eilig). Ist die Aufgabe links angesiedelt, so ist sie nicht dringend.

Es ergeben sich vier Kombinationsmöglichkeiten der Faktoren Wichtigkeit und Dringlichkeit, deren Aufgaben jeweils eine bestimmte Art und Weise der Bearbeitung zugeordnet wird:

Ein großer Vorteil der Methode liegt in ihrer Einfachheit, so dass man sie sich eigentlich nur vor seinem geistigen Auge vorzustellen braucht und alles, was zu erledigen ist, in dieses Koordinatensystem überträgt. Bei der Bewertung der Aufgaben sollte man sich jedoch auch im Klaren darüber sein, dass Andere (z.B. Kollegen, denen man zuarbeitet oder Vorgesetzte) womöglich andere Prioritäten vergeben würden. Insofern sollte man bei der Priorisierung immer den Blick über den eigenen Tellerrand hinaus werfen und sich mit dem Umfeld abstimmen.

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.