Gemeinheiten elegant bändigen

SharePoint Projekte und Wicked Problems
Kommentare

Wicked {engl, adjectiv}: abgefahren [ugs.] ,böse, cool [sl.], gefährlich, geil [sl.], schelmisch, schlimm, stark [sl.], verrucht [form.].

Am Anfang erschien das neue SharePoint-Projekt unproblematisch. Klar, wir mussten einiges abstimmen, konfigurieren und umsetzen. Und die Konzepte, die die SharePoint-Arbeitsgruppe erstellt hatte, waren auch in sich schlüssig. Doch irgendwie gab es immer wieder Teilthemen, die wir nicht wirklich in den Griff bekamen. Wir hatten das Gefühl, dass das Projekt aus dem Ruder laufen würde. Themen, die ursprünglich nichts miteinander zu tun hatten, führten zu Eskalationsmeetings, die das gesamte Projekt in Frage stellten. Meetings, in denen erst einmal lange versucht wurde, das Problem zu formulieren und man trotz eines erzielten Kompromisses den Raum mit dem flauen Gefühl verließ, dass man einer Lösung nicht wirklich näher gekommen war. Das ist einer der typischen Symptome eines Wicked-Problems.

Wicked Problems sind Probleme, die sich aufgrund ihrer komplexen Natur nicht mit herkömmlichen Projektmethoden beherrschen lassen und schon per definitionem nicht eindeutig lösbar sind. Mit Dialogue Mapping gibt es eine Methode, die eine der Kernursachen von Wicked Problems im Visier hat: das mangelnde gemeinsame Verständnis.

Im ersten Teil dieses Artikels werden zuerst Wicked Problems betrachten und vor allem auf die Kriterien eingehen, durch die man ein Wicked-Problem erkennen kann. Der zweite Teil untersucht, wie mit Dialogue Mapping mit wenigen Hilfsmitteln und Veränderungen ein gemeinsames Verständnis aufgebaut und somit komplexen Projekten etwas von ihrer Schärfe genommen werden kann.

Zahme Probleme – Wicked-Probleme

Wicked Problems sind keine neue Erfindung. Bereits 1973 veröffentlichten Horst Rittel und Melvin Webber, zu der Zeit beide Stadtplaner an der University of Berkley, einen Artikel mit dem Titel Dilemmas in a General Theory of Planning . Während ihrer Arbeit als Stadtplaner waren beide zu der Erkenntnis gekommen, dass herkömmliche Planungsmethoden völlig unzureichend für bestimmte Arten von Problemen sind. Diese Wicked Problems und deren Eigenschaften sind in diesem Artikel erstmalig definiert.

Die Wasserfallmethodik ist fest in unserem Denken verankert. Zuerst sammeln wir Daten, dann analysieren wir diese, leiten eine Lösung ab und setzen diese schließlich um. Ein einfaches Webpart nach dieser Methodik zu entwickeln, wäre sicherlich zielführend. Alle Beteiligten hätten eine gute Vorstellung, vom dem, was das Webpart leisten können müsste. Sie könnten eine klare Lösung formulieren und diese auch mit Erfolg umsetzen. Das wäre ein zahmes Problem oder ein Tame-Problem, wie Rittel und Webber es bezeichnen. Das zahme Problem ist hauptsächlich dadurch gekennzeichnet, dass es eine eindeutige Lösung zu einer Problemstellung gibt. Im Umkehrschluss könnte man nun ein Wicked-Problem einfach dadurch definieren, dass es für diese keine eindeutige Lösung gibt. Das stimmt auch soweit. Es gibt jedoch noch sechs weitere Kriterien, an denen man Wicked Problems erkennt (in ihrem Artikel erwähnen Rittel und Webber zehn Kriterien, Jeff Conklin [Conklin, Jeff: „Dialogue Mapping: Building Shared Understanding of Wicked Problems“, Wiley 2005] generalisierte das Konzept für Themengebiete außerhalb der Stadtplanung):

  • Das Problem ist erst verstanden, wenn eine Lösung gefunden wurde.
  • Wicked-Probleme haben kein definiertes Ende.
  • Es gibt keine richtige oder falsche Lösung für ein Wicked-Problem, nur eine bessere oder eine schlechtere.
  • Jedes Wicked-Problem ist einzigartig.
  • Jeder Lösungsversuch kann nur einmal durchgeführt werden. Danach hat sich das Wicked-Problem verändert.
  • Wicked-Probleme haben keine definierte, alternative Lösung.

Folgenden werde ich diese Kriterien näher beleuchten.

1. Das Problem ist erst verstanden, wenn eine Lösung gefunden wurde: Einer meiner letzten Kundenprojekte war bei einem global agierenden Beratungsunternehmen, das in den letzten Jahren weltweit einige Unternehmen hinzugekauft hatte. Man verlangte nun von uns als technisches Team, ein Prozessportal in SharePoint umzusetzen, das den gesamten Prozess des Beratereinsatzes von der Angebotserstellung bis zur Rechnungsstellung begleitet. Bezeichnend für das Projekt war, dass wir nie eine finale Version der Spezifikationen erhalten hatten. Da sich der Auftraggeber ehrgeizige terminliche Ziele gesetzt hatte, verlangte er, dass wir die Umsetzung bereits mit den Entwürfen beginnen sollten. Hatten wir Rückfragen oder wollten wir Punkte konkretisieren, führte das nur zu langwierigen Diskussionen und oft zu Änderungen in der Spezifikation. Auffällig war, wie oft in diesen Diskussionen das Wort „SharePoint“ fiel – und zwar nicht von Techies, sondern von den Mitarbeitern der Fachbereiche. Diese hatten nun wirklich kein tiefergehendes Verständnis der Technologie, sondern nutzten das Wort als Platzhalter für das eigene Verständnis. Wenn nämlich ein Repräsentant des Bereichs aus den USA sagte, „mit SharePoint können wir out of the box die Daten erfassen lassen und anschließend Berichte erstellen“, dann konnte er sogar mit der Zustimmung der Kollegen aus Frankreich rechnen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -