SharePoint Projekte und Wicked Problems (Teil 2)
Kommentare

Bohrte man aber kurz nach, kam schnell zu Tage, dass alles andere als Einigkeit herrschte, ja, dass sogar sehr unterschiedliche Meinungen zu einem Thema vorhanden waren. SharePoint war dieser diffuse,

Bohrte man aber kurz nach, kam schnell zu Tage, dass alles andere als Einigkeit herrschte, ja, dass sogar sehr unterschiedliche Meinungen zu einem Thema vorhanden waren. SharePoint war dieser diffuse, alles erklärende Begriff, der eine Lösung eines Problems versprach, das man noch nicht verstanden oder erkannt hatte.

In diesen Besprechungen gab es viele solcher Begriffe. In einem Meeting habe ich mir mal den Spaß gemacht, die Nennung bestimmter Schlagworte mitzuzählen. Herausgekommen ist die in Abbildung 1 gezeigte Tag-Cloud.

Abb. 1: Tag-Cloud
Abb. 1: Tag-Cloud

2. Wicked Problems haben kein definiertes Ende: Wir müssen erst eine Lösung finden, um das Problem zu verstehen – wie sollen wir das Ende eines Wicked-Problems vorhersagen können? Das Ende wird sich nur aus den Gegebenheiten wie beschränkten Ressourcen (Geld, Zeit) oder dem Machtwort einer Führungskraft ergeben. Es wird sich nie eine final richtige Lösung ergeben – höchstens eine, die „richtig“ genug ist.

Das terminliche Ende des Prozessportals zu finden, war für alle beteiligten ein schmerzhafter Weg. Denn wie löst man das folgende Dilemma auf: Ich kann das Ende nur planen wenn ich die Lösung kenne; ich kann aber nur eine Lösung finden, wenn ich das Problem verstehe. Wie lange ich brauche, um das Problem zu verstehen, kann ich nicht vorhersagen. Wirklich auflösen kann man es nicht. Man kann sich nur iterativ der Lösung annähern. Beim meinem Prozessportalprojekt haben wir uns nach gewissen Startschwierigkeiten für Scrums agile Projektmethode entschieden. Dadurch war das Ende nur noch durch das beschränkte Budget definiert.

3. Es gibt keine richtige oder falsche Lösung für ein Wicked-Problem, nur eine bessere oder eine schlechtere: Ein Wicked-Problem kann keine objektiv richtige Lösung haben. Es kann nur Lösungen haben, die einen Konsens zu dem Zeitpunkt widerspiegeln, die sich aus den aktuellen sozialen Interaktionen ergeben haben. Im Vergleich miteinander können die Lösungen nur besser oder schlechter sein. Welche Lösung am Ende umgesetzt wird, wird letztlich durch Präferenzen entschieden.

4. Jedes Wicked-Problem ist einzigartig: Die Lösungsfindung wird durch so viele Faktoren beeinflusst, die in ihrem sozialen Gefüge betrachtet werden müssen, dass zwei Wicked Problems nicht miteinander verglichen werden können.

Ich habe schon einige SharePoint-Projekte begleitet. Diese Projekte haben sich oft geähnelt, allein schon deshalb, weil ich Ansätze aus vergangenen Projekten übernommen hatte, die sich als praktikabel herausgestellt hatten. Doch gab es auch immer wieder diese Momente, in denen Fundamentales nicht mehr gültig zu sein scheint: So bin ich im letzten Jahr stark dazu übergegangen, die SharePoint-Oberfläche mit JQuery anzupassen und zu erweitern. Viele gute Gründe sprechen hierfür, und die Tatsache, dass Microsoft in der kommenden SharePoint-2010-Version selbst teilweise mit jQuery arbeitet, bestätigt dieses Vorgehen. Bei einem aktuellen Kunden bin ich jedoch kürzlich vom Stuhl gefallen, als man mir mitteilte, dass fast alle ActiveX-Objekte durch die Sicherheitsrichtlinien nicht im Browser laufen dürfen. Für jQuery bedeutet das, dass keine AJAX-Aufrufe zum Server gemacht werden können und auf jeder Seite eine sehr irritierende Fehlermeldung von Internet Explorer zu sehen ist (XmlHttpDocument ist ein ActiveX-Objekt, für diejenigen, die es ganz genau wissen wollen). Es ist diese Kombination aus Kundeneigenheiten und technologischer Komplexität, die dazu führt, dass kein größeres (SharePoint-)Projekt mit dem anderen vergleichbar ist.

Das ist die größte Gemeinheit. Man kann nicht wissen, wie das Prozessportal zu implementieren ist, wenn man nicht anfängt, es umzusetzen und zu betreiben. Aber jeder Versuch ist teuer und hat unendlich viele Konsequenzen, die wiederum neue Wicked Problems auslösen. Rittel spricht hier von einer „One-Shot-Operation“: Nur wenn man die Autobahn durch die Stadt gebaut hat, weiß man, wie sich die Stadt verändert haben wird – oder analog bezogen auf SharePoint-Projekte: Nur wenn ich das Portal veröffentlicht habe, werde ich wissen, ob die Anwender es akzeptieren. Ein zweiter Versuch, der die Akzeptanz verbessern soll, wird ungleich schwieriger sein, da sich viele schon eine Meinung gebildet haben werden.

Ein Webpart, das Daten aus einer Datenbank anzeigt, wird wenig Spielraum bei der Umsetzung zulassen. Das Prozessportal, das sich aus Workflows, Masken, Datenbankzugriffen, Dokumenten, Berechtigungen und vielen anderen Bestandteilen zusammensetzt und auch noch in die Arbeitsweise der Mitarbeiter eingebettet sein soll, hat unendlich viele Lösungsmöglichkeiten. Man wird keine Lösung finden, die genauso „gut“ ist, wie eine andere gegebene Lösung.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -