Risiko und Wahrnehmung III (Die geprägten Schatten)

14. Januar 2009

Im letzten Blogeintrag habe ich die Risikostruktur als Ausdruck der Schattenseite einer Organisation beschrieben, vergleichbar mit den Untiefen des Unterbewusstseins einer Person.

Ein – auf den ersten Blick – gewagter Vergleich, insbesondere wenn man die IT-Brille aufsetzt und sich vorstellt, dass die Erzeugung von Software irgendwas mit Unterbewusstsein zu tun haben soll… Aber wer von uns IT’lern kennt das nicht: man kommt in ein Projekt, und man bekommt schon über die Diskussionskultur (was wird wirklich diskutiert, welche Themen sind nicht diskussionsfähig, was wird ignoriert) mit „wie der Hase läuft“. Und ob das Projekt eine Chance auf Erfolg hat. Und dieser „Projektstil“ bleibt meistens erhalten, auch wenn Leute kommen oder gehen. Es ist wie eine Art Mantra – „so verhalten wir uns, und nicht anders“ – dass von der Organisation als Ganzes geprägt und aufrecht erhalten wird.

Dieses Verhalten hat natürlich überhaupt nichts mit Gruppendynamik oder Organisationspsychologie zu tun 😉

So, zurück zum Thema: Risiken sind Ausdruck der Schatten einer Organisation…

Einer meiner ersten Gedanken nach dieser Assoziation war: „hoho, und IT-Projekte giessen diese Schatten in digitale Form…“. Diesem Gedanken will ich heute nachgehen…

Ist das so?

Der übliche Verlauf ist: die Fachseite möchte ein System anpassen oder ein neues System gebaut bekommen. Die IT-Seite wird involviert, es werden Anforderungen formuliert und in Diskussion verfeinert. Es werden verschiedene Aufwandsschätzungen durchgeführt und Budgets organisiert. Es werden technische Konzepte geschrieben und in Software umgesetzt. Die Qualitätssicherung startet (Tests werden formuliert und durchgeführt), es wird eine Produktionsumgebung geschaffen, auf die die Endanwender zugreifen werden. Letztlich wird die Software final abgenommen und in Produktion genommen.

Soweit, so einfach. Nur funktioniert das leider in der Praxis nicht ganz so einfach. Die Anforderungen ändern sich, unerwartete technische Probleme verursachen Mehraufwand, die Qualitätssicherung findet immer wieder neue Fehler in der Software, der Produktionstermin wird immer wieder verschoben…

Wenn ich so darüber nachdenke sehe ich tatsächlich zwei Risikostrukturen: die Risikostruktur der Fachseite, und die Risikostruktur des IT-Projekts.

Die Risikostruktur der Fachseite umfasst alle fachlichen Risiken – das sind alle fachlichen „Risiken“, die in der einen oder anderen Form in der zu erstellenden Software zu berücksichtigen sind. Anders formuliert: es sind mindestens alle Anforderungen, die die Fachseite vergessen hat zu formulieren, plus sich aus dem Business heraus ergebende Risiken (Geschäftspolitik wird kurzfristig geändert).

Die Fachseite hat somit eine eigene, für sie spezifische „Schattenseite“. Und alles was die Fachseite vergisst, verdrängt, nicht beachtet wird über die (nicht) formulierten Anforderungen auch schön brav von der IT in digitales Material „gegossen“. Eine fertige Software hat also zumindesten zu einem gewissen Grad einen „Imprint“ des Unterbewusstseins der Fachseite…

Die IT-Risikostruktur und die Schatten werden zum gewissen Teil ebenfalls in digitales Material verewigt – über nicht richtig oder vollständig realisierte Funktionalitäten, technisch wackelige Lösungen oder ignorierte Tests.

Was mir gerade in diesem Moment auffällt – und jetzt spreche ich als Entwickler: als (motivierter) Entwickler hat man fast immer zwangsläufig ein schlechtes Gewissen. Man hätte hier und dort immer noch besser sein können, die Funktion X ist nicht generisch genug, die Tabelle Y ist eigentlich eine Krücke, und die Fehlerbehandlung an Stelle Z wird in die Hose gehen weil sie nicht ganz zum Rest passt.

Anders ausgedrückt: jede Software digitalisiert das schlechte Gewissen der beteiligten Entwickler – für die „Ewigkeit“. *ein tragisch-komischer Gedanke*. Ich stelle mir vor wie die Softwarepakete dieser Welt, in den Banken, Versicherungen, Telco-Unternehmen alle im millisekundentakt im schlechten Gewissen schwingen… „hätten wir doch… wir sollten das noch ändern… keine Zeit… die Lösung ist aber gar nicht gut… wenn das die Fachseite wüsste… wir haben gesagt das das nicht funktioniert…“

Ja, auch die Schatten der (Projekt)Organisation werden im Endergebnis verewigt. Sie vermischen sich mit den Schatten der Fachseite, und das Endergebnis ist ein Stück Software: ein digitales Mahnmal von Licht („Hoffnung“: unsere IT baut uns eine neue Software die unser Leben leichter/besser macht) und Schatten (wieso haben die/wir nicht daran gedacht das…)…

*schmunzel*


Risiko und Wahrnehmung II (Die Schattenseite)

12. Januar 2009

Im vorangegangenen Blogeintrag habe ich über die Wahrnehmung von Risiken im Zusammenspiel mit dem Risikomanagement philosophiert. Das will ich jetzt fortsetzen…

Mich beschäftigt weiterhin der Aspekt der (Risiko-)Wahrnehmung im Zusammenspiel mit dem Verhalten der Organisation.

Zunächst einmal gilt es festzuhalten das es zwei Arten von Risiken gibt: diejenigen Risiken welche wahrgenommen werden, und diejenigen die verdrängt bzw. ignoriert werden.

Nebengedanke: nach Murphys Gesetz sind diejenigen Risiken, die nicht wahrgenommen werden, diejenigen die einem im unpassensten Moment in den „A…“ beissen. Wenn man also als Projektleiter Risikomanagement ernst meint, dann sollte man mit Sorgenfalten auf die leeren Stellen auf der Risikoliste starren… 😉

Spannend ist es mich Sicherheit heraus zu finden, warum eine Organisation mal die eine Risikoklasse, mal die andere Risikoklasse ignoriert. Diese Auswahl dürfte eine Mischung von schlechten Erfahrungen (das passiert uns nicht wieder), guten Erfahrungen (unsere Kunden könnten uns zwar hier ärgern, das passiert aber aus guten Gründen nie) sowie dem grundsätzlichen Unternehmenskontext (Datenschutz hat bei uns höchste Priorität) sein.

Der Unternehmenskontext wirkt hier umso stärker, umso enger die Risiken mit den Zielvereinbarungen der jeweiligen Management-Ebene verknüpft sind.

Das Risikomanagement als einen Einstieg in eine systemische Analyse zu verwenden dürfte einiges an Erkenntnis über die IT-Organisation als Ganzes liefern, über dem Umgang mit Erfolg und Misserfolg etc.

Der Umgang mit Risiken zeigt in meinen Augen den Reifegrad der Organisation. Risiken sind schlecht, „böse“, unangenehm, lästig. Für das Nennen und Verwalten von Risiken gibt es keine Bonuspunkte – im Gegenteil. Der Projektleiter wird sich „bedanken“ das er ein neues Problem benannt bekommt, denn das Verhindern von Risiken oder die Minimierung von Schäden kostet Zeit, Nerven, Aufwand, bringt einem in der Sache oberflächlich gesehen nicht voran.

Wenn ich so darüber nachdenke: Risiken kann man sich als die „Schattenseite“ der (Projekt)Organisation vorstellen, wobei wahrgenommene Risiken die bewusst eingestandenen Schwächen, und die nicht wahrgenommenen Risiken die dunklen tiefen Schatten des Projekts darstellen. Ähnlich wie in der Psyche eines Menschen: die dunklen Stellen, das Verdrängte, das Vergessene, das Übersehene. In den IT-Sprachgebrauch übersetzt: es sind die nur mit Annahmen „gelösten“ Probleme, die wegdefinierten Anforderungen, die ignorierten Erwartungshaltungen, die wegdiskutierten technischen Risiken, die vergessenen ToDos, die schlecht umgesetzten Softwareroutinen…

Wobei die sich in der Wahrnehmung befindlichen Probleme und Risiken schon aus Selbstschutz berücksichtigt werden. Naja: auch nicht immer – man hat im Projektverlauf nicht immer die Kapazität/Resourcen – noch nicht mal für die benannten Risiken…

Für mich ist eine Organisation „erwachsen“, wenn sie verantwortlich mit Risiken umgehen kann. Das bedeutet nicht, dass alle Risiken immer benannt/behandelt werden müssen – es bedeutet, dass die Organisation sich über den Umgang mit Risiken bewusst ist, und bewusst handelt. Risikoklassen zu ignorieren kann je nach Kontext schlichtweg sinnvoll sein – wenn es bewusst geschieht.

Genug philosophiert für heute… da ist aber mit Sicherheit noch mehr…


Risiko und Wahrnehmung I (Die blinden Flecken)

10. Januar 2009

Beim Abarbeiten meiner alten Arbeitsmails aus den vergangenen Jahren ist mir eine meiner „typischen“ Mails in die Hände gefallen. Es ging um die Vorbereitung eines Angebotsdokuments, und ich habe auf gewisse kommerzielle Risiken hingewiesen die sich aus Formulierungen ergeben könnten – Formulierungen, die nicht in meinem Arbeitsgebiet lagen.

Ich kann mich noch gut erinnern wie meine „Warnung das ist ein Risiko“-Mails etwas verwundert zur Kenntnis genommen wurde. Ich war der einzige der sich über derartige Risiken Gedanken gemacht hat, was wohl vor allem auch daran lag das ich ein „neuer Externer“ war. Als ein solcher war ich noch nicht an die organisationsüblichen „Filter“ angepasst.

Die Projektleitung hat meiner Risiko-Einschätzung nicht widersprochen – das Risiko war echt. Es war einfach nur so, dass derartige Risiken einfach nicht beachtet wurden – es war ein bisschen so „ich sehe das Risiko nicht, also existiert es auch nicht“.

Das Paradoxe daran war: innerhalb dieses Projekts gab es offiziell einen Risikomanagement-Prozess. Man hat mein Risiko aufgenommen, aber dann im Rahmen des Prozesses „verhungern“ lassen. Keine Absicherungmaßnahmen, keine Risikominderungsmaßnahmen… Es war als hätte man die fachliche Richtigkeit (und das damit verbundene kommerzielle Risiko) zur Kenntnis genommen, aber dennoch… es war als hätte sich die (soziale) Organisation dazu entschieden derartige Risiken einfach zu ignorieren.

In diesem Verhalten sind – systemisch gesehen – einige Erkenntnisperlen versteckt.

Zunächst einmal kann man das Verhalten des Systems als Schutz verstehen. Die Projektorganisation hat sich (unbewusst) entschlossen eine bestimmte Risikoklasse zu ignorieren – vielleicht weil man nicht wusste, wie man derartige Risiken richtig handelt, vielleicht weil man mit der Nennung derartiger Risiken ggf. politische Konflikte versachen könnte, vielleicht weil man einfach nicht genügen Kapazität hat sich „auch noch um sowas kümmern zu können“.

Das war mein Hinweis auf das entdeckte Risiko natürlich auch ein Hinweis darauf, dass eine komplette Klasse von Risiken nicht beachtet werden. Die Organisation hat an dieser Stelle nur die Wahl die Tore zu öffnen und alle relevanten Risiken zu benennen (mit unabsehbaren Folgen), oder mein Risiko zu einem „Einzelgänger“ zu machen. Sprich: da man’s nicht verschweigen kann, lässt man den Einzelgänger „verhungern“ in dem sich keiner drum kümmert. Für mich hatte das – zum Glück – keine negativen Folgen, d.h. ich wurde für diesen „Frevel“ weder auf der sozialen Ebene noch formal „bestraft“.

Die (Projekt-)Organisation hat damit aber eine Art Wahrnehmungslücke „produziert“, einen blinden Fleck. Da derartige – oder ähnlich wahrgenommene – Risiken fast schon reflexartig ignoriert werden, tut sich im Risikomanagement natürlich ein grosses Loch auf.

Mein „Intervention“ – die Nennung eines derartigen Risiko – und der Umgang damit (Ignorieren) hat diesen blinden Fleck noch verstärkt. Einem Beobachter im Projekt wird damit deutlich: aha, derartige Risiken werden höchstens in die Liste aufgenommen, aber sonst kümmert sich keiner. Der Aufwand lohnt also nicht… Was wie eine Belohnung für die Handlungsoption „ignorieren“ wirkt.

Wenn man etwas über derartige blinden Flecken eines Projekts wissen will, so müsste man nur folgendes machen: eine Liste aller potentiell möglichen Risikoklassen erstellen (= die üblichen Verdächtigen), und mit der Liste der realen Risiken im Risikomanagement abgleichen. Man kann statistisch davon ausgehen, dass es von jeder Risikoklasse wenigstens ein paar (ggf. auch nur kleine) Risiken gibt. Fehlt im Risikomanagement eine Risikoklasse komplett, dann hat man einen guten Anhaltspunkt für einen blinden Fleck in der Organisationswahrnehmung.

Als Sicht des Risikomanagements müsste der erste Eintrag immer lauten: „Das Risiko, dass Risiken übersehen werden“ 🙂

Im nächsten Blog-Eintrag werde ich das Thema nochmal aufgreifen – da ist noch mehr zu finden…


Die IT’ler und ihre Religionen…

3. Januar 2009

Und da sage noch einer die IT hätte nichts mit Spiritualität am Hut: Programmiersprachen als Religionen (englisch)… *schmunzel*

Ich war früher mal (mehr oder weniger nicht ganz aus freiwilligen Gründen) ein VB’ler, bin lange Zeit Pythoniac gewesen und wandele seit kurzem auf Java’s Pfaden. Was sagt das über mich und meine Entwicklung nun aus?

Ich habe mich Satan (VB) entzogen, dem gesunden Menschenverstand (Python) zugewendet und bin nun in die Fänge einer strengen Religion (Java) geraten… *grosser*schmunzler*

Einem Nicht-IT’ler mag der Vergleich von Technologien und Religionen sehr komisch oder vielleicht auch anmassend vorkommen. Aus meiner eigenen Historie heraus weiss ich aber, dass manche IT’ler bei bestimmten Themen absolut keinen Spaß mehr verstehen. Zu solchen Themen zählen Programmiersprachen, Entwicklungsumgebungen sowie Datenbanken. Wobei Datenbanken inzwischen in den Hintergrund getreten sind, und durch Webserver-Technologien ersetzt wurden – glaube ich…

Über diese Themen wird im Internet mal nett, mal heftig und sogar auch mit persönlichen Angriffen diskutiert. Das läuft dann unter dem Begriff „flamewar„, und Beispiele sind hier und hier zu finden.

Ein Zitat dazu: This is a topic that many programmers apparently feel “more passionate about than their wives”. Das Zitat stammt übrigens aus einem Blogeintrag welches ganz gut erklärt, wie diese Flamewars gestartet werden, wie sie verlaufen und es wird auch zitiert wie persönlich und unfair diese flamewars verlaufen können…

Es ist ja nicht so als gäbe es in der Systemik nicht auch „Glaubensanhänger“ – ich sage nur „pro Hellinger“ und „contra Hellinger“…

Wenn man ein Organisationssystem mit IT-Beteiligung betrachtet sollte man diesen Aspekt im Auge behalten. Es kann sowohl sein das die gesamte IT-Organisation in sich dogmatisch ist („Java ist die beste Sprache der Welt“), es kann aber auch sein das die IT-Abteilungen in Fraktionen unterteilt sind, die in einem negativem Bezug zueinander stehen. Oftmals gibt es Bestandssysteme die in einer älteren Sprache (C++) geschrieben sind, neuere System für das Internet sind in „aktuellen“ oder „trendigen“ Sprachen geschrieben (Java) . Die Bestandssysteme fühlen sich – oder werden defacto – von den neueren Systemen „bedroht“.

Diese Dogmen kann man IT-Aussenstehenden entweder nicht erklären oder man will es auch nicht erklären („das ist unser Hoheitsgebiet, warum X besser als Y ist müssen sie schon uns überlassen“). Das es diese Fraktionen gibt – und auch auf welcher Basis diese Fraktionen entstanden sind – ist für einen IT-Laien nicht erkenn- oder verstehbar.

Man wundert sich nur warum bestimmte, ganz gut klingende Lösungsvorschläge einer Fraktion von einer andere Fraktion verteufelt und strikt abgelehnt werden. Ich selbst erlebe es im Tagesgeschäft als IT-Architekt das z.T. Projekte einer Fraktion von anderen Fraktionen aktiv unterlaufen oder torpediert werden, nur um zu verhindern das die andere Fraktion Erfolg hat und ggf. mehr Macht bekommt. Das macht man dann nicht offen, sondern schön subtil. Da werden die Aufwandsschätzungen plötzlich sehr hoch, das werden Interfaces komplexer gemacht als notwendig, da werden Anforderungen an die Leistungsfähigkeit der neuen Komponente plötzlich ganz hoch geschraubt – und alles mit guten Gründen belegt und bewiesen…

Sollte man in einer Aufstellung das Gefühl bekommen das noch nicht alles sichtbar geworden ist – es könnte ein solches Dogma sein, welches dann symbolisch für ein kompletten Werte- und Glaubenskontext steht. An diesem Kontext hängen dann auch Visionen, Hoffnungen, Sorgen oder Ängste.

„von einer andere Fraktion verteufelt und strikt abgelehnt werden“…

Mit dem Begriff „verteufeln“ sind wir genau wieder beim Einstiegsthema angekommen… 🙂


Back from Madeira

28. Oktober 2008

Ich war für 9 Tage mal wieder auf meiner Lieblingsinsel Madeira und habe das Angenehme mit dem Beruflichen verbunden.

Jetzt bin ich wieder in Köln und muss mich auf Raumsuche für das Institut machen. Sobald sich ein passender Raum gefunden hat wird der nächste Forschungsabend kurzfristig organisiert, versprochen!

Andrew


Köln, ich komme :-)

29. September 2008

So, das gröbste ist geschafft, ich bin sowohl privat als auch beruflich jetzt in Köln beheimatet.

Noch Stapeln sich die Kisten, und das übliche organisatorische Schaulaufen (Ummelden, Auto, Adressen etc.) steht noch an, aber ich bin soweit „up and running“.

Die Arbeit im Insitut wird sicherlich noch 1-2 Woche ruhen müssen, aber dann gehts mit neuer Kraft weiter.

Die neue Adresse: Arndtstr. 10, 50676 Köln

Andrew Smart


Komplexe und komplizierte Aufgaben

26. Juli 2008

Ich habe mit wachsender Neugier das Buch „Denkwerkzeuge der Höchstleister“ gelesen. Ich finde die Thesen in diesem Buch sehr passend.

Den Abschnitt „Im Kontext hoher Dynamik ist Können wichtiger als Wissen“ treffen die Autoren die Unterscheidung zwischen Wissen und Können, und ordnen diese beiden Fähigkeiten jeweils den Problemklassen „Komplizierte Aufgaben“ und „Komplexe Aufgaben“ zu.

Mit Wissen kann man komplizierte Aufgaben lösen, aber nur mit Können kann man komplexe Aufgaben lösen. Die Autoren vergleichen das mit einer Fußballmannschaft. Die Logistik einer Fußballmannschaft ist kompliziert, aber mit genügend Wissen über die Zusammenhänge lösbar. Die Durchführung des Spiel selbst ist komplex (weil hochdynamisch) und mit theoretischem Wissen über das Fußballspiel eben nicht lösbar. Dafür muß man es können.

Diese Unterscheidung passt hervorragend in die IT. Es wimmelt nur so von komplizierten und komplexen Aufgaben, und manchmal ist der Erfolg dadurch determiniert zuerst – und vor allem – die richtige Einordnung zu finden. Können wir diese Aufgaben mit Knowhow lösen, oder bedarf es eines Könners?

Die IT ist per se sehr wissenslastig. Was ich mir schon alles an Bibliotheken, Betriebssystemen, Programmiersprachen, Datenbanken, Softwarepaketen und Entwicklungsumgebungen „reingezogen“ habe geht auf keine Kuhaut. In der IT zu arbeiten bedeutet lebenslanges, kontinuierliches Lernen.

Dadurch gilt in der IT oft die Ableitung: Wissen = Können. Oder anders ausgedrückt: ohne gründliches technisches Wissen kann auch ein Könner nicht wirklich gut arbeiten.

Das ist natürlich prinzipiell richtig, aber nur dann wenn es sich um ein komplizierte Aufgabe handelt. Bei den komplexen Aufgaben muß man schon genauer hinschauen. Sobald die Aufgabe z. B. sehr kommunikationslastig ist (Mensch-Mensch-Kommunikation um genau zu sein 😉 wird der Anteil des „Könnens“ viel stärker zum Erfolg beitragen als das Wissen.

Aber auch manche scheinbar wissenslastige Jobs sind im Kern komplex. Nehmen wir einmal das Thema „Datenbank-Tuning„. Ist das kompliziert oder komplex?

Erste Antwort eines Managers: ich will einen Spezialisten für die Datenbank X – und zwar für die Version 10.2.1 – weil nur er weiß die vielen verschiedenen Tuning-Optionen der Software. Doch nur das Wissen über die Konfigurationsoptionen macht keinen guten DB-Tuner. Das Zusammenspiel zwischen Hardware, Betriebssystem, Datenbank-Software und der Anwendungssoftware ist hochdynamisch und komplex. Man braucht einen Könner – und dabei ist die konkrete Version der Datenbank eher nebensächlich.

*grübel* Es wäre interessant mal eine Abbildung der komplexen wie komplizierten Arbeitsgebiete und Themen in der IT zu erstellen…

Die Idee mit Aufstellungen in der IT zu arbeiten ist übrigens der Versuch den komplexen Problemen beizukommen. Eben da wo das Wissen über Prozesse, Methoden und Technologien nicht mehr weiterhilft. Wenn es also nicht nützt 10 Büchern (Tom DeMarco: Bärentango, Der Termin, Der Mythos Mannmonat etc) über das IT-Management gelesen zu haben. 😉

Andrew Smart