Paul Culmsee (http://www.cleverworkarounds.com/) schreibt seit einiger Zeit in seinem Blog über Wicked Problems im Zusammenhang mit SharePoint. Als ich diese Serie das erste mal las, war es für mich ein einziges “JA-SO-IST-ES” Erlebnis. Ich habe mir auch gleich das Buch von Jeff Conklin “Dialogue Mapping – Building a Shared Understanding of Wicked Problems” gekauft. Meistens sind ja diese “Wie-löse-ich-Probleme-Bücher” nur die ersten paar Kapitel lesbar; danach kommen sie gleich wieder ins Regal. Dieses habe ich aber schon fast zu Ende gelesen und bin begeistert.
Ich werde in nächster Zeit immer wieder auf das Thema Wicked Problems, SharePoint und Dialogue Mapping eingehen.
Zunächst was sind Wicked Problems Die Definition von Wicked Problems geht auf den gebürtigen Berliner Horst Rittel (Bild) zurück. 
Dieser hat in den 70er Jahren festgestellt, dass ein linearer Lösungsansatz (Wasserfall-Methode) für die komplexen Zusammenhänge bei Stadtplanungen völlig unzureichend ist. Er leitete daraus Regeln ab, die Wicked Problems kennzeichnen:
Sinngemäß übersetzt:
1. Das Problem ist erst verstanden, wenn eine Lösung gefunden wurde.
2. Wicked Problems haben kein definiertes Ende
3. Es gibt keine richtige oder falsche Lösungen für Wicked Problems, eher bessere, weniger gute oder unzureichende.
4. Jedes Wicked Problem ist einzigartig.
5. Jeder Lösungsversuch kann nur einmal durchgeführt werden. Danach hat sich das Wicked Problem verändert.
6. Wicked Probleme haben keine definierte, alternative Lösung.
Die bekanntesten Wicked Problems sind Themen wie globale Erwärmung oder Finanzkrisen.
Nun würde es nicht sehr für das Produkt SharePoint sprechen, wenn alle oben genannten Regeln auf das Produkt zutreffen würden. Das Wicked Problem in SharePoint Projekten liegt nicht im Produkt an sich, sondern viel mehr am Umfeld, in dem SharePoint eingesetzt wird. Wie bei jedem IT Projekt hat man eine schwer zu überblickende Kombination aus Geschäftsanforderungen, Menschen und Technologien. Was bei SharePoint Projekten erschwerend hinzu kommt, ist die Tatsache, dass viele Projektbeteiligten eine sehr unterschiedliche Vorstellung vom Nutzen von SharePoint haben. Auf Befragungen erhält man doch sehr unterschiedliche Antworten:
Fachbereich: “SharePoint ist die Wunderwaffe, die meine Fachanwendung in Null-Komma-Nix umsetzt.”
IT Leiter: “Durch Konsolidierung verschiedener Anwendungen, kann ich mit SharePoint mein knappes IT-Budget besser ausnutzen”
Entwickler: “SharePoint ist eine auf .NET basierende Plattform, mit der ich die Anforderungen des Fachbereichs in Code umsetzen kann ”
Admin: “SharePoint ist ein Dokumentenmanagementsystem für den Fachbereich, das ich neben den anderen Anwendungen betreibe.“
Projektleiter: “Durch Verwendung der SharePoint Standardfunktionen (Out-of-the-Box) müssen wir weniger entwickeln und können unseren engen Zeitplan einhalten.”
Endanwender: “Kann mir jemand mal dieses SharePoint erklären?”
Kurzum, SharePoint ist ein geflügeltes Wort unter dem jeder etwas anderes versteht. Und genau hier beginnt der Lösungsansatz für Wicked Problems des Herrn Rittel : Wicked Problems werden beherrschbarer, wenn man die menschlichen Beziehungen in den Mittelpunkt stellt und für ein allgemeines Verstehen des Problems sorgt (“Shared Understanding”).
