Mit jedem Perspektivenwechsel geht die Chance einher, im Vertrauten Neues zu entdecken.

Markus Mirwald

Vor mehr als sieben Jahren, es war ein Donnerstag, da hatte ich frei. Die Kindertagesstätte meines damals zweijährigen Sohnes hatte geschlossen und wir wollten den Tag gemeinsam verbringen. Am Ende machten wir das auch, aber anders als ursprünglich geplant. Um acht Uhr klingelte mein Telefon. Am anderen Ende war die Projektleiterin eines Projekts, an dem ich gerade mitarbeitete. Sie sagte mir, dass sich das Steering Committee heute treffen würde und ich teilnehmen müsse. Ich erklärte ihr, dass ich frei habe und meinen Sohn hüte. Auf den Vorschlag, sie solle meinen Chef einladen, erwiderte sie: «Mit deinem Chef habe ich gerade telefoniert, er sagte mir, ich soll mich bei dir melden.» «Ok» erwiederte ich «wenn ich teilnehmen soll, muss ich meinen zweijährigen Sohn mitbringen, denn ich habe heute niemanden, der den Hütedienst übernehmen kann.»

Du kannst dir sicher vorstellen was los ist, wenn es bei einem Anruf um ein Meeting mit dem Steering Committee geht, etwas ist eskaliert. Da war sie nun also die Worklife-Balance von der immer alle sprechen. Mein Sohn und ich machten uns auf den Weg.

Beim Kunden angekommen begann das Meeting, aus den Gesichtern verschwand der ernste Ausdruck als mein Sohn den Raum betrat. Er schaffte etwas, was ich in so einer kurzen Zeit nicht erreicht hätte. Er nahm dem Meeting mit seiner Anwesenheit die emotionale Anspannung. So konnten wir die Probleme sachlich angehen. Das ist die Grundlage des S.C.O.R.E Modells von R. Dilts.

S.C.O.R.E steht für Symptome, Cause, Outcome, Resource und Effect.

Diese Schablone lässt sich für Sachkonflikte anwenden, nur für Sachkonflikte! Im Coaching wird dieses Modell gelegentlich auch zur Auftragsklärung genutzt. Wenn ein Beziehungskonflikt mitschwingt, dann «sollte» dieser zuerst gelöst werden. Wenn du jetzt denkst: «Wäre ein schönes Vorgehen, aber die Realität…» – ja, auch das kenne ich gut. Ich hatte letzten Monat ein Mittagessen vereinbart, die Person verspätete sich aufgrund eines Steering Committee Meetings. Es spielten Beziehungskonflikte mit rein, die einen Lösungsansatz aufgrund von Überreaktionen hinauszögerte. Das Muster ist meist ähnlich wie in meiner Beobachtung hier. Aber kommen wir zurück zum Meeting, das mehr als sieben Jahre zurückliegt.

Symptome

Beim Symptom geht es zuerst einmal darum, einen Überblick zu gewinnen, wo der Schuh drückt. Dabei können auch Fragestellungen hilfreich sein wie:

• Was genau stört?
• Wie ist der Stand der Dinge?
• Wie drückt sich der Konflikt aus?

In solchen Situationen ist es bereits eine Herausforderung, die Symptome von den Ursachen zu trennen.

In meinen Fall war das Symptom, dass die einzelnen Lösungen auf Ebene der Integration nicht stabil miteinander kommunizierten. Bei einer grossen Anzahl von Anfragen erzeugte das Gesamtsystem Fehler im Austausch und Daten gingen verloren. Nach einer Zeit normalisierte sich der Zustand wieder. Immer wenn die Datenmenge eine gewisse Anzahl von Anfragen erreichte, dann tauchte der Fehler wieder auf.

Die zuständige Person für Operations zeigte die Messwerte bei einer gewissen Anzahl von Datenmengen und so gingen wir tiefer ins Detail.

Cause

Bei den Ursachen ging es an die Eingrenzung. Fragestellungen, die helfen können, sind:

• Was löste das Problem aus?
• Welche Faktoren kamen hinzu?
• Was für neue Erkenntnisse haben wir, die zuvor nicht bedacht wurden?
• Welche nicht vorhersehbaren Umstände sind eingetreten?

Die Ops-Person schilderte mir ihre Erkenntnisse. Sie hatte bereits Vorarbeit geleistet und die möglichen Systeme der Integration eingegrenzt. Ich öffnete die Codebasis, die mir bereitgestellt wurde. Der Code, um den es ging, wurde über ein Offshore-Unternehmen erstellt. Heute wird dafür auch gerne Nearshore oder Smartshore als Begriff verwendet, die Probleme sind nicht selten die selben.

Wir grenzten die Ursachen auf zwei Endpunkte ein. Ich schaute mir den Code an. Es gab keine automatisierten Tests, jedoch hatte ich einen Einstieg, um zielgerichtet analysieren zu können.

Outcome

Beim Ziel war es dann auch sehr konkret. Sie bezogen sich auf die zwei eingegrenzten Endpunkte. Diese sollen nach der Korrektur die Datenmenge der Lasttests verarbeiten können. Ein weiteres Ziel war eine Deadline, bis wann die Korrektur abgeschlossen sein muss.

Fragestellungen, die dabei auch noch nützlich sein können:

• Wo wollen wir hin?
• Was muss entschieden sein?
• Wie werden wir handlungsfähig?

Gerade bei den Zielen müssen die Entscheidungsträger mit am Tisch sitzen, damit keine Zeitverschwendung durch weitere Rückfragen und Anpassungen bzw. neuen Anforderungen zu einem späteren Zeitpunkt entstehen.

Resource

Nach der Zieldefinition kamen wir zu den benötigten Ressourcen. Insgesamt sassen Teilnehmer von vier Unternehmen am Tisch. Alle in das Problem einzubeziehen hätte in keinem Verhältnis gestanden. Für mich war klar, ich benötigte für diese Korrektur die Ops-Person und für ein Interview einen Ansprechpartner des Systems, dass die Anfragen initiierte. Dieser Ansprechpartner sass auch am Tisch, er spielte mit meinem Sohn Brio-Eisenbahn. Die beiden waren Trendsetter, heute ist das die Grundlage von innovativen Workshops für Unternehmen.

Fragestellungen in diesem Bereich können sein:

• Was brauchen wir?
• Welche Unterstützung ist notwendig?
• Was für Entscheide sind notwendig?

Effect

Bei den Auswirkungen verwende ich gerne «Was wäre, wenn» – Fragen. Es geht in diesem Bereich darum, dass die Erreichung des Ziels mehr positive Effekte hat als negative. In der Softwareentwicklung drückt sich das meist so aus, dass die Korrektur keine neuen Fehler zu Tage fördern soll. Diese Forderung war auch Thema dieses Meeting. Für mich bedeutete das: Zur Absicherung musste ich zuerst Characterization Tests schreiben und die Code-Referenzierungen analysieren.

Fragestellungen, die dabei helfen können:

• Woran erkennen wir, dass wir eine gute Lösung gefunden haben?
• Was sollte nicht passiert sein?
• Was wäre das schlechteste Ergebnis?

Dieses Meeting war für eine Dauer von zwei Stunden angesetzt. Durch die strukturierte Vorgehensweise und dank der Konzentration auf den Sachkonflikt, war das Meeting nach knapp 45 Minuten beendet. Im Rückblick bin ich immer noch davon überzeugt, dass dies ohne meinen Sohn nicht möglich gewesen wäre, da seine Anwesenheit allen Teilnehmern die emotionale Anspannung nahm.

Für die Lösung des Problems benötigte ich am Ende nur die Ops-Person. Wir konnten gemeinsam innerhalb der geforderten Deadline das Problem beheben.

Ich persönlich finde dieses Modell sehr gut, da es eine Struktur vorgibt, die als Hilfestellung dienen kann. Gerade wenn Teilnehmer sehr sprunghaft sind, sich leicht ablenken lassen oder Ausflüchte suchen, dann kann das S.C.O.R.E – Modell der rote Faden bei der Problemlösung sein.

Wenn du für so eine Situation eine strukturierte und wertfreie Vorgehensweise hast, dann interessiert mich dein Feedback! Wie meisterst du solche Situationen?