SharePoint Projekte und Wicked Problems (Teil 3)
Kommentare

Umgang mit Wicked Problems

Wicked Problems sind wie kleine Kinder – sie können unglaublich gemein sein. Wie geht man mit kleinen gemeinen Kindern um? Man kann sie bestrafen und die Schuld auf ihre

Umgang mit Wicked Problems

Wicked Problems sind wie kleine Kinder – sie können unglaublich gemein sein. Wie geht man mit kleinen gemeinen Kindern um? Man kann sie bestrafen und die Schuld auf ihre schlechten Gene schieben („Das können nicht meine Gene sein!“). Oder man kann sich geduldig mit ihnen auseinandersetzen. Ähnlich verhält es sich mit unseren Problemen im (SharePoint-)Projektalltag. Wir können unsere Nachbarabteilung durch Streuung gezielter Unwahrheiten ausbremsen und die Schuld auf ihre generelle Unfähigkeit schieben. Diese werden bestimmt mit einem lustigen politischen Gegenangriff reagieren und unbeabsichtigt eine dritte Partei mit in den Schlamassel ziehen. Schließlich ist es ja im Sinne des Unternehmens, politische Grabenkämpfe zu führen (Ironiehinweis). Oder wir können lernen, mit Wicked Problems umzugehen.

Wir haben schon von agilen Projektmethoden wie Scrum gehört, die viele Gemeinheiten bändigen und den Weg für ein beherrschbares Projekt ebnen. Scrum geht wunderbar auf die Unplanbarkeit und Wechselhaftigkeit von Wicked Problems ein. Eine Kernursache von Wicked Problems behandelt es aber nur bedingt: die soziale Komplexität des Umfelds, in dem sich alles abspielt. Diese wollen wir im Folgenden etwas näher betrachten.

Soziale Komplexität

SharePoint-Entwickler bringen traditionsgemäß wenig Verständnis für SharePoint-Administratoren auf. In Ihren Augen sind die Admins nur die Partymuffel, die nichts anderes im Sinn haben, als SharePoint so herunter zu konfigurieren, dass das System für den Endbenutzer keinen Mehrwert mehr bieten kann. Umgekehrt sind die SharePoint-Entwickler aus Sicht der Administratoren rückgratlose Wesen, die jedem Wunsch der Fachbereiche nachgeben, um unwartbare Anwendungen zu produzieren. Zwischen Mitarbeiter unterschiedlicher Fachbereiche herrschen ähnlich ausgeprägte Vorurteile, die zwar oft humorvoll gelebt werden, jedoch ihren Weg in manch eine Entscheidung finden. Betrachtet man Tabelle 1, in der ich etwas unstrukturiert die Rollen des Prozessportalprojekts aufgelistet habe, dann wird schnell klar, dass es sehr viele Rollen im Projekt gab.

SharePoint-Entwickler SharePoint-Administrator IT-Administrator IT-Leiter Betrieb Support Fachbereichsleiter D Fachbereichsmitarbeiter D Fachbereichsleiter US Fachbereichsmitarbeiter US Fachbereichsleiter F Fachbereichsmitarbeiter F Und noch viele mehr Projektmanager Businessanalyst Architekt Technischer Projektleiter

Diese Interessengruppen verfolgten unterschiedliche, teilweise fast gegenläufige Ziele. Sie lebten unterschiedliche Kulturen (deutsche Genauigkeit versus amerikanische Effizienz) und sprachen sogar unterschiedliche Sprachen. Auch wenn wir uns alle auf die Projektsprache Englisch geeinigt hatten, hieß das noch lange nicht, dass wir dasselbe Verständnis der Aufgabenstellung hatten.

Eine der Gründe, warum sich mein Kunde für das SharePoint als Prozessportal entschieden hatte, war die gute Office-Integration von SharePoint. Insbesondere die Integration des SharePoint-Kalenders hatte es ihm angetan. Im Laufe eines Meetings, in dem es um die Kalender ging, redete er von Kalendersynchronisation. Ich befürchte gleich, dass er eigentlich etwas völlig anderes wollte, wie das was ihm SharePoint bieten konnte, und beschloss ihm detailliert die Kalenderintegration vorzuführen. Er war natürlich sauer, als er merkte, dass er „nur“ SharePoint-Kalender bei sich in Outlook einblenden und nicht auch seine sämtlichen privaten Termine auf wundersame Weise ins Portal synchronisieren konnte. Man könnte jetzt Microsoft Sales arglistige Täuschung vorwerfen, doch betrachtet man die Situation genauer, sieht man, dass beide Seiten einfach ein unterschiedliches Verständnis der Problematik hatten.

Für meinen Kunden bedeutete Integration eben auch Synchronisation. Genau an diesem Verständnis füreinander setzen Ritter und noch weiter Conklin an: „Wir können viel mehr erreichen, trotz dieser schwierigen Bedingungen, wenn wir lernen ein gemeinsames Verständnis des Problems aufzubauen und eine gemeinsame Bekenntnis zu den Lösungen zu leben.“

Gemeinsames Verständnis und gemeinsames Bekenntnis – das klingt doch nach Wollpullover, Fencheltee und fremde Menschen umarmen, nach „Du, ich verstehe dich“ – ein bisschen was davon ist es auch, aber nur der Teil mit dem Verstehen. Wer mal angefangen hat, Projekte mit IBIS und Dialogue Mapping zu begleiten, der wird Besprechungen mit einem wesentlich besseren Gefühl verlassen und hoffentlich früher realisieren, dass der Kalender weniger kann als erhofft.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -