Nutzen Sie in Ihrer Projektarbeit auch die neuesten, zeitoptimierten Prozessmodelle, während flache Organisationsstrukturen für Synergieeffekte sorgen und Ihre Mitarbeiter und Kollegen dank entsprechender Schulungen zu richtigen Teamplayern avanciert sind? Oder klingt das für Sie nach reiner Utopie? Dann leben Sie vermutlich in der realen Welt und arbeiten mit Menschen aus Fleisch und Blut zusammen. Wenn in dieser Welt etwas nicht so funktioniert wie es funktionieren sollte, wie es geplant und vereinbart war, kann das verschiedene Gründe haben – oft ist die eigentliche Ursache jedoch ein ungelöster Konflikt.
Wie die Erfahrung zeigt, ist für viele Menschen die eigene Stellung im Unternehmen oft wichtiger als die tatsächliche Arbeit. Ein Gesichtsverlust wird vehementer bekämpft als ein Scheitern des Projekts. Gegen den einen oder anderen Kollegen wird deshalb einfach aus Prinzip mit dem Säbel gerasselt – nur weil dieser einem immer den Firmenparkplatz oder die Lieblingskaffeetasse wegschnappt (Senge, 2006).
Solche Konflikte, die oft im Verborgenen schwelen, sind Sand im Projektgetriebe und mit eine Ursache dafür, wenn es zu Budgetüberschreitungen kommt oder Zeitlimits sang- und klanglos überschritten werden. Wenn Konflikte auftauchen, dann meist in der Phase des Requirements Engineering. Dort kann hervorragend über Anforderungen gestritten und das Projekt frühzeitig sabotiert werden.
Da der Requirements Engineer als Außenstehender meist nicht hinter die Kulissen blickt, stellt sich für ihn oft die Frage: "Was ist denn passiert? Das hatten wir doch abgestimmt, das war doch ausgemacht, das haben doch Sie selbst vorgeschlagen ...". Um das Projekt voran zu bringen, bleibt ihm daher nichts anderes übrig, als die Ärmel hochzukrempeln, die Beteiligten an einen Tisch zu rufen und den Konflikt zu bereinigen.
Es gibt allerdings auch Konflikte, die weniger tiefgreifende Ursachen haben und vor allem auf die unterschiedliche Interpretation eines Sachverhalts oder Begriffs zurückzuführen sind. Werden solche Missverständnisse nicht frühzeitig aufgedeckt, entstehen daraus ebenfalls Konflikte, die den Fortschritt des Projektes blockieren.
Im Folgenden gebe ich Ihnen einen Überblick über bewährte Methoden, Requirements-Konflikten vorzubeugen oder diese aufzulösen. Bei einigen Konfliktarten wird Ihnen die Lösung mit Hilfe der genannten Methoden leicht fallen. Andere Konfliktfälle können Sie auf diese Weise lediglich versachlichen und damit das konkret anstehende fachliche Problem lösen, den dahinter schwelenden Konflikt allerdings nicht.
Bild 1: Definition des Requirements Engineering.
Ein altes Sprichwort besagt: "Du musst den Brunnen graben, bevor du Durst hast". Dieses Prinzip lässt sich auch auf das Requirements Engineering übertragen. Sinngemäß würde es dort lauten: Einfacher als einen bereits entstandenen Konflikt zu lösen, ist es, seine Entstehung zu verhindern oder diese zumindest zu hemmen.
Einer der Konfliktherde, die wir während der Projektarbeit am häufigsten beobachten, ist die Sprache. Wenn die Bedeutung gebräuchlicher Begriffe von Abteilung zu Abteilung abweicht, sind Konflikte vorprogrammiert. Solchen Konflikten lässt sich jedoch durch ein gemeinsames Glossar leicht der Nährboden entziehen. Denn eine gemeinsame Sprachwelt sorgt für ein gemeinsames Verständnis (Rupp, 2009).
Ein gutes Beispiel dafür ist der Ausdruck "Abnahme". Für den einen Fachbereich bedeutet "Abnahme", dass alle Altdaten migriert wurden, alle potentiellen Nutzer anhand spezifischer Trainingsunterlagen geschult wurden und das System einsatzbereit ist. Ein anderer Fachbereich versteht unter "Abnahme" lediglich die Prüfung, ob die vom Lieferanten zur Verfügung gestellte Software den vorgegebenen Anforderungen entspricht. Das schließt keine Aussagen zur Einsatzfähigkeit ein, da die neue Software noch nicht im System aufgespielt wurde. Aus solchen widersprüchlichen Vorstellungen entsteht schnell ein Konflikt. Führen sie deshalb ein Glossar ein, in dem interpretierbare Begriffe genau definiert werden.
