Benutzerkontakt - Interaktion, Kommunikation und Fragetechnik


Zusammenfassung
Exkurs: Meetings
Interview
Workshop
Informelle Treffen
Spontane Interaktion
Beobachtung des Endanwenders
Mitarbeit beim Endanwender
Fragebogen und Schriftliche Umfrage
EMail
Telefongespräch
Arbeitspakete
Fragetechniken
Exkurs: Eskalation

Siehe evtl. auch Schwierige Kunden, Situationen und Menschen, falls Sie eher Informationen zu unsozialen Verhaltensweisen, stark politisierten Umgebungen oder mangelhafter Projektunterstützung suchen.

Zusammenfassung

Dargestellt werden zunächst die verschiedenen Möglichkeiten formeller und informeller Kommunikationsformen zwischen Analytiker und Fachanwender. Dabei wird auf typische Probleme und Fehler ebenso eingegangen, wie auf die Vorbereitung und Durchführung der Kommunikation. In einem einführenden Exkurs wird auf Meetings eingegangen, wobei Checklisten für Vorbereitung und Durchführung angeboten werden. Bei den Fragetechniken im zweiten Teil werden explizite Fragebeispiele für die für eine Anforderungsanalyse spezifischen kritischen Stellen dargestellt. Ein Exkurs über Verhörmethoden soll nachdrücklich zeigen, was bei einer Interaktion zwischen Fachanwender und Business Analyst nicht erreicht werden soll.

Exkurs: Meetings

Allgemeines


Ein Meeting ist stets ein mehr oder weniger formeller Kommunikations-Prozess, der in irgend einer Weise dem Informationsaustausch, der Entscheidungs- oder der Konsensfindung dient. So beginnt z.B. jedes Projekt mit einem Kickoff-Meeting, später treffen sich Projektgruppen regelmäßig zu Status-Meetings, um auf dem Laufenden zu bleiben, oder ein Dokument wird zum Review vorgelegt und ein zugehöriges Review-Meeting findet statt.

Über Meetings werden gelegentlich böse Witze gemacht deren gemeinsamer Hintergrund die fehlende Effektivität ist ("Feeling lonesome? Nothing to do? Hold a meeting!"). Gibt es im Team oder Unternehmen keine Regeln und keine Meetingkultur, so kann ein Treffen eher kontraproduktiv werden. Meetings können missbraucht werden, um Selbstdarstellung oder Lobbyismus zu betreiben. Ohne Ergebnisorientierung wird es kein Ergebnis geben, der Unterschied zu einem Projekt ohne klare Definition von Erfolg und Misserfolg ist lediglich quantitativer Natur. Bedenkt man die Kosten, die ein Meeting verursacht, so sollte die Notwendigkeit umfangreicherer längerer Meetings nachvollziehbar bleiben. Eine Verzögerung von ca. 15 Minuten kann bei einem Treffen von sechs bis acht Personen ohne weiteres mit 150.- Euro angesetzt werden, sofern noch kein Mitarbeiter des Managements dabei ist. Ein erfolgloser zweitägiger Workshop mit zehn Teilnehmern kann 20000.- Euro kosten.

Bei typischen Projektmeetings ist es guter Stil, wenn jemand die Moderation übernimmt und die Rolle des Moderators auch aktiv wahrnimmt. Es ist nicht falsch, ein Meeting nach der allgemeinen Begrüßung mit den Worten zu beginnen: "Ziel unseres heutigen Treffen ist es..., wir wollen folgende Ziele erreichen...". Ein Protokollführer sollte benannt sein, der alle Entscheidungen, Vereinbarungen (auch verteilte Arbeitspakete), wichtige Aussagen und Aussagen die auf Wunsch eines Teilnehmers aufgenommen werden sollen, festhält. Dazu kommen Zuständigkeiten und Termine. Vorlage / Vorschlag für ein  Meetingprotokoll (word)

Im Laufe der letzten Jahre habe ich einige Checklisten, deren Quellen ich leider verloren habe, meinen Bedürfnissen angepasst, und verschiedentlich auch durchsehen lassen. Die Checklisten müssen dem jeweiligen Rahmen angepasst werden, internationale Tagungen haben andere Anforderungen als kleine firmeninterne Workshops, Strategie-Meetings andere als Review-Meetings.

Vorbereitung

  1. Wurde eine Person beauftragt, das Meeting „technisch“ vorzubereiten? (Sekretärin?)
  2. Wurde ein Raum reserviert? Wurde ggf. beachtet, dass das Meeting länger als geplant dauern kann?
  3. Ist der zeitliche Umfang des Meetings klar? Stehen geplante Zeit und gewünschte Ziele / Beiträge in Relation?
  4. Ist klar, welche Arbeitsmittel für das Meeting notwendig sind? Wird ein PC oder ein Projektor benötigt? Sollen Notizblöcke für die Teilnehmer bereit liegen? Sollen Unterlagen verteilt werden, wurden genügend Kopien angefertigt?
  5. Ist der Grund für das Meeting allen Teilnehmern klar? Herrscht Konsens, welche Ergebnisse am Ende des Meetings herauskommen sollen?
  6. Wurde eine schriftliche Agenda rechtzeitig vor dem Meeting verschickt?
  7. Wurden alle notwendigen Teilnehmer eingeladen, und in der Einladung ist Ort und Zeit des Meetings genannt worden? Wurde ein Anreiseplan verschickt?
  8. Wurden für auswärtige Teilnehmer Hotels reserviert oder eine Empfehlungsliste von Hotels verschickt? Ist der Transport vom Hotel zum Meeting-Ort organisiert?
  9. Liegt eine Teilnahmebestätigung der Schlüsselteilnehmer vor?
  10. Wurden einzelne Teilnehmer auf besondere Aufgaben hingewiesen, sodass sie sich rechtzeitig vorbereiten können?
  11. Wurde bei längeren Meetings an Pausen gedacht? Stehen Erfrischungen bereit? Gibt es Gelegenheit für ein Mittagessen in entspannter Atmosphäre?
  12. Fallen Kosten für die Teilnehmer an? Sind sie informiert?
  13. Gibt es ein Anmeldeformular? Wurde es den Teilnehmern zugeschickt?
  14. Gibt es einen Anmeldeschluss für die Teilnehmer?
  15. Wenn Teilnehmer etwas präsentieren: Gibt es „guidelines“, z.B. Beschränkungen der Redezeit oder der Arbeitsmittel?
  16. Sind Namensschilder notwendig? Eine Sitzordnung?
  17. Wenn Material / Dokumente für das Meeting notwendig sind: Wurden sie rechtzeitig verteilt?

Agenda

  1. Nennt die Agenda den Grund und das Ziel des Meetings?
  2. Bezieht sich das Meeting auf ein vorhergehendes Meeting? Wurden Protokolle und Ergebnisse hieraus an die Teilnehmer verschickt?
  3. Welches Grundwissen wird vorausgesetzt? Worüber sollen sich alle / bestimmte Teilnehmer vorab informieren?
  4. Werden Diskussionsthemen und zu bearbeitende Aufgaben / Probleme spezifisch aufgeführt? Sind die Themen auch für alle Teilnehmer interessant, oder brauchen einzelne Teilnehmer nur zeitweise anwesend sein?
  5. Welche Entscheidungen sollen gefällt werden?
  6. Welche Konsequenzen werden die Entscheidungen haben? Ist klar, wer von den Entscheidungen betroffen ist? Sind die Interessen dieser Personengruppen klar?
  7. Sind die zu diskutierenden Punkte klar priorisiert?

Persönliche Vorbereitung

  1. Wurde das Protokoll des/der letzten Meetings gelesen? Wurden eigene Notizen des letzten Meetings durchgesehen?
  2. Das letzte Meeting sollte nochmals rekapituliert werden. Was haben die Teilnehmer letztes Mal gesagt? Gibt es Widersprüche?
  3. Wurden relevante Punkte mit wichtigen Teilnehmern vorab besprochen? Wo besteht Konsens, wo Dissens?
  4. Ist klar, welche Personen „schwergewichtig“ sind, wer Einfluss / Druck ausüben kann? Wer entscheidungsbefugt ist, wer wankelmütig, wer desinteressiert?
  5. Sind die Streitpunkte und gegensätzlichen Standpunkte klar? Wer vertritt die Standpunkte? Bei demokratischen Entscheidungen: Sind Parteien / Mehrheiten geformt?
  6. Wurden spezifische Fragen vorab gelöst? Ist klar, um was es geht? Ist genügend Know How vorhanden / wurden alle notwendigen Unterlagen gelesen, um kompetent mitwirken zu können?

Durchführung

  1. Wurden Rollen und Aufgaben verteilt? Wer ist der Moderator? Wer Vorsitzender? Wer führt Protokoll?
  2. Wird die Agenda abgearbeitet? Wird auf die Priorisierung einzelner Fragen geachtet?
  3. Wurden „versteckte“ Punkte in der Agenda schließlich benannt und behandelt?
  4. Wird darauf geachtet, sich weder zu sehr im Detail zu verlieren, noch zu oberflächlich zu sein?
  5. Wird darauf geachtet, dass Nicht-Agenda-Themen auch nicht im Meeting besprochen werden? Wurde eine Protokollnotiz gemacht, dass diese Themen ggf. beim nächsten Meeting auf die Tagesordnung kommen?
  6. Ist sichergestellt, dass die Interessen all derer, die von im Meeting getroffenen Entscheidungen berührt werden, auch berücksichtigt werden?
  7. Ist sichergestellt, dass sich die Teilnehmer des Meetings als Team verstehen, die an einer gemeinsamen Lösung arbeiten?
  8. Wird darauf geachtet, dass das Meeting nicht von Einzelpersonen dominiert wird? (Ausnahme: Wenige Personen informieren viele.)
  9. Wurde ein Abstimmungsverfahren vorbereitet (sofern notwendig)? Wurde es korrekt durchgeführt?
  10. Herrscht am Ende des Meetings Klarheit über Entscheidungen, Verantwortlichkeiten, Zeitpläne und Aufgaben? Ist das Berichtswesen klar? Wurden explizit Punkte für das nächste Meeting definiert?

Aufgaben des Meeting-Leiters

  1. Das Meeting soll sich an die Agenda halten und nicht in nebensächliche Themen abgleiten.
  2. Die Atmosphäre soll konstruktiv sein und einen freien Meinungsaustausch fördern.
  3. Der Leiter muss aktiv an der Lösung von Konflikten mitwirken.
  4. Wird das Interesse an dem Meeting wachgehalten?
  5. Zwischenergebnisse sollen zusammen gefasst werden, sodass unter den Meeting-Teilnehmern nicht unterschiedliche Vorstellungen der Ergebnisse entstehen.
  6. Die Teilnehmer müssen dabei unterstützt bzw. dazu hingeführt werden, Punkte der Agenda auch abzuschließen.
  7. Positives Feedback geben (wo angebracht).

Nachbearbeitung

  1. Wurde das Protokoll an alle Teilnehmer verschickt?
  2. Wurde der Rücktransport der Meeting-Teilnehmer organisiert?
  3. Wurde dafür gesorgt, dass der Meeting-Ort auch wieder aufgeräumt wird?

Interview

Beim Interview trifft sich der Analytiker mit dem Fachanwender, um bestimmte Fragen zu klären, deren Antworten dem Fachanwender bekannt sind. Bei einer Istaufnahme geht es i.d.R. unmittelbar um die Tätigkeit des Fachanwenders, bei einer Anforderungsanalyse um seine Wünsche und Ideen. Der Analytiker muss also wissen, welche Fragen er zu stellen hat. Charakteristisch für solche Treffen ist, dass es sich um eine kleine Gruppe handelt, einer oder vielleicht zwei Analytiker bzw. der Analytiker und der Projektleiter auf der IT-Seite mit einem oder zwei Fachanwendern. Ein Übergewicht an Analytikern sollte vermieden werden, die Situation erinnert sonst zu sehr an ein Verhör und könnte kontraproduktiv werden.

Das Interview ist in allen Phasen einer Istaufnahme und einer Anforderungsanalyse ein geeignetes Werkzeug, es kann sowohl zur Klärung von Detailfragen als auch zum Finden einer Übersicht benutzt werden.

Ein Interview sollte nach folgenden Kriterien vorbereitet werden:
Beim Interview gilt eine klare Rollenverteilung: Der Analytiker fragt, der Fachanwender antwortet. Natürlich sind Verständnisfragen des Fachanwenders erlaubt, aber Diskussionen um Themen oder Details, die nicht auf der Agenda stehen, sollten vermieden werden. Die Ergebnisse müssen natürlich protokolliert werden, eine Kopie des Protokolls geht dem Fachanwender zu. Wird dem Protokoll nicht widersprochen, so gehen die gewonnenen Erkenntnisse in die Projektdokumente ein. - Auch hier ist eine Messung der Qualität sinnvoll: Wie häufig widerspricht der Anwender dem Protokoll? Wie häufig wird die Istaufnahme bzw. das Anforderungsdokument korrigiert, obwohl sie dem Protokoll entspricht? Wie häufig stellt sich heraus, dass die aufgenommenen Informationen unvollständig waren? Wie häufig wusste der Analytiker nicht, welche Fragen er stellen soll?

Das EVA-Prinzip kann auch auf die Tätigkeit eines Fachanwenders angewendet werden. Dabei sind im Rahmen eines Interviews zur Tätigkeit eines Fachanwenders folgende Fragen zu klären:
Beim Interview zur Istaufnahme muss stets darauf geachtet werden, dass tatsächlich nur der Istzustand berichtet wird. Einige Fachanwender neigen dazu, sich über das gewünschte System zu äußern, ohne dabei klar zu stellen, dass es sich bei ihren Aussagen um Anforderungen an den zukünftig gewünschten Sollzustand anstatt um den aktuellen Istzustand handelt. Je nach Vorgehensweise muss man solche Abschweifungen entweder von Anfang an zurück weisen, oder man einigt sich darauf, dass sie als Stichwort festgehalten werden, jedoch nicht jetzt sondern erst ein anderes Mal bei der Aufnahme des Sollzustands weiter verfolgt werden.
Beispiel aus der Praxis

Im Rahmen einer Notfalllösung ging es kurz vor dem ersten Produktionslauf nur noch um eine Layout-Frage eines Reports, auf dem die Ergebnisse von Auszahlungen und die Verteilung der Zahlungsströme stehen sollten. Der Entwickler, der aufgrund des Zeitdrucks ohne schriftliche Analyse auf Zuruf mit dem Fachanwender die Lösung erarbeitet hatte, hielt deshalb Rücksprache. Der Fachanwender zeigte sich verwundert über die Vielzahl implementierter Features und wies den Layout-Entwurf des Reports zurück, da er diese Ergebnisse (die besondere Verteilung von Zahlungen nach einem bestimmten Regelwerk) erst in mittelferner Zukunft brauchte. Tatsächlich hatte der Entwickler jedoch mehrmals konkrete Fallbeispiele mit dem Fachanwender durchgerechnet, ohne dass der Fachanwender klar gestellt hatte, dass er dieses relativ komplexe Feature erst irgendwann einmal im Rahmen einer vollständigen Lösung brauchen würde, aber nicht jetzt für das Provisorium.
Man sagt, dass man nicht mehr als zwei Messungen machen soll, wenn das Ergebnis eine Gerade sein soll. Dadurch, dass man es nur mit einem oder zwei Fachanwendern zu tun hat, kann man im Rahmen des Interviews lange Sinn-Diskussionen vermeiden und rasch Ergebnisse erzielen. Zu klären ist jedoch, ob die Ergebnisse vom Fachanwender noch mit anderen Leuten abgestimmt werden müssen; dies kann ein lähmender Prozess werden. Bei einer Istaufnahme ist die Paralysegefahr jedoch beschränkt, da ein vorhandener Prozess lediglich beschrieben bzw. dokumentiert wird und somit keine Entscheidung über die Zukunft des Prozesses gefällt werden muss. Der Prozess selbst kann jederzeit gemessen werden, im Zweifelsfall kann die Aussage des Interviewpartners vor Ort durch Beobachtung des Endanwenders verifiziert werden. Bei einer Anforderungsanalyse kann dagegen die Vorstellung des fiktiven und noch zu erreichenden Sollzustandes unter einzelnen Fachanwendern stark voneinander abweichen. Besteht dann noch Abstimmungsbedarf, kann recht rasch ein show stopper entstehen. Wünschenswert ist daher, dass das Interview nur mit Personen geführt wird, die kompetent und entscheidungsbefugt sind.

Die größte Gefahr des Interviews ist die Betriebsblindheit der Gesprächsteilnehmer. Vier Augen sehen mehr als zwei, die beschränkte Augenzahl beim Interview kann daher zur Folge haben, dass wesentliche Informationen unterschlagen werden, häufig, weil der Fachanwender stillschweigend davon ausgeht bzw. als selbstverständlich voraussetzt, dass der Analytiker diese Informationen kennt. Dasselbe gilt für einen Analytiker mit tiefem Wissen im zu untersuchenden Fach, er setzt u.U. bestimmte Abläufe als selbstverständlich voraus und hinterfragt nicht die betriebsspezifischen Charakteristika.

Workshop

Beim Workshop trifft sich der Analytiker mit mehreren Fachanwendern, um bestimmte Ergebnisse zu erarbeiten.

Für die Vorbereitung gilt dasselbe wie für ein Interview. Da jedoch Ergebnisse oder Inhalte erarbeitet werden, wird man mehr Papier für den Flipchart brauchen. Ab vier Teilnehmern sollte ein Moderator bestimmt werden.

Ein Workshop ist in folgenden Fällen vorzuziehen:
Häufig benutzt man Workshops, um sich zu orientieren oder einen Konsens herbei zu führen. Bei Istzustandsanalysen ist eine Konsensfindung nicht notwendig, denn man misst ja nur vorhandene Prozesse. Dagegen ist die Konsensfindung bei Anforderungsanalysen an noch nicht existierende Systeme ein Grundproblem. Insofern sollten die Alarmglocken schrillen, wenn sich zwei Fachanwender über einen von ihnen geplanten oder vollzogenen Vorgang nicht einig werden und darüber diskutieren. Spätestens, wenn die Sinnfrage gestellt wird ("Warum machen Sie das so?") muss davon ausgegangen werden, dass keine einheitliche Vorgehensweise in der Organisation zu ein und demselben Vorgang existiert. Die Unterschiede zwischen beiden Vorgehensweisen sind dann zu erarbeiten. Im Regelfall werden lediglich die Vorgehensweisen abweichen, nicht die eingehenden Informationen. Das Ergebnis wird gelegentlich voneinander abweichen, der eine Fachanwender erzeugt mehr Output als der andere, z.B. in Form einer zusätzlichen Kontrollliste oder einer optionalen Serviceleistung für seine Kunden.

Die größte Gefahr des Workshops besteht in der Themaverfehlung, dass also der Workshop zu Ende geht, ohne dass das angestrebte Ergebnis auch nur annähernd erreicht wird. Charakteristisch ist, dass sich die Spezialisten, bei der Istaufnahme also die Fachanwender, in der Diskussion von Details verlieren. Der Analytiker muss her strikt eingreifen und zunächst einen Haltepunkt oder einen Schnittstelle definieren, hinter der diese Details erst relevant werden.

Informelle Treffen

Ein informelles Treffen kann auch verabredet sein und sollte auch mit einer Agenda versehen sein. Im Großen und Ganzen gilt ungefähr das gleiche wie für Interviews, Workshops oder Meetings im allgemeinen. Wesentlicher Unterschied ist, dass kein definiertes Schema abgearbeitet wird, sondern die Vorgehensweise, um zum Ziel zu kommen, eher intuitiv ist. Raum für Kreativität ist vorhanden. Normalerweise werden in informellen Treffen in Expertenrunden Detaillösungen erarbeitet.

Informellen Treffen sollte zwar nicht jegliche Form fehlen, d.h. sie sollten nicht strukturlos als Kaffeekränzchen und ohne Zielsetzung stattfinden, aber sie finden ohne größere Verbindlichkeit und häufig ohne den Einfluss von Hierarchien oder Interessensgruppen statt.
Beispiel aus der Praxis

Ein technischer Mitarbeiter eines mittelständischen Unternehmens war in Meetings stets mehr als nur zurückhaltend. Offensichtlich war er durch seinen recht dominanten Vorgesetzten ziemlich eingeschüchtert; die Umgangsweise des ansonsten sozial sehr kompetenten Vorgesetzten hinterließ beim Beobachter den Eindruck, als ob er diesen speziellen Mitarbeiter nicht für ganz voll nahm. Beim Mittagessen in der Kantine war dieser Mitarbeiter aber eher das Gegenteil. In informellen Treffen offenbarte er sich als Goldgrube für die Lösung kniffeliger Aufgaben. Im persönlichen Kontakt zu anderen Mitarbeitern entwickelte er eine Proaktivität, die dem Unternehmen sehr zu Gute kam, die er aber im formellen Kreis niemals lebte.
Für einen Business Analysten sind informelle Treffen eine gute Gelegenheit, Detailfragen zu klären und qualitätssichernde Maßnahmen für sein Anforderungsdokument zu realisieren. Ein Walkthrough zu einem definierten Prozess sollte m.E. zunächst immer erst einmal informell statt finden, da im ersten Durchlauf ohnehin Fehler gefunden werden.

Inwiefern Protokolle solcher Treffen angefertigt werden sollen oder ob die erzielten Ergebnisse als Teil des Analyseprozesses sofort in das Anforderungsdokument eingehen, ist eine Frage der Unternehmenskultur. M.E. reichen Notizen, die nicht in einem (formellen) Protokoll resultieren, und die erzielten Ergebnisse werden sofort ins Anforderungsdokument übertragen und dann den Gesprächspartnern nochmals zur Durchsicht gegeben.

Informelle Treffen bzw. jede Form informeller Interaktion machen den Hauptteil der Interaktionen im Rahmen einer Anforderungsanalyse aus, wobei auch Workshops oder Interviews einen eher informellen Rahmen genießen können.

Gelegentlich gibt es in der untersten Management-Ebene ein unbegründetes Misstrauen gegenüber informellen Treffen. Nach meinen Erfahrungen wird dabei der Begriff "informell" nicht als intuitive Arbeitsweise verstanden, sondern als nicht durch das Management kontrollierbar.

Spontane Interaktion

Gemeint damit ist eine ungeplante Interaktion, die zu Ergebnissen führt. Dies ist alles andere als ein formeller Prozess. Man trifft sich zufällig in der Kaffeeküche, der Kantine oder im Gang, oder im Rahmen einer gemeinsamen Freizeitaktivität, oder man schweift in einem Telefongespräch plötzlich ab. Typisch für solche spontanen Interaktionen ist, dass sie sehr kurz sind und meist nur ein Detail betreffen, das einem gerade durch den Sinn geht. Häufig handelt es sich dabei um eine intuitive aber wichtige Erkenntnis, die jedoch der genaueren Untersuchung bedarf. Nach kurzer Diskussion trennt man sich wieder und vergisst alles, wenn man es nicht sofort festhält.

Pflicht ist es also, sofort eine Notiz zu machen, soz. ein kleines Protokoll. Man kann seinem Gesprächspartner, und zunächst nur diesem, eine kurze EMail zukommen lassen, dann über die Angelegenheit nachdenken, und schließlich einen informellen oder formellen Rahmen zur Weiterarbeit suchen. Der Normalfall ist allerdings, dass geklärte Details sofort in die Spezifikation eingehen, neue Fragen entstehen aus spontanen Interaktionen nur selten.

Beobachtung des Endanwenders

Wenn sich der Analytiker für die Beobachtung des Endanwenders entscheidet, dann fand meist zuvor schon ein Interview oder ein Workshop statt, und die beschriebenen Abläufe sollen nochmals verifiziert werden. Ein anderer Grund kann sein, dass der Fachanwender und der Analytiker keine gemeinsame Sprache gefunden haben und die Beobachtung den einfachste und sichersten Weg darstellt, die vom Fachanwender vollzogenen Prozesse zu definieren. Man sollte nicht vergessen, dass die Mehrheit der Fachanwender lediglich einen reproduktiven Anspruch hat, also ihre einmal erlernten Prozesse fortwährend und mit möglichst geringen Abweichungen reproduzieren. Der Anspruch, diese Prozesse auch im Sinne der IT vollständig und richtig erklären zu können, liegt beim normalen Fachanwender nicht vor.

Eine Beobachtung des Endanwenders sollte nach folgenden Kriterien vorbereitet und durchgeführt werden:
Normalerweise wird der Analytiker sich die Tätigkeit neben der Arbeit erklären lassen. Da das Tagesgeschäft nicht einfach so zu bewältigen ist, sollte der Analytiker nicht davon ausgehen, dass die Aufnahme der Tätigkeit unterbrechungsfrei stattfinden kann. Zu vermeiden ist eine Situation, in der der Fachanwender lediglich einen beispielhaft vorbereiteten Ablauf demonstriert und dann den Analytiker wieder entläßt. Solch ein beispielhaft vorbereiteter Vorgang kann sehr gut als erste Einführung dienen oder bei einem Interview oder Workshop vorgeführt werden, er wird jedoch kaum jemals die Ausnahmen, alternativen Abläufe und Nebeneffekte des Prozesses darstellen. Der Regelfall wird sein, dass der Analytiker Notizen macht und sich Unterlagen kopiert und ggf. auch Screenshots sammelt.

Die Kooperation der Fachanwender sollte geschätzt und auch honoriert werden. Das Ergebnis der Beobachtung, d.h. das resultierende Schriftstück sollte mit dem Fachanwender nochmals durchgesehen werden, ehe es weiter verwendet werden. Ein reines Zusenden zur Durchsicht ist kein probater Weg der Qualitätssicherung: Fachanwender, die ihre eigene Tätigkeit nicht selbst IT-brauchbar dokumentieren können, können meist auch die erstellten Dokumente nicht korrigieren.

Die größte Gefahr bei der Beobachtung des Endanwenders besteht darin, dass nur der Geradeausflug studiert wird und die Ausnahmen, also gerade die für ein IT-System kritischen Ereignisse, nicht erkannt werden. Der Fachanwender vermeidet häufig auch mehr oder weniger bewusst diese Ausnahmen, nicht selten im Glauben, dem Analytiker etwas gutes zu tun und ihn nicht zu verwirren. Eine weitere Gefahr besteht darin, dass sich manche Menschen nicht gerne bei der Arbeit zusehen lassen und sich unter Druck gesetzt fühlen. Dem kann nur durch hinreichende soziale Kompetenz begegnet werden, wobei sicher gestellt sein muss, dass am Ende lediglich der Geschäftsprozess und nicht die Person des Fachanwenders beschrieben wird; auch nicht informell oder mündlich.

Mitarbeit beim Endanwender

Die Mitarbeit beim Endanwender ist das letzte Mittel, das zur Istaufnahme angewendet werden kann, wenn alle anderen Methoden versagen oder von Anfang an nicht erfolgversprechend sind. Dabei wird der Grundsatz probieren geht über studieren angewendet.

Die einzigen Gründe für die Wahl dieser Methode sind die Komplexität der Materie oder die Unmöglichkeit, mit dem Fachanwender eine gemeinsame Kommunikationsebene zu finden, evtl. noch der Wunsch, bei besonders sensiblen Prozessen Sicherheit über deren korrekte Beschreibung zu erhalten. In diesem Fall bleibt dem Analytiker nur der Weg, die Prozesse vor Ort selbst nicht nur zu studieren sondern auch zu reproduzieren, um sie vollständig verstehen und umsetzen zu können. Der typische Anwendungsbereich für diese Methode sind komplexe rein manuelle Prozesse. Die Methode kann auch erwogen werden, wenn der Analytiker von der zu analysierenden Materie noch gar keine Ahnung hat, ein nicht unüblicher Wunsch von Auftraggebern, die Betriebsblindheit vermeiden wollen.

Die Mitarbeit beim Fachanwender ist ein Prozess wechselseitigen Lernens und Lehrens. So, wie der Fachanwender dem Analytiker seine Tätigkeit und die damit verbundenen letztendlich zu analysierenden und zu fixierenden Prozesse nahe bringt, vermittelt der Business Analyst dem Fachanwender die Bedürfnisse der IT-Welt, indem er ihn immer wieder darauf aufmerksam macht, wie in einer gegebenen Situation ein dummes IT-System reagieren würde. Dieser Schritt ist wichtig, da ja ein gemeinsames Verständnis und eine gemeinsame Sprache notwendig sind.

Man tritt als Analytiker eher als eine Art recht nerviger Praktikant auf, der vor allem beim Tagesgeschäft stört. Insofern sollte also irgendeine Form der Kompensation oder Motivation für den Fachanwender vorgesehen werden, und sei es nur die Verpflichtung, regelmäßig die Brotzeit zu beschaffen. Um die Konsequenzen einer Tätigkeit im Detail kennen zu lernen, sollte man auch nicht davor zurück schrecken, die möglichst unangenehmen Teile einer Tätigkeit immer wieder zu wiederholen, z.B. die Diskussion mit unzufriedenen Kunden. Ungeachtet seines berufsbedingten Wissensdurstes muss sich der Analytiker über die Grenzen seiner Kompetenzen stets im Klaren sein: im Rahmen der Istaufnahme ist Kritik an den vorhandenen Prozessen oder Methodiken nicht angebracht, man ist Praktikant und im aktuellen Arbeitsumfeld nur geduldet und will zunächst die Prozesse nur verstehen.

Da jede Einarbeitung geraume Zeit dauert und Business Analysten i.d.R. gut bezahlte Leute sind, kann dieser Weg sehr teuer werden. Bei allen Kostenbedenken bzw. gerade deshalb sollte nicht vergessen werden, dass ein unbrauchbares und womöglich gar nicht nutzbares IT-System wesentlich teurer kommt, als ein durch eine intensive Analysephase scheinbar verteuertes System. Selbst die Einsicht, dass man besser kein IT-System einführt, kann ein gutes Resultat sein. Die günstigste Möglichkeit für einen Auftraggeber besteht hier darin, den Analytiker nicht über ein Softwarehaus anzuheuern und damit die Marge des Auftragnehmers mit zu bezahlen, sondern den Analytiker direkt unter Vertrag zu nehmen; das dürfte zwischen 30% und 60% billiger kommen. Weiterhin vermeidet der Auftraggeber damit einen Interessenskonflikt, bei dem der Analytiker vom Auftragnehmer unter Druck gesetzt wird, irgendwelche Ergebnisse zu liefern, auch wenn diese für den Auftraggeber zu unbrauchbarer Software führen.

Die größte Gefahr bei der Mitarbeit beim Endanwender ist sozialer Natur. Eine unangenehme Analytiker-Persönlichkeit wird kaum die nötige Integration in das Team und somit ins Tagesgeschäft bekommen. Eine andere große Gefahr ist übermäßige und freundlich gemeinte Rücksichtnahme auf den Analytiker, sodass er kritischen Prozessteile nicht zu Gesicht bekommt oder nicht versteht.

Fragebogen und schriftlichen Umfrage

Die Verwendung eines Fragebogens bzw. einer schriftlichen Umfrage setzt voraus, dass man sehr genau weiß, welche Fragen man beantwortet haben will. Sie kann benutzt werden, wenn man quantitative Ergebnisse oder Meinungsbilder feststellen will. Im Rahmen der Anwendungsentwicklung in der IT spielt diese Vorgehensweise eine untergeordnete Rolle.

Die schriftliche Umfrage unterscheidet sich im hier verwendeten Sinne vom Fragebogen insofern, als der Befragte eher selbstformulierte Antworten geben kann. Beispiel: Bei der Umfrage kann die Frage lauten "Welcher Arbeitsablauf ist Ihnen am unangenehmsten und Sie wollen dort bessere IT-Unterstützung?" und die Antwort kann auf einigen Textzeilen frei formuliert werden. Beim Fragebogen würden noch vorgefertigte Antworten evtl. zusammen mit einer Benotung oder Gewichtung stehen, z.B. "Kundennummer zu lang zum Eintippen", "zu viele Datenfelder auf den Formularen", "Kontrollliste zum aushaken wäre wünschenswert" etc. Gemäß dieser Unterscheidung kann bzw. muss eine schriftliche Umfrage bei einer kleineren Gruppe stattfinden, z.B. bei einer repräsentativ ausgewählten Stichprobe. Muss deshalb, da die Antworten relativ frei sein können und daher die Auswertung aufwendig und teuer wird.

Sinnvoll angewendet kann ein Fragebogen nur dann werden, wenn eine sehr große Anzahl zu befragender Personen vorhanden ist. Bevor man einen Fragebogen verteilt, sollte man sich über die möglichen Antworten den Kopf zerbrechen. Multiple Choice ist nur sinnvoll, wenn auch alle möglichen Antworten aufgelistet sind oder zumindest der aller größte Teil, sodass die Kategorie sonstiges mit der dahinter stehenden Textzeile nicht all zu häufig angegeben wird.

Ein Fragebogen kann dann angewendet werden, wenn eines oder mehrere der folgenden Kriterien erfüllt sind:
Jeder Mensch fragt sich, was mit seinen Antworten gemacht wird. Man sollte sich also entscheiden, ob eine Umfrage anonym stattfinden kann, oder nicht. Eine Erklärung, wofür die Ergebnisse der Umfrage verwendet werden, ist ebenso sinnvoll wie die Veröffentlichung des Umfrageergebnisses samt den daraus geschlossenen Resultaten.

EMail

Formelle EMails

EMails unterstützen das Prinzip der Schriftlichkeit, d.h. man erhält ein Dokument, auf das man sich bei Widersprüchen beziehen kann. Dabei sollte man allerdings wie auch im sonstigen Geschäftsleben niemals aus dem Blickfeld verlieren, dass Lösungen gesucht werden, und nicht Schuldige. Wird also einmal ein gravierender Widerspruch entdeckt, so sollte dies eine Gelegenheit sein, nach weiteren Schwächen im Lösungsansatz zu suchen und ihn zu verbessern, nichts anderes.

Bei der EMail gibt es sowohl die formelle als auch die informelle Variante. Zu unterscheiden sind die beiden Varianten am ehesten durch den Verteiler, wobei in einen strategischen und einen sachlichen Verteiler unterschieden werden kann. Im strategischen Verteiler finden sich im günstigsten Fall Personen, die Entscheidungen fällen bzw. herbei führen können. Im ungünstigsten Fall setzt der Absender lediglich deshalb Personen in geeigneten Positionen auf den Verteiler, um sich selbst zu profilieren.

Eine formelle EMail ist i.d.R. das Resultat eines anderen formellen Prozesses. Sie dient dazu, zu informieren, und sie ist häufig mit einem Arbeitspaket verbunden. Der Versand eines Protokolls aus einem Workshop kann solch eine informative Mail sein. Ebenso kann der Versand einer ToDo-Liste bzw. eines Fragenkatalogs Grund für eine formelle EMail sein.

Ein sinnvoller Einsatz eines strategischen Verteilers ist eine Rückfrage bzgl. nicht eingehaltenen Terminen. Es kommt erstaunlich häufig vor, dass Liefertermine für Arbeitspakete ohne Kommentar nicht gehalten werden, oder aber, dass die Arbeitsergebnisse vollkommen unzureichend sind. Eine Rückfrage unter Einbeziehung der Hierarchie hat dann den doppelten Effekt, dass einerseits daran erinnert wird, dass ein Arbeitspaket nicht gut oder schnell genug bearbeitet worden ist, andererseits wird die Hierarchie über den Verzug informiert. Für das mittlere und höhere Management ist es essentiell zu wissen, was im Unternehmen und im Projekt vorgeht, es besteht also letztendlich sogar eine Informationspflicht.
Beispiel aus der Praxis

Ein Projektleiter bestand darauf, dass jede EMail, die an den Kunden gerichtet ist, auch an ihn in Kopie gehen sollte. Da er mehrere Projekte parallel verwaltete, war der in seiner Mailbox auflaufende Schriftverkehr beträchtlich. Gelegentlich wurde er von Mitarbeitern auf EMails angesprochen, die er noch nicht beantwortet hatte. Meist verwies er auf Zeitdruck und darauf, dass er noch über 500 ungelesene Mails in seiner Inbox hätte. Feedback zu EMails kam häufig erst mit mehrtägiger Verspätung an, die aktuelle Fragestellung war meist bereits bearbeitet, sodass Entscheidungen gelegentlich revidiert werden mussten. Dies führte wiederum regelmäßig zu Ärger auf Kundenseite.
EMails tendieren dazu, sich unkontrolliert zu vermehren. Vergessen Sie nicht, dass die Empfänger i.d.R. vielbeschäftigte Leute sind. EMails sollten also knapp gehalten werden, sofern dies möglich ist. Die Sicht auf eine Fragestellung und die dazu passende Antwort ist oft abhängig vom Empfänger: Für einen Geschäftsführer eines kleinen oder mittleren Unternehmens tut es i.d.R. ein kurzes ja oder nein, wo der Software-Designer ein kleines Buch erwartet.

EMails haben wie jede andere schriftliche Kommunikationsform auch den Nachteil, dass weder Verständnisfragen sofort gestellt werden können, noch kann man auf andere Weise mit seinem Gegenüber interagieren, sodass die übermittelte Botschaft gelegentlich missverstanden wird. Im Gegensatz zum klassischen geschäftlichen Briefverkehr hat sich kein formalisierter Schreibstil bei diesem noch recht jungen Kommunikationsmedium etabliert. Ein Mindestmass an Höflichkeit und Sachlichkeit sollte neben einem lesbaren Stil gewahrt bleiben.
Beispiel aus der Praxis

In einem kleinen mittelständischen Unternehmen trugen einige Leute gelegentlich ihre Konflikte per EMail aus. Dies ging auch lange Zeit gut, bis ein neuer Mitarbeiter des unteren Managements mit dieser Streitkultur nicht zurecht kam. Fortan tendierte der Verteiler dazu, bei jeder Antwort zu wachsen, bis schließlich die Geschäftsführung mit drauf war.

Informelle EMails

Die informelle EMail ist i.d.R. mit einer oder einigen wenigen Fragen oder einer kurzen Information verbunden. Gegenüber einem Anruf hat man zwei Vorteile: Der Empfänger wird in seiner Arbeit nicht unterbrochen und man erhält ein Dokument als Resultat. Informelle EMails gehen grundsätzlich an keinen strategischen Verteiler. Die EMail wird zwar ausgewertet und geht in die eigenen Arbeitsergebnisse ein, aber sie stellt kein offizielles Dokument dar. Darüber sollte Konsens zwischen Sender und Empfänger herrschen.
Beispiel aus der Praxis

Ein Projektleiter wollte von seinem Analytiker einen schriftlichen Bericht über die Auswirkungen eines Änderungswunsches des Kunden. Der Analytiker verfasste dazu eine recht locker formulierte EMail, die er als informell ansah. Der Projektleiter kopierte ungefragt Teile dieser EMail und schickte sie an den Kunden, wobei nicht ersichtlich war, dass die kopierten Stellen vom Analytiker waren. Der Kunde reagierte aufgrund der recht entspannten aber nicht unhöflichen Wortwahl der zitierten Stellen nicht erfreut. U.a. wurde davon gesprochen, dass "das Konzept teilweise über den Haufen geworfen" worden war und Teile der Arbeit des Analytikers "für den Mülleimer" gewesen wären. Als der Analytiker den Projektleiter zur Rede stellte, erklärte dieser, dass er jede EMail, die er bekäme, als formelle Stellungnahme betrachte.
Gelegentlich können gerade informelle Emails missverstanden werden. Der Leser interpretiert eine Aussage in die Mail, die nicht gegeben ist bzw. liest Dinge zwischen den Zeilen, die nicht drin stehen. Als Leser merkt man dies am ehesten an einer aufwallenden negativen Emotion. Man sollte sich dann vor Augen halten, dass der erste Gedanke, das erste Gefühl oder die erste Interpretationsweise nicht die richtige sein muss. Man nimmt die EMail durch die eigene Brille wahr, anstatt die Intention des Autors zu hinterfragen. - Sinngemäß gilt dies natürlich immer.

Eine gute Taktik ist es dann, die EMail nicht sofort sondern erst nach einigen Stunden, vielleicht erst am nächsten Tag zu beantworten bzw. zunächst eine Antwort zu schreiben und dann zu speichern, um sie später nochmals Korrektur zu lesen.

Telefongespräch

Normalerweise will ein Business Analyst etwas wissen, wenn er jemanden anruft. Anders herum will ein Fachanwender so gut wie immer eine neue Anforderung oder eine gewonnene Information an den Analytiker kommunizieren. Ich selbst habe meist nur eine oder einige Fragen, die zu klären sind, was aber abhängig von der Komplexität der Fragen nicht heißt, dass das Gespräch in wenigen Minuten beendet ist. Ist der Kunde räumlich zu weit entfernt, so müssen teilweise recht ausführliche Diskussionen telefonisch erledigt werden. Wenn dies vor Gesprächsbeginn bekannt ist, dann sollte auch ein Gesprächstermin vereinbart werden; niemand schneidet sich gerne eine Stunde aus seiner Tagesplanung.

Es ist eine Philosophie-Frage, ob man zu jedem Telefongespräch auch eine Gesprächsnotiz anfertigen sollte. Auch hier führt eine Überbürokratisierung lediglich zu Ineffektivität. Wenn eher wichtige Auskünfte gegeben werden, derer Verbindlichkeit relevant für das Projekt ist, dann ist diese Frage sicher zu bejahen. Eine kurze zusammenfassende EMail an den Angerufenen tut es meistens.

Das Telefon kann zum Zeitkiller werden. Zumindest als Anrufer kann man dem entgegen wirken, indem man vor dem Gespräch seine Fragen und den Zweck des Anrufs niederschreibt. Auf diese Weise vermeidet man auch, dass man im Gespräch ein Thema vergisst. Man kann auch EMail und Telefon kombinieren, indem man die Fragen an seinen Gesprächspartner schickt, am Telefon die Antworten diskutiert und ausarbeitet und dann in einer weiteren EMail festhält. Wesentlicher Unterschied zur EMail-Anfrage ist hier die Interaktion: Anrufer und Angerufener erarbeiten gemeinsam die richtigen Antworten, häufig überhaupt erst die richtigen Fragen.

Arbeitspakete

Formelle Arbeitspakete

Ein Arbeitspaket ist eine Menge von Aufgaben, die bis zu einem bestimmten Termin zu erledigen sind. Wenn ein Meeting oder Workshop veranstaltet wird, dann ist es mit dem Treffen nicht getan. Am Ende des Meetings werden normalerweise Ziele vereinbart, die wiederum zu Arbeitspaketen geschnürt und verteilt werden.

Arbeitspakete, die ein Analytiker vergibt, sind fast ausschließlich die Bearbeitung von Fragekatalogen bzw. ToDo-Listen mit zu beschaffenden Unterlagen oder Informationen, und gelegentlich die nachdrückliche Forderung nach einer beim Kunden oder in der Fachabteilung ausstehenden verbindlichen Entscheidung. Die korrekte Erledigung solcher Arbeitspakete ist meist kritisch für die Vervollständigung des Anforderungsdokuments. Wird ein formeller Weg eingeschlagen, um Arbeitspakete zu erledigen, dann nicht zuletzt deshalb, damit auch ein formeller Eskalationsweg beschritten werden kann, wenn die Arbeitspakete in unzureichender Weise bearbeitet werden.

Informelle Arbeitspakete

Informelle Arbeitspakete unterscheiden sich von formellen entweder dadurch, dass jemand gebeten wird, ein Arbeitspaket nebenbei zu übernehmen, das er nach seinen Tätigkeitsmerkmalen nicht übernehmen muss; es gibt keinen formellen Weg, ihm dieses Paket zu übertragen. Oder dieses Arbeitspaket könnte zwar formell vergeben werden, jedoch wird ein informeller Weg gewählt, meist, da dadurch im Einzelfall schneller Ergebnisse erwartet werden können.

Auch informell vergebene Arbeitspakete sind Arbeitspakete, die erledigt werden müssen. Da jedoch der formelle Rahmen fehlt, fehlt auch eine Möglichkeit, unzureichende Ergebnisse nachzufordern bzw. zu sanktionieren. Man bittet also seinen Partner mehr um die Erledigung der Arbeitspakete, als dass dies angeordnet wird. Der Empfänger des Arbeitspaktes hat auch eher eine Möglichkeit, die Bearbeitung zurückzuweisen, als wenn der formelle Weg eingeschlagen wird. Im Projektgeschäft ist der Übergang vom formellen zum informellen Arbeitspaket fließend, denn i.d.R. ist der Projektleiter nicht der disziplinarisch Vorgesetzte seines Projektteams. Für den Business Analysten gilt darüber hinaus, dass er seinen Kunden keine Anordnungen geben kann.

Arbeitspakete, die ein Analytiker vergibt, sind auch bei der informellen Variante meist nur die Beschaffung von Informationen und Dokumenten, die Bearbeitung von Fragenkatalogen oder die Herbeiführung von Entscheidungen. Letzteres geht allerdings auf informellem Wege nicht in jedem Umfeld. Allerdings spricht nichts dagegen, dass eine informelle Anfrage zu einem formell kund getanen Ergebnis führt.

Fragetechniken

Allgemeines

Ein Analyseprozess für ein IT-System sollte nicht mit den Fragetechniken in einem polizeilichen Verhör verwechselt werden. Zwar lohnt es sich auch für Business Analysten die grundlegenden Methoden einer Vernehmung zu studieren, aber die Anwendung z.B. der Reid-Methode oder das Ausspielen verschiedener Fachanwender gegeneinander ist in höchstem Maße kontraproduktiv, unprofessionell bzw. schlichtweg dumm. Ich weise hierauf deshalb nochmals drastisch hin, um den Unterschied zwischen der Suche nach Lösungen und der Suche nach Schuldigen deutlich zu machen. Beim Bau eines IT-Systems wird nach einer Lösung gesucht, nachdem das richtige Problem definiert bzw. die richtige Fragestellung formuliert wurde. Dabei wird es immer wieder menschliche Nachlässigkeiten oder Fehler geben. Es gibt seltene Ausnahmefälle, bei denen ein Projektleiter, Business Analyst oder Fachanwender ausgewechselt werden muss, da er seinen Pflichten nicht nachkommt. Häufiger kommt es jedoch vor, dass einige Team-Mitglieder ungeduldig und entnervt reagieren, wenn von anderen Team-Mitgliedern Fehler gemacht werden. Man kann dann die Normalität der menschlichen Unvollkommenheit nur immer wieder betonen.

Selbstverständlich versagt jede Befragungstechnik, wenn der Befragte konsequent die Aussage verweigert. Da geht es einem Polizisten nicht besser, als einem Business Analysten.

Als Analytiker hat man die Verantwortung, die Quote der zweitteuersten Fehler im Projekt niedrig zu halten. Nach Projektplanungsfehlern schlagen falsche oder unvollständige Anforderungen am massivsten zu Buche.

Exkurs: Theoretischer Hintergrund zur Befragungstechnik anhand von Verhörmethoden

Vgl. z.B. http://media.wiley.com/product_data/excerpt/12/04708446/0470844612.pdf und http://www.reid.com/critic-techniquedefen.html
google zu interrogation method
google zu Verhörmethoden (geprüfte Treffer Stand 10/2003 waren in Bezug auf diese Site wenig bis gar nicht interessant)

Allgemeines

In der Kriminalistik sucht man nach Schuldigen, im Geschäftsleben dagegen nach Lösungen. Dies zu verstehen ist notwendig. Bei Verhören benutzte Methoden sind offensichtlich kein geeignetes Mittel, um von Fachanwendern Informationen zu bekommen. Eher bewirken sie das Gegenteil. Ein Fachanwender, der in eine hilflose oder bedrohliche Situation gebracht wird bzw. der unter psychischen oder physischen Druck gesetzt wird, wird schlagartig die Kooperation einstellen und zu Recht ggf. den Vorfall eskalieren. Die theoretische Kenntnis der Methoden ist m.E. jedoch nützlich, da sie einerseits aufzeigen, was man im Geschäftsleben nicht erreichen soll, andererseits wird auch Verkaufspersonal oder Mitarbeiter von Personalabteilungen, die Einstellungsgespräche führen, in Befragungstechniken unterrichtet, die auf Vernehmungsmethoden beruhen.

Verhörtechniken und Befragungsmethoden, um Kriminelle zu Geständnissen zu bringen, haben eine lange Geschichte. Der Wert des Geständnisses wird auch heute noch so hoch geachtet, dass Folter selbst in den sog. zivilisierten Ländern gelegentlich noch immer als probates Mittel diskutiert oder sogar eingesetzt wird. Ein Verhör ist prinzipiell kein freundliches Beisammensein, sondern ein Machtspiel im weiteren Sinne, bei dem es darum geht, den Widerstand und somit den Willen des Verhörten zu brechen. Hierzu wird Druck ausgeübt, auch in Rechtsstaaten wird dabei manchmal sehr nahe an den Grenzen der Legalität gearbeitet wird, wobei die Interpretation dieser Grenzen von Land zu Land verschieden ist. Moderater Schlafentzug durch Dauerverhöre, Verweigerung des Ganges zur Toilette, Reduzierung der Nahrung oder "moderate physical preassure" sind nichts ungewöhnliches. Die weniger physiologisch orientierten Methoden der professionellen Vernehmung basieren im Wesentlichen darauf, eine emotionale Beziehung zum Verhörten aufzubauen, "undercover" sich in das Vertrauen des Verdächtigten einzuschleichen, oder ihn mit erfundenen "Beweisen" (z.B. dass ein Mordopfer noch lebt und den Verdächtigten identifiziert hätte) unter Druck zu setzen. Druck ist ein Grundprinzip, z.B. erzeugt das ständige wiederholen lassen einer vom Verdächtigten erzählten Story, unterbrochen von smaltalk, bereits Druck. Negative Emotionen wie Zorn oder Wut sollen sowohl beim Vernehmenden als auch beim Vernommenen vermieden werden, da sie sich nicht konstruktiv auf die Interaktion auswirken.

In gewissen Sinne sind sowohl ein Vernehmer, als auch ein befragender Business Analyst auf der Suche nach der Wahrheit. Sie haben einen begründeten Verdacht, dass eine Person die Wahrheit kennt, aber nicht nennen will. Und sie wollen diese Wahrheit in Erfahrung bringen. -  Im Regelfall geht der Verhörende davon aus, dass er tatsächlich mit einem Schuldigen, und nicht mit einem Beschuldigten zu tun hat. Die Möglichkeit, ein falsches Geständnis zu bekommen, wird kaum beachtet.

Allerdings ist die Motivation des "Verdächtigen" komplett anders. Ein schuldiger Krimineller ist sich seiner Tat und der Zurückhaltung der Wahrheit bewusst. Er will nicht, dass sie ans Licht kommt, wobei nach gängiger Meinung sowohl die Angst vor Strafe als auch Schamgefühle eine Rolle spielen. Ein befragter Fachanwender hält dagegen die Wahrheit nur unbewusst zurück, er weiß u.U. gar nicht, was der Analytiker von ihm wissen will, oder er hat keine Vorstellung davon, dass fachlich unbedeutende Ereignisse für das Funktionieren eines IT-Systems von herausragender Wichtigkeit sind. Er ist normalerweise engagiert und will sich an der Wahrheitsfindung aktiv beteiligen. Selten können jedoch gemachte Fehler zu einer Verschleierungshaltung führen, und zwar immer dann, wenn die Unternehmenskultur bzw. der direkte Vorgesetzte Fehler bestraft.

Offshe-Modell

Nach dem Offshe-Modell muss zunächst erreicht werden, dass sich der Verdächtige zunächst auf ein (Zu-) Geständnis einlässt bzw. dass ihm dies entlockt wird, und dann das volle Geständnis folgt. Um nun ein erstes Zugeständnis zu erreichen, muss der Verdächtige davon überzeugt werden, dass an seiner Schuld keinerlei Zweifel besteht. Dazu muss er mit Beweisen soz. überrannt werden, nötigenfalls auch mit fiktiven (also frei erfundenen) Beweisen. Zudem soll der Eindruck vermittelt werden, dass der Vernehmende um so verärgerter wird, je länger das Geständnis aus ich warten lässt. Eines der wesentlichen Ziele des Vernehmenden ist es zunächst, den Verdächtigen in eine subjektiv hilflose Situation zu bringen, z.B. mit Aussagen wie "Sie kommen hier nicht eher heraus, bis Sie gestehen" oder "Es besteht kein Zweifel an Ihrer Schuld, fraglich ist nur noch das Strafmaß". Sobald der Zustand subjektiver Hilflosigkeit erreicht ist, wird der Verdächtige motiviert bzw. animiert, zu gestehen. Dazu wird Druck aufgebaut. Eine typische "schwach motivierende" Phrase hierzu ist "Sie werden sich besser fühlen, wenn Sie uns die Wahrheit gesagt haben", eine "stark motivierende" ist "Wenn Sie nicht gestehen, werden Sie zur Höchststrafe verurteilt. Ihre Kinder landen in einem Heim." Sobald ein erstes Geständnis abgegeben wurde, wird im zweiten Teil der Befragung auf die Details des Verbrechens eingegangen, also darauf, wie es begangen worden ist. Dabei muss auch nachgewiesen werden, dass das Geständnis echt ist. Neben Differenzen zwischen echten Beweisen und Aussagen des Verdächtige, und dem Fehlen von (neuen) Details, die den Verdacht erhärten, gilt auch die vollkommene Übereinstimmung der Aussagen des Verdächtigen mit den Annahmen bzw. Unterstellungen der Polizei als Hinweis auf ein falsches Geständnis.

Reid-Methode

Die z.Z. durch die deutsche Presse geisternde und immer wieder kritisierte Reid-Methode, die nun auch bei der deutschen Polizei geschult wird, basiert auf zwei Prinzipien:
  1. Brechen des Widerstandes und des Unterbinden des Abstreitens der Tat.
  2. Förderung des Wunsches zu gestehen.
Zunächst wird eine informelle Befragung empfohlen, bei der es nicht notwendig ist, den Verdächtigten über seine Rechte aufzuklären. Zweck ist es, eine positive Atmosphäre des Vertrauens herzustellen und Informationen über die Persönlichkeit des Verdächtigten zu erhalten, die anschließend genutzt werden können, um den Widerstand gegen ein Geständnis zu brechen. Das neunstufiges Modell der Reid-Methode lässt sich grob wie folgt zusammen fassen:
  1. Zuerst wird der Verdächtige direkt konfrontiert. Der Vernehmende drückt sehr klar seine Überzeugung aus, dass der Verdächtige schuldig ist. - Dabei geht es auch darum, etwas über die Persönlichkeit des Verdächtigen heraus zu bekommen und einen Anknüpfungspunkt zu definieren.
  2. Dem Verdächtigen wird Verständnis für die Tat vermittelt. Dabei werden monologartig moralische (aber nicht juristische) Gründe und Rechtfertigungen für die Tat auf mitfühlende Art vorgetragen. Empfohlen wird dabei bei emotionalen Verdächtigen u.a. zu kommunizieren, dass jeder andere auch in derselben Situation dasselbe Verbrechen begangen hätte. Schuldgefühle des Verdächtigen sollen reduziert werden, z.B. indem man ihm kommuniziert, dass andere Leute schlimmeres getan haben. Bei unemotionalen Verdächtigen wird der Versuch empfohlen, ihn bei einer Lüge zu erwischen, wodurch sofort ein psychologischer Nachteil für den Befragten entsteht. Ebenso soll unterstellt werden, dass das Motiv hinter dem Verbrechen nicht kriminell war. Der Verdächtige soll soweit gebracht werden, zuzugeben, dass er in irgend einer Weise mit dem Verbrechen verbunden ist, z.B. dass er in der Nähe des Tatorts war. Sind mehrere Personen in das Verbrechen involviert, können sie gegeneinander ausgespielt werden. - Ziel ist es, dem Verdächtigen ein Geständnis zu erleichtern und seine inneren Widerstände zu überwinden, z.B. sein Selbstwertgefühl.
  3. Der Verdächtige wird i.d.R. bislang jede Schuld bestritten haben. Je hartnäckiger er leugnet, um so unwahrscheinlicher ist es, dass er gesteht. Wiederholtes hartnäckiges Bestreiten der Schuld gilt als psychologischer Nachteil für den Vernehmenden. Wenn er sich darauf einlässt, entgleitet ihm die Kontrolle über das Verhör. Der Vernehmende tritt jedem Versuch entgegen, die Schuld zu bestreiten, und zwar sowohl verbal als auch mit Körpersprache. ("Stopp, einen Moment." mit einer ablehnenden Geste) 
  4. Verdächtige, denen es nicht gelingt, den Vernehmenden von ihrer Schuldlosigkeit zu überzeugen, tendieren gelegentlich dazu, das Verhör "auszusitzen" und die Kooperation einzustellen. Dies wird als Tiefpunkt für den Verdächtigen betrachtet und es ist nun wichtig, nicht den "Kontakt" zu ihm zu verlieren, sondern seine Widerstände zu überwinden.
  5. Der Verdächtige sollte in diesem Stadium des Verhörs einen niedergeschlagenen Eindruck hinterlassen. Nun muss die Aufmerksamkeit des Verdächtigen wieder gewonnen werden. Dazu wird emotionale Nähe geschaffen, i.d.R. durch "freundliche" Körpersprache, z.B. auch durch Körperkontakt.
  6. Da der Widerstand des Verdächtigen so gut wie gebrochen ist, reagiert er besser auf Appelle des Vernehmenden. Er appelliert direkt an Anstand, Ehre, Religion und zeigt sich abermals verständnisvoll und mitfühlend. Einige Verdächtige fangen nun zu weinen an, schließlich brechen sie emotional zusammen. Ein Blick ins Leere und komplette Stille sind oft ein Anzeichen, dass nun ein Geständnis folgt.
  7. Nun wird eine Alternativ-Frage gestellt, eine Frage, bei der zwei Antworten vorgegeben sind, die beide auf ein Schuldgeständnis hinaus laufen. Die eine Antwortsvariante bietet ein Geständnis ohne Gesichtsverlust an. Dem Verdächtigen wird dadurch eine Gelegenheit gegeben, eine Erklärung oder Entschuldigung für das Verbrechen zu geben, was aber auf ein Schuldeingeständnis hinaus läuft. Etwa 80% der Verdächtigen gestehen nun.
  8. Aus dem "Ansatz" in Schritt 7 wird nun ein vollständiges mündliches Geständnis. Dazu werden Details der Tat hinterfragt. Um den Verdächtigen nicht zu verunsichern, ist der Vernehmende zunächst alleine mit ihm. Später wird dann das Geständnis vor Zeugen wiederholt, falls keine schriftliches Geständnis erreicht werden kann.
  9. Das schriftliche Geständnis hat vor allem juristischen Wert.
Literaturhinweis: Fred E. Inbau, John E. Reid, Joseph P. Buckley III, Brain C. Jayne: Criminal Interrogation and Confesions, 4th Edition. - Das Buch wird regelmäßig zitiert, ich habe es aber selbst nicht gelesen.

"Mutt and Jeff" - Technik

Diese Befragungstechnik wird auch als friendly-unfriendly oder, im deutschen Sprachraum, als good guy - bad guy bezeichnet. Der Verdächtige wird dabei von zwei oder drei Vernehmern befragt, die jeweils eine freundliche bzw. moderierende und unfreundliche bzw. aggressive Rolle übernehmen. Arbeitet man zu dritt, so tritt einer jeweils als unfreundlich, moderat und freundlich zurückhaltend auf. Der Unfreundliche kritisiert dabei, kann laut, bedrohlich oder auch körperlich aggressiv sein, z.B. mit einem Tritt in den Bauch in weniger rechtsstaatlich orientierten Ländern, oder einen Tritt gegen den Tisch in zivilisierteren Gegenden. Der Moderator schickt dann den "ausgeflippten" Kollegen kurz raus, der Freundliche bietet vielleicht eine Zigarette an. Zweck ist es dabei vor allem, den Unterschied zwischen einem freundlichen und unfreundlichen Ansatz zu demonstrieren, wobei der Verdächtige sich eher dem freundlichen Vernehmer zuwenden wird.

Da diese Technik jedoch schon so abgedroschen und bekannt ist; jeder hat sie schon mal in einem Vorstellungsgespräch erlebt; sind die Gegenmaßnahmen hinlänglich bekannt. Dem Unfreundlichen wird freundlich begegnet, dem Freundlichen dagegen unfreundlich. Nicht zuletzt deshalb wechseln die Vernehmer dann ebenfalls die Rolle, es soll ja vor allem die Differenz zwischen beiden Verhaltensweisen demonstriert werden.

Die Technik kann als Teil anderer Techniken benutzt werden, z.B. in Stufe 3 der Reid-Methode.

Exkurs: Die üblichen Verdächtigen

Sowohl bei der Entwicklung als auch beim produktiven Einsatz von IT-Systemen lassen sich jeweils ein Paar üblicher Verdächtiger ausfindig machen, wobei die Verdächtigungen innerhalb des Paares auf Gegenseitigkeit beruhen.

Während der Entwicklung eines IT-Systems verdächtigt das Entwicklerteam die Fachanwender, nicht alle relevanten Informationen zu kommunizieren, nicht zu priorisieren, nicht rechtzeitig Arbeitspakete zu erledigen, sich zu weigern Entscheidungen zu fällen und generell nicht zu kooperieren. Im Gegenzuge verdächtigen die Fachanwender die IT-Leute, dass sie nicht alle Anforderungen umsetzen wollen, kein Verständnis für die Prioritäten des Fachbereichs aufbringen, das Projekt verschleppen, "offensichtlich" einfache Anforderungen verkomplizieren, das Projekt verteuern und generell nicht zu kooperieren.

Im produktiven Einsatz funktioniert gelegentlich ein IT-System nicht so, wie es der Fachanwender erwartet. Üblicherweise wird dann das IT-System und letztendlich das Entwicklerteam verdächtigt, einen Fehler gemacht zu haben. Die Beweislast wird dem IT-Team zugeschoben, aus einer juristisch korrekten Unschuldsvermutung wird eine IT-Schuldvermutung. Das IT-Team wiederum verdächtigt die Fachanwender, das System nicht korrekt zu bedienen. - Tatsächlich liegt bei einem etablierten System, das schon einige Monate oder Jahre im Einsatz ist, fast immer ein Bedienfehler vor. Da man allerdings die Nicht-Existenz von etwas nach üblicher wissenschaftlicher Denkweise nicht beweisen kann, bleibt es regelmäßig am IT-Team hängen, die Effekte des Systems nachzuvollziehen und dem Fachanwender am Ende seinen Bedienungsfehler nachzuweisen.

Fragetechnik in der Anforderungsanalyse

Wie schon mehrfach betont sucht man auch oder gerade bei IT-Projekten nach Lösungen, nicht nach Schuldigen. Gewisse Parallelen zu Vernehmungstechniken lassen sich zwar gelegentlich erkennen, die Ziele sind jedoch unterschiedlich. Im Rahmen einer Befragung soll der Befragte zur Kooperation bewegt werden: die Kooperation einer Person, die eines Verbrechens verdächtigt wird, wird mit einem Geständnis gleich gesetzt; die Kooperation eines Fachanwenders liegt ähnlich, er soll für die Entwicklung relevante Informationen liefern. Auf einen Verdächtigen kann Druck ausgeübt werden, die Kooperation kann bis zu einem gewissen Maß erzwungen werden. Ähnlicher Druck auf Fachanwender ausgeübt wird allerdings zu einer Blockadehaltung führen. Der Fachanwender kann das "Verhör" auch jederzeit abbrechen, ein eines Verbrechens verdächtigter allerdings nicht.

Nach meinen Erfahrungen eignet sich folgende Vorgehensweise am ehesten:
  1. Entspannung der Situation. Der Fachanwender soll sich sicher fühlen,  insbesondere muss er die Sicherheit haben, dass er für Fehler, die aus seiner Initiative und Unterstützung für das Projekt versehentlich entstehen, nicht bestraft wird.
  2. Darstellung eines Prozesses, der hinterfragt werden soll, z.B. durch einen Walkthrough.
  3. Eine starke positive Stimmung erzeugen, z.B. durch den expliziten Dank für die bisherige gute Kooperation und Anerkennung für erbrachte Leistungen. Hierdurch soll der Wille zur Kooperation gefördert werden.
  4. Hinterfragen, ob man selbst (also der Analytiker), einen Fehler gemacht hat. Appell an den Fachanwender, bei der Fehlersuche zu helfen. Situationsabhängig kann Unglaube ausgedrückt werden, dass der Prozess wirklich schon vollständig oder korrekt sei, man hat "ein intuitiv schlechtes Gefühl", könne dies aber nicht begründen. Alternativ kann der Glaube kommuniziert werden, dass der Prozess bereits richtig bzw. fast richtig sei, und man ein gutes Gefühl hat. Sofern man logische Widersprüche gefunden hat, oder aus einer anderen Quelle zusätzliche Informationen vorliegen, können diese als "Beweismaterial" dargelegt werden. Es ist die Regel, dass die erste Beschreibung eines Prozesses, die mit einem Fachanwender z.B. in einem Interview erarbeitet worden ist, logische Widersprüche enthält oder offensichtlich unvollständig ist. Die Vorlage solch "konkreten" Beweismaterials ist sehr wichtig, da sonst eine gewisse Gleichgültigkeit oder Gutgläubigkeit ("passt schon") entsteht, die die weitere Verbesserung bzw. Vervollständigung der Prozessbeschreibung untergräbt. Wichtig ist, dass das Beweismaterial nicht zu Vorwürfen führt, sondern als Aufhänger benutzt wird, der Prozess-Beschreibung zu misstrauen und sie zu verbessern.
  5. Korrektur der gefundenen Lücken bzw. Widersprüche, sofern welche vorhanden waren. Dabei werden klare ja-nein-Fragen gestellt. Alle Abweichungen vom Thema oder Sinndiskussionen werden strikt unterbunden. Man kann die Themen sammeln und später bearbeiten ("Ein guter Punkt, den ich mir notieren will. Lassen Sie uns darauf zurück kommen, wenn dieser Prozess korrigiert wurde." - Man sollte natürlich wirklich diesen Punkt später wieder aufgreifen.)
  6. Hinterfragen der Vollständigkeit des Prozesses.
  7. Hinterfragen der Richtigkeit des Prozesses.
  8. "Freundlichen" Druck erzeugen, z.B. durch die Aussage: "Ich bekomme ziemlichen Ärger, wenn der Prozess jetzt nicht korrekt und vollständig ist." oder "Es gibt keinen Weg zurück. Wenn die Implementierung erst begonnen hat, wird jede weitere Änderung sehr teuer." Damit soll erreicht werden, dass sich der Fachanwender auch noch nach dem Treffen mit der Thematik auseinander setzt, wobei es egal ist, ob dies bewusst oder unbewusst geschieht.
  9. Entspannung der Situation und Appell, sich die Prozesse nochmals durch den Kopf gehen zu lassen. Sofern es wahr ist, kann man z.B. sagen: "Ich habe jetzt ein gutes Gefühl, dass wir den Prozess korrekt abgebildet haben. Wenn Ihnen noch etwas einfällt, dann lassen Sie es mich wissen. Ansonsten beantrage ich übermorgen den Review."
  10. Rückfrage einen oder zwei Tage später, ob dem Fachanwender noch etwas eingefallen ist.
Bei all dem sollte man weder sich noch seinen Ansprechpartner belügen. Beim dritten Schritt sollte man Feedback-Regeln im Auge behalten: Zuerst das Positive, dann das Negative. War die Kooperation bislang nicht all zu gut, so kann man dies kommunizieren und Anregungen zur weiteren Arbeitsweise platzieren, muss aber darauf achten, keine Blockade-Haltung zu erzeugen.

Mich würde Ihre Vorgehensweise interessieren! Kontakt

Entspannung der Situation

Eine wie auch immer geartete Benutzerbefragung ist eine anstrengende Angelegenheit. Konzentriertes Arbeiten, evtl. verbunden mit Zeit- und Erfolgsdruck, ist nicht jedermanns Sache. Die Einleitung sollte eher zu einer entspannten Situation führen, in der sich der befragte Fachanwender sicher fühlt. Eine Tasse Kaffee zusammen mit einem kurzen Gespräch über den letzten Urlaub kann hier Wunder wirken. IT-Mitarbeiter und somit auch Analytiker werden häufig als Wesen aus einer fremden Welt betrachtet, man sollte also klar demonstrieren, dass man auch nur ein Mensch ist.

Nachdem die eigentliche Arbeit getan ist, sollte man sich auch noch ein paar Minuten gönnen, um die Anspannung wieder abfallen zu lassen. I.d.R. wird man dabei nochmals die Arbeitsergebnisse der Befragung rekapitulieren und sehr häufig fallen dann noch Unklarheiten auf. Evtl. gibt man sich auch noch Feedback, ob die Kooperation in dieser Form zufrieden stellend war und was man verbessern könnte.

Die ja-nein-Frage

Computer arbeiten binär, Software ist letztendlich nichts anderes als eine Abfolge von ja-nein-Verzweigungen. Für einen Menschen ist auch eine ja-nein-Frage die am leichtesten zu beantwortende Frage. Im echten Leben gibt es jedoch auf die ja-nein-Frage häufig noch eine dritte Antwort: ich weiß es nicht, bzw. ich bin mir nicht sicher. Für eine Analyse ist es weitaus besser, ein ehrliches "ich weiß es nicht" zu hören und die korrekte Klärung der Frage abzuwarten, als eine vermeintlich korrekte Antwort zu erhalten, die die weitere Analyse nachhaltig beeinflusst und die Wochen später revidiert wird.

Typische ja-nein-Formulierungen sind:
Stellt man eine ja-nein-Frage und der Befragte antwortet mit ausschweifenden Erklärungen, ohne ein klares Ja oder Nein von sich zu geben, dann ist die Situation verdächtig. Wahrscheinlich hat man die falsche Frage gestellt: was dem Frager einfach erscheint, ist in Wirklichkeit eine längere Geschichte. Man beachte hierbei eine alte Analytikerweisheit: "All difficult questions have a simple answer. And it is wrong." - Alle schwierigen Fragen haben eine einfache Antwort. Und sie ist falsch.

Das Antwort-Verhalten kann allerdings auch in der Person des Befragten liegen. Manche Menschen geben prinzipiell keine direkten Antworten; dann muss man hartnäckig bleiben. Es ist aber auch möglich, dass der Befragte die Frage gar nicht verstanden hat, und nicht den Weg einer direkten Rückfrage ("Das habe ich nicht verstanden, können Sie es mir nochmals erklären?") wählt, sondern das fehlende Wissen auf etwas verschlungenen Pfaden durch eine Diskussion erarbeiten will, oder ganz einfach nicht zugeben will, dass er die Frage nicht verstanden hat.

Gelegentlich will aber der Befragte nur vom Thema ablenken um eine Festlegung zu vermeiden, in politisch verzwickten Situation gar, um Verwirrung zu stiften. Eine Rückfrage ("Ich hatte eine Frage gestellt, die man mit ja oder nein beantworten kann. Ich verstehe nicht, weshalb dies nicht geschieht.") ist angezeigt, will man nicht versehentlich Antworten auf Fragen bekommen, die nicht gestellt wurden oder wesentliche Entscheidungen offen lassen.

Frage nach Vollständigkeit

Die Frage nach der Vollständigkeit bedeutet lediglich, dass es für jeden Weg in ein System hinein, also für jede Eingabe, auch einen Weg hinaus gibt. Für alle bekannten Daten lassen sich z.T. recht formale, z.T. intuitive Beweisverfahren abarbeiten. Offen bleibt, was der Fachanwender alles nicht gesagt hat. Sehr häufig arbeiten Fachanwender nicht mit Regeln sondern mit Beispielsammlungen. Dabei werden zwar seltene, aber wichtige Ausnahmen übersehen.
Beispiel aus der Praxis

Im Börsenbereich gibt es den Begriff "Pennystock". Darunter versteht man alle Aktien, deren Kurswert kleiner als ein Euro bzw. ein Dollar ist. Für eine Anwendung wurde eine Aktienauswahl von ca. 600 Werten getroffen. Das vom Kunden kommunizierte Regelwerk schloss Operationen auf Pennystocks im Rahmen der Anwendung aus. Hieraus ließen sich bereits in der Frühphase der Analyse logische Fehler in der Anwendung nachweisen, da ein Wert zwar anfangs oberhalb eines Euros notieren, jedoch im Laufe der Zeit bei sinkenden Kursen zum Pennystock werden konnte. Der Kunde gab hierzu die Auskunft, dass so etwas bei den ausgewählten Werten praktisch nicht vorkommen könne. Ein vom Analytiker als Domain-Experte befragter früherer Börsenhändler wollte gar eine Wette darauf abschließen. Eine Sichtung des Datenmaterials ergab jedoch, dass etwa ein Prozent der Werte knapp oberhalb eines Euros notierten, durchweg Werte nicht-europäischer Unternehmen, die der frühere Börsenhändler niemals näher betrachtet hatte. Im Laufe der folgenden Tage nach der Sichtung fielen tatsächlich einige Werte unter einen Euro. Die Erweiterung des Regelwerks für diesen praktisch nicht vorkommenden Fall war unvermeidbar.
Typische Fragen, die gestellt werden können, um die Vollständigkeit zu gewährleisten, sind:

Frage nach Korrektheit

Eine Frage nach Korrektheit ist fast eine ja-nein-Frage, jedoch wird der Befragte dabei ermuntert, seine Überlegungen laut kund zu tun. Bei der Korrektheit geht es darum zu beweisen, dass ein Verfahren auch das tut, was sich der Fachanwender vorstellt. Diese Vorstellung kann erheblich von dem abweichen, was kommuniziert und auch dokumentiert wurde. An einer anderen Stelle auf diesen Seiten wurde ein Fallbeispiel zitiert, in dem ein Fachanwender von ihm selbst definierte Preisstaffeln nicht mehr nachvollziehen konnte. Korrektheit kann man nur anhand konkreter Szenarien nachweisen, man führt sozusagen einen Schreibtischtest aus. Sehr viele Fachanwender zeigen aber eine moderate Verweigerungshaltung, wenn es darum geht, mit Zeit- und Arbeitsaufwand Prozesse im Detail nachzuvollziehen, von denen man doch weiß, dass sie richtig sind.

Typische Fragen, um die Korrektheit einer Aussage zu gewährleisten, sind:

Exkurs: Eskalation

Allgemeines

Die Eskalation ist ein Standardvorgehen im Konfliktfall. Normalerweise lösen Mitarbeiter entstehende Konflikte innerhalb eines Projekts auf gleicher Ebene nach sachlichen Kriterien und technischen Erfordernissen. Es kommt jedoch regelmäßig vor, dass die Priorisierung der anstehenden Fragestellung für beide Mitarbeiter so hoch ist, dass sie den Konflikt nicht selbst lösen können bzw. im Rahmen einer eigenverantwortlichen Entscheidung ihre Kompetenzen überschreiten würden. In diesem Fall wendet man sich an eine Schlichtungsstelle. Dies kann der gemeinsame Vorgesetzte sein, in der Projektarbeit ist die erste Eskalationsstufe i.d.R. der Projektleiter. Liegt der Konflikt projekt- oder abteilungsübergreifend, dann lässt man den Konflikt von seinem Vorgesetzten oder Projektleiter erledigen. Letzteres ist der Regelfall, wenn ein Konflikt zwischen Fachabteilung und IT-Projektgruppe entsteht.

Die Nicht-Anwendung dieses Standardvorgehens äußert sich meist darin, dass ein Problem im Kreise herum geschoben wird, mehrfach an bestimmten Leuten vorbei segelt, aber nicht gelöst wird. Das Unverständnis des Eskalationsverfahrens kann dabei ziemliche Blüten treiben und wird auf jeden Fall ein Zeitkiller, Kostentreiber und es ist für die Projektmitarbeiter frustrierend.

Beispiel aus der Praxis (aus einer Zuschrift)

In einem Projekt im Gesundheitswesen sollte ein OP-Planungssystem eingeführt werden. Für die Analysephase wurden ein OP-Pfleger und zwei Ärzte als Ansprechpartner benannt.  Einer der Ärzte wollte bestimmte Dokumente zur Datenerfassung erstellt haben. Der Wunsch war kein wirkliches Problem, der Arzt schickte den sogenannten DGAI-Kerndatensatz zum Fachberater des beauftragten Systemhauses, der daraus ein Konzept entwarf. Dabei entstanden einige Fragen, die dem Arzt zugestellt wurden. Damit begann eine der wohlbekannten Endlosschleifen: Der Arzt schickte das gleiche Dokument nochmals mit dem Kommentar, der Fachberater solle es doch bitte aufmerksam lesen, da stünde alles drin. Das ging mehrere Male so hin und her, bis es zum Projektleiter eskaliert wurde (vom Systemhaus, nicht vom Arzt, der im Hause des Projektleiters Mitarbeiter war). Die Zuschrift endete mit dem Satz: "Die Probleme ließen sich in einer moderierten Telefonkonferenz in etwa 20 Minuten beheben, aber durch die präferierte Vorgehensweise waren etwa 4 Wochen Projektzeit verloren gegangen."

In der Zuschrift zeigt sich noch ein zusätzlicher kritischer Punkt: Sitzt der Projektleiter beim Auftraggeber, so wird der Auftragnehmer stets etwas zurückhaltender sein, einen Konflikt zu eskalieren, auch wenn er offensichtlich von einem Mitarbeiter beim Auftraggeber verursacht wurde. Den konkreten Fall kann man durchaus als Verletzung der Mitwirkungspflicht des Auftraggebers werten. Das Prinzip der Eskalation ist im Hause nicht verstanden worden, noch schwerer wiegt aber, dass der Projektleiter überhaupt erst nach 4 Wochen vom Konflikt erfahren hatte. Weiterhin zeigt das Beispiel, dass bei der Interaktion ein grundsätzlicher Fehler gemacht wurde: Wird eine Informationsmenge (z.B. einige Dokumente) zur Verfügung gestellt, und auf Basis dieser Informationsmenge werden Fragen gestellt, dann darf nicht einfach davon ausgegangen werden, dass die ursprüngliche Informationsmenge ausreicht. Statt dessen sollten die Fragen ganz einfach beantwortet werden.

Die Eskalation will verstanden sein!

Die Eskalation ist wie bereits erwähnt ein Standardverfahren, allerdings eines, das häufig nicht verstanden wird

Niemand würde heutzutage noch auf die Idee kommen, sich auf Grund einer Streitigkeit zu Duellieren, statt dessen wird eine Schlichtungsstelle oder ein Gericht angerufen. Ungeachtet dessen gibt es eine Menge Leute, die eine Eskalation mit petzen ("kann nichts informell regeln"), Sturheit oder Uneinsichtigkeit ("gibt nie nach"), Unselbständigkeit ("traut sich nicht, etwas selbst zu entscheiden") oder Geltungssucht ("will sich profilieren") gleichsetzen. Beschreitet man den Eskalationsweg vernünftig, so ist dies nicht der Fall.

Allerdings gibt es auch tatsächlich einige Leute mit sozialen Defiziten, die Eskalationen strategisch und nicht sachlich einsetzen oder es doch versuchen. Entscheidend sollten am Ende stets die besseren Argumente sein. Insofern kann man der Eskalationsinstanz durchaus nach Darstellung der objektiven Sachlage mitteilen, dass man selbst der Meinung ist, dass die Eskalation nicht sachlicher Natur war. Ihr Vorgesetzter wird sich seinen Teil denken, und zwar i.d.R. den richtigen.

Sofern die eigenen Kompetenzen klar abgegrenzt sind, kann man auch selbst entscheiden und eine Angelegenheit regeln, sei es nun auf formellem oder informellem Wege. Die Eskalation wird nur dann notwendig, wenn man außerhalb der eigenen Kompetenzen handeln müsste. Häufig reicht schon eine informelle Rückfrage beim Projektleiter, ob ein fraglicher Konflikt auf eine bestimmte Weise eigenverantwortlich gelöst werden kann.

Frustrierend wird es bei einer "save my arse"-Mentalität. Geht die Kontrolle in einem Projekt verloren und beginnt langsam die Suche nach Schuldigen, anstatt nach Lösungen, dann tendieren manche Leute dazu, jede Kleinigkeit zu eskalieren. Sofern man seinen Job gut gemacht hat und auch solide belegen kann, dass man die fragliche Kleinigkeit nicht perfekt genug erledigt hat, weil man wichtigeres zu tun hatte, kann man solch eine Eskalation schulterzuckend akzeptieren und stets auf die Unsinnigkeit derselben hinweisen. Da Kosten stets das Hauptargument sind, wird es lächerlich, wenn die Eskalation selbst teurer wird, als der Streitgegenstand. Nützlich ist es dann, bei der Eskalationsinstanz seine Tätigkeiten recht genau nachzuweisen und um eine Priorisierung zu bitten. Die Grundidee dahinter ist, dass die strategischen Unternehmensentscheidungen und daher die Priorisierung von Konflikten ("Was ist zu tun, was ist wichtig?") stets eine Frage des Managements und nicht der ausführenden Stellen ist.

Beispiel aus der Praxis

In einem Projekt kochten die Emotionen langsam über. Schließlich wurde jeder Pfurz eskaliert. Die Blüte war schließlich, dass ein Mitarbeiter eine Präsentation zum Projektstatus aus dem Stegreif machte, anstatt sie mit einer schönen Präsentationssoftware mit einigen Stunden oder Tagen Vorbereitungszeit durchzuführen. Der Vorfall wurde eskaliert Der Mitarbeiter konnte belegen, dass er ca. 50h/Woche damit beschäftigt war, die Produktion sicher zu stellen und für die optisch ansprechende Vorbereitung einer rein berichtenden Präsentation beim besten Willen keine Zeit hatte. Er stellte lediglich lakonisch die Frage, ob die Produktion wegen der Vorbereitung der Präsentation unterbrochen werden sollte, dann war das Thema erledigt.

Eskalationswege

In jedem Projekt sollte es zwei formell definierte Eskalationswege geben:
  1. Die reguläre Eskalation für den Fall, dass ein Konflikt auf gleicher Ebene nicht gelöst werden kann.
  2. Die Eskalation am Vorgesetzten vorbei, für den Fall, dass die Loyalität des Vorgesetzten in Frage gestellt werden muss, der Vorgesetzte den eigentlichen Konfliktpunkt darstellt (z.B. weil er jede Form von Initiative der Projektmitarbeiter blockiert und bestraft), oder der Vorgesetzte den Konflikt nicht befriedigend löst (meist mangels Sachkompetenz, die zur Entscheidung notwendig ist, gepaart mit mangelnder sozialer Kompetenz, dies auch zuzugeben und andere um Hilfe zu bitten).
Es ist guter Stil, die Eskalationswege bereits in der Einladung zum Kickoff-Meeting eines Projekts festzuschreiben.

Die reguläre Eskalation wird idealerweise einvernehmlich vorgenommen. Die betroffenen Mitarbeiter stellen dabei gemeinsam fest, dass sie nicht in der Lage sind, den Konflikt zu lösen, sammeln gemeinsam ihre Argumente und formulieren auch gemeinsam Lösungsvorschläge, die dann der nächsten Eskalationsstelle vorgetragen werden. Dieses Vorgehen ist in professionellen Arbeitsumgebungen der Normalfall. Die Alternative zu dieser Form der Eskalation ist eine simple Nicht-Erledigung des anstehenden Arbeitspakets. In seltenen Fällen verweigert eine der beteiligten Parteien die gemeinsame Eskalation. Dann bleibt nichts anderes, als die Eskalation nicht einvernehmlich durchzuführen, will man nicht auf bessere Zeiten warten. Solch eine Verweigerungshaltung hat grundsätzlich keine sachlichen Gründe, das Vertrauensverhältnis zwischen den Parteien ist dann meist schon gestört.

Die Eskalation am Vorgesetzten vorbei, also das Überspringen einer Eskalationsstufe, sollte wohl überlegt vorgenommen werden. In der Praxis ist dies eine seltene Ausnahme. Betroffen ist normalerweise der eigene Projektleiter, und die Gründe für eine Eskalation an der ersten Vertrauensperson im Projekt vorbei liegen auf der Hand: der Projektleiter ist entweder technisch oder sozial inkompetent, oder er verfolgt offensichtlich (persönliche) Ziele, die nicht mit dem Projektziel überein stimmen. Man sollte stets davon ausgehen, dass die angerufene Instanz die übersprungene Instanz anspricht. D.h., dass man genügend Material in der Hand haben muss, um die Eskalation zu begründen. Typischerweise betreffen solche Eskalationen bzw. Beschwerden stets dieselben Mitarbeiter, und man hat nur dann Ärger zu erwarten, wenn man der Erste ist, der ein konsequentes Fehlverhalten seines Projektleiters bemängelt. Man sollte keinesfalls beim ersten Zweifel an seinem Projektleiter diesen Eskalationsweg beschreiten, dagegen sollte der Projektleiter direkt auf die Effekte seines Verhaltens angesprochen werden. Zeigt sich der Projektleiter jedoch uneinsichtig und die anderen Teammitglieder oder der Kunde bemängeln ähnliche Schwierigkeiten (d.h. man steht mit seiner Überzeugung offensichtlich nicht alleine da), dann lässt sich im Sinne des Projekterfolgs eine Eskalation nicht vermeiden. Der Normalfall ist, dass solche Projektleiter früher oder später abgelöst und schließlich unter irgend einem Vorwand gekündigt oder weg gelobt werden.
home - top - Kontakt - letzter Update 14.6.2004 - © Karl Scharbert