Kategorie-Archiv: IT-Governance

Sowohl die Zusammenarbeit wie auch Konflikte gehören zu unserem täglichen Leben. Meist wird Zu­sammenarbeit als wünschenswerter Idealzustand angesehen, Konflikte hingegen als unerwünschte Störung, die unbedingt zu vermeiden ist.

Meiner Meinung nach sollte man Kooperation und Kon­flikt als zwei Seiten derselben Medaille sehen. Das Problem sind nicht die Konflikte an sich, sondern vielfach die Art, wie mit ihnen umgegangen wird. Reibung erzeugt Energie. Konflikte können zu kreativen, neuen Lösungen führen, die eine Organisation flexibel und anpassungsfähig werden lassen – können aber auch zersetzend wirken und ein Projekt oder ein ganzes Unternehmen zum Scheitern bringen. Entscheidend für diese unterschiedlichen Auswirkungen ist die Fähigkeit der Beteiligten, Konflikte konstruktiv zu bewältigen. Aber was ist „konstruktiv“ und wie macht man das?

Es mag Naturtalente der Konfliktbewältigung geben, aber selbst Talente profitieren von Wissen, es gibt ja bekanntlich nichts Praktischeres als eine gute Theorie (so Kurt Lewin).

Wir beschäftigen uns hier nicht mit inneren Konflikten, wenn ich mich z.B. zwischen zwei Alternativen entscheiden muss, die beide große Vorteile, aber auch große Nachteile haben. Das fällt in die Rubrik Entscheidungstechnik, wenn man es rational betrachtet, in die Rubrik Mentaltraining, wenn man die emotionale Seite betrachtet. Empfehlenswert ist es, beide Aspekte gleichermaßen zu berücksichtigen, aber darüber an anderer Stelle mehr.

Wir sprechen hier davon, wenn verschiedene Personen Handlungsalternativen vertreten, die ihnen als un­vereinbar erscheinen und einander an der Verwirklichung dieser Alternativen zu hindern suchen. Nehmen wir eine typische Projektsituation: Soll man den Termin verschieben oder nicht? Soll man ein Feature zur Realisierung frei geben, ganz streichen oder auf eine spätere Projektphase verschieben?

Es gibt zwei grundlegend verschiedene Konfliktarten 

Es ist eine grundlegende Weichenstellung für das Konfliktmanagement, die Art des aktuellen Konflikts zu erkennen. Konkret: Ist es ein Zielkon­flikt oder ein Methodenkonflikt? Damit es nicht zu einfach wird, gibt es natürlich auch Mischformen, aber dazu später.

Ein Zielkonflikt liegt vor, wenn z.B. externe Projektmitarbeiter an einer Aufstockung des Budgets interessiert sind und daher für die Erweiterung des Scope und die Verschiebung des Termins eintreten. Manche IT-Unternehmen beschäftigen bekanntlich professionelle Claim-Manager, die jedes Ereignis im Projekt darauf abklopfen, ob sich daraus eine Erhöhung der Auftragssumme ableiten ließe.  Auf der anderen Seite steht z.B. der Auftraggeber und der interne Projektleiter, die daran interessiert sind, die im Projekt gebundenen Ressourcen so schnell wie möglich frei zu bekommen, um ein anderes, wichtiges und dringendes Vorhaben umzusetzen.

Damit es nicht so ausschaut, als wären immer die Externen die Bösen, ein anderes Beispiel, ebenfalls aus der Praxis: die internen Mitarbeiter sehen den Auswirkungen des Projektes zur Einführung eines neuen IT-Systems mit Skepsis entgegen; sie erwarten sich dadurch Effizienzsteigerungen und damit Personaleinsparungen und mehr Stress. Sie sind daher daran interessiert, die Produktivsetzung möglichst zu verzögern. Daher werden Features gesucht und gefunden, die man glaubhaft als unverzichtbar darstellen kann. Durchaus oft auf der gleichen Seite die Claim-Manager eines IT-Dienstleisters, auf der anderen Seite wiederum Auftraggeber und interner Projektleiter,

Das sind Interessensgegensätze, denen man ins Auge blicken muss. Sie sind unangenehm, moralisch vielleicht fragwürdig, aber meist legitim und jedenfalls oft existent und wirksam.

Ein Methodenkonflikt liegt vor, wenn die Kontrahenten ein gemeinsames Ziel haben, jedoch unterschiedliche Vorstellungen vertreten, wie dieses Ziel erreicht werden kann bzw. soll. Wieder aus Praxis: Alle wollen Termin und Budget halten, aber die einen meinen, dies durch ein striktes Wasserfallmodell am sichersten zu erreichen, die anderen meinen, dass ein agiles, iteratives Vorgehen dafür am besten geeignet ist.

Oder viel banaler, aber häufig. Soll mit regelmäßigen Meetings gearbeitet werden oder geht es in Einzelarbeit mit Meetings, die anlassbezogen vereinbart werden, besser?

In allen genannten Fällen ist es nicht offensichtlich und zweifelsfrei entscheidbar, welche Methode die bessere ist. Es kommt auf so viele situationsspezifische Faktoren an, dass auch Erfahrungen aus anderen Projekten keine sichere Basis für eine Entscheidung bieten.

Manchmal tarnen sich auch Zielkonflikte als Methodenkonflikte. Das Drängen auf ein genaues und verbindliches Pflichtenheft und die Abwehr eines iterativen Vorgehens kann auch dadurch motiviert sein, dass Claim-Manager damit rechnen, auf diese Weise durch Change-Requests die Budgetvorgaben später auszuhebeln. Der Vorschlag klingt aber vordergründig sehr überzeugend und kommt auch dem Kontrollbedürfnis des Managements entgegen („Wir wollen endlich wissen, was Scope des Projekts ist und was nicht und was es kosten wird!“). Wer wagt hier zu widersprechen ohne sich dem Verdacht auszusetzen, Planungssicherheit und Verbindlichkeit nicht ernst zu nehmen. Aber es kann auch umgekehrt sein, das iterative Vorgehen ist der Hebel, um mit einer „Salami-Taktik“ die eng gewordenen Budgetvorgaben aufzubrechen oder ist schlicht Ausfluss des Versuchs, sich auf nichts festlegen zu müssen, weil das mit Mühen und Unbequemlichkeiten verbunden ist.

Es ist offensichtlich, dass der Weg zur Konfliktbewältigung unterschiedlich sein wird, je nachdem, ob es einen Zielkonflikt oder einen Methodenkonflikt gibt. Für eine Konfliktbewältigung ist daher Klarheit über die Konfliktur­sachen wichtig.

Es gibt zwei typische Konfliktursachen

Konflikte können dadurch entstehen, dass den Konfliktbeteiligten unterschiedliche Informationen vorliegen oder dass sie von unter­schiedlichen Wertvorstellungen ausgehen und an sich gleiche Infor­mationen unterschiedlich beurteilen.

Ziele und Vorstellungen darüber, wie ein Ziel erreicht werden kann, können durch unterschiedliche Informationen zum gleichen Problem bei den Konfliktpartnern zum Konfliktgegenstand werden. Die Konfliktursache sind Informationsfaktoren. 

Die Konfliktursache können aber auch unterschiedliche Wertvorstellungen sein. Nehmen wir z.B. eine ausgeprägte egozentrische Grundeinstellung, die darauf abzielt, stets möglichst viel für sich heraus zu holen, auch wenn das zu Lasten anderer geht. Wenn Menschen mit dieser Grundeinstellung z.B. auf Betriebsräte treffen, dann gibt es einen lupenreinen Wertkonflikt: Wahrung der Interessen der Mitarbeiterinnen und Mitarbeiter an guten Arbeitsbedingungen gegen Ergebnismaximierung bis ans Limit der Belastbarkeit der Betroffenen.

Konflikte, die aus unterschiedlichen Wertvorstellungen der Beteiligten resultieren, sind gefährlich, schwer zu kontrollieren und schwer zu lösen. Das weiß jeder, der die Sprengkraft religiöser Konflikte beobachtet, wozu wir in vielen Weltgegenden leider auch heute noch Gelegenheit haben. Es ist aber nicht so lange her, dass auch in Mitteleuropa heftige Religionskriege ausgetragen wurden und die Ära des Nationalsozialismus war ja auch von fundamentalen Wertdifferenzen geprägt. Letzten Endes kann man nur auf einen „Deal“ hinarbeiten, bei dem jede Seite von der Durchsetzung ihrer Wertvorstellungen Abstriche macht. Das ist ja das Wesen einer liberalen Gesellschaftsordnung und der historisch gesehen bisher erfolgreichste Versuch, Wertkonflikte zu entschärfen. Dies ist ein Blog über Projektmanagement und wir wollen diesen Verweis auf politische Konflikte nur dazu verwenden, um das Wesen von Wertkonflikten zu verdeutlichen und nicht weiter darauf eingehen.

Innerhalb von Unternehmen und innerhalb von Projekten gibt es natürlich auch unterschiedliche Wertvorstellungen, die Brisanz ist allerdings deutlich geringer; wer sich mit den vorherrschenden Wertvorstellungen gar nicht identifizieren kann, wechselt das Unternehmen bzw. verlässt das Projekt. Unterschiedliche Wertvorstellungen führen zu unterschiedlichen Führungsstilen, beeinflussen den Umgang mit Informationen, bestimmen die Grenzen der gewählten Maßnahmen, wofür und in welchem Ausmaß also gilt der Grundsatz: „Der Zweck heiligt die Mittel“.

Tom DeMarco u.a. beschreiben sehr anschaulich typische Verhaltensmuster in Projekten. Zwei Typen geben diesem großartigen Buch den Titel: „Adrenalin Junkies & Formular Zombies“. Ein paar Zeilen aus der Beschreibung der „Adrenalin-Junkies“ helfen uns bei der Analyse weiter: „Adrenalin-Junkies sind davon überzeugt, dass die beste Art, Arbeit zu erledigen, definitiv nicht in sorgfältiger Planung besteht, sondern einfach darin, so schnell wie möglich zu arbeiten – egal was. Diese Arbeitsweise setzt verzweifelte Dringlichkeit mit effektiver Leistung gleich. … Teams, die jedes Wochenende am Arbeitsplatz erscheinen, gelten mehr als Teams, die einer geregelten Arbeitszeit nachgehen“ (a.a.O., S. 4).

Auf den ersten Blick repräsentieren Adrenalin-Junkies eindeutig ein bestimmtes Wertsystem. Das wird auch durch Aussagen nahegelegt, wie z.B.: „Wenn Sie zu denjenigen gehören, die nicht ständig Überstunden leisten und keine hektische Betriebsamkeit ausstrahlen, sind Sie ‚keiner von uns‘. … Unheroischer Einsatz gilt schlicht als nicht akzeptabel“ (ebenda). 

Wenn man genauer hinschaut, erkennt man, dass differente Werte das Resultat von Erfahrungen sind, also letztlich auch auf Informationsfaktoren beruhen, die allerdings über längere Zeit wirksam waren. Wer in seiner Projektarbeit regelmäßig Manager erlebt hat, die Adrenalin-Junkies sind, dem fehlt die Erfahrung, dass Projekte auch ohne Hektik erfolgreich sein können. Obwohl es so ist, dass gerade diese hektische Betriebsamkeit die Probleme verursacht, als deren Lösung sie sich ausgibt.

Über lange Zeit kumulierte Erfahrung lässt sich nicht mit ein paar Worten ändern, es braucht entsprechend starke Impulse, die sowohl Wissen als auch Emotionen wirksam adressieren. Beispiele von Projekten, in denen ein optimales Gleichgewicht von Planung und Flexibilität herrscht, in dem möglichst viel nach klaren und stabilen Regeln abläuft und dazu genügend Raum für die Reaktion auf unerwartete Ereignisse bleibt, sind der wirkungsvollste Impuls, solche Wertvorstellungen ins Wanken zu bringen und für neue Werte zu öffnen. Systematische Entwicklung der Unternehmenskultur als unterstützendes Umfeld wird für den langfristigen Erfolg wohl unabdingbar sein. Aber damit sind wir schon bei der Therapie, bevor wir noch die Diagnose vervollständigt haben.

Konflikte nutzen gerne Tarnkappen

Für den Umgang mit Konflikten ist ein weiteres Phänomen wichtig, das besonders in hierarchisch gegliederten Organisationen auftritt: die Konfliktverschiebung. Wenn ein Konflikt zwischen zwei Personen nicht ausgetragen wird, weil z.B. einer der beiden hierarchisch niedriger steht und negative Konsequenzen befürchtet, kann dieser unterdrückte Konflikt in einer anderen Situation Triebfeder eines Konfliktes sein.

So kann z.B. eine Meinungsverschiedenheit über die Leistungsbewer­tung zwischen einem Vorgesetzten und einem unterstellten Mitarbei­ter nicht ausgetragen werden, weil der Mitarbeiter weitere schlech­te Beurteilungen befürchtet. Im Zusammenhang mit Überstunden kann sich dieser Konflikt, jetzt mit einem neuen Inhalt, wieder entzünden. In diesem Fall wurde der Konflikt auf einen weniger be­drohlichen Inhalt „verschoben“. Wir sprechen in diesem Fall von einer Konfliktinhaltsverschiebung.

Andererseits kann dieser Mitarbeiter, der sich über eine seiner Meinung nach ungerechte Leistungsbeurteilung ärgert, einer Auseinandersetzung mit seinem Vorgesetzten aber aus dem Weg geht, die Beurteilung eines Kollegen kritisieren. Hier wird dann der soziale Konflikt mit einem „stellvertretenden“ Konfliktpartner ausgetragen. Entsprechend bezeichnen wir diese Art der Konfliktverschiebung als Konfliktadressatenverschiebung.

Diese beiden Formen der Konfliktverschiebung können die Analyse eines Konfliktes und auch seine konstruktive Bewältigung erschweren. Auch den Konfliktbeteiligten ist dieser Mechanismus nicht immer be­wusst. Ergänzend zur Analyse der Konfliktursachen ist also auch zu untersuchen, ob der Gegenstand eines Konfliktes überhaupt jener ist, den man auf den ersten Blick erkennt.

Wir fassen also zusammen:

Die Notwendigkeit einer Konfliktanalyse, in der festgestellt wird, ob Ziele oder Methoden, Werte oder Informationen bei einem Konflikt die Ursache sind, sollte deutlich geworden sein. Wer diese Fragen stellt, hat schon einen großen Schritt zum erfolgreichen Konfliktmanagement getan.

Wenn differente Ziele die Hauptursache sind, dann muss ein Interessensausgleich gesucht werden. Wie dieser aussehen kann, ist eine Frage der Strategie, der Entwicklung eines möglichen Lösungsszenarios mit Bandbreiten, in der Mathematik spricht man von einem Lösungsraum. Was potenzielle Lösungen sind, die von allen Beteiligten akzeptiert oder zumindest hingenommen werden, kann man nicht a priori festlegen, das wird sich im Verlaufe des Konfliktes ändern. Es können neue Optionen dazu kommen und bisher in Betracht gezogene Szenarien ausscheiden.

Sind Zielkonflikte Ausdruck von unterschiedlichen Wertvorstellungen, ist die Kompromissfindung schwieriger, wahrscheinlich auch stärker emotional belastet als bei Zielkonflikten, die eher sachlicher Natur sind.

Ein Beispiel für eher sachlich begründete Zielkonflikte: Ist es möglich, den vorgegebenen Termin zu verschieben oder hat das für das Unternehmen derart katastrophale Folgen, dass man alles daran setzen muss, den Termin zu halten. Fast immer ist eine Terminverschiebung eine Frage des Ausmaßes und der flankierenden Maßnahmen. Aber das gilt nicht immer: Als Projektmanager eines Projektes zur Umstellung der Anwendungslandschaft eines Finanzdienstleisters auf den Euro stand der Termin 1.1.2002 nicht zur Disposition, andernfalls hätte das Unternehmen seine Geschäftstätigkeit einstellen müssen und das hätte man nicht überlebt. Es war übrigens ein Projekt, in dem die Entscheidungsfindung besonders gut funktionierte und auch das Teamwork nach Anfangsproblemen hervorragend war. Es gab einfach einen Punkt weniger, an dem sich Konflikte hätten entzünden können.

Ein Zielkonflikt kann Ausdruck einer Werthaltung und nicht sachlich begründet sein, wenn z.B. das Management „aus Prinzip“ keine Terminverschiebung akzeptieren will. Dann hat die Auseinandersetzung um die Terminfrage eher den Charakter einer Gehorsamkeitsprüfung, was in der Hundedressur angebracht ist, unter Menschen allerdings zu heftigen emotionalen Verwerfungen führt. Es ist ja deutlicher Ausdruck mangelnder Wertschätzung und fehlenden Vertrauens und das geht an die Substanz sozialer Beziehungen. Professionelles Konfliktmanagement muss versuchen, diese Emotionen zu dämpfen und mit aller Konsequenz die Frage zu klären, mit welchen Mitteln die strikte Vorgabe erfüllt werden könnte. Wenn es wirklich nicht geht, dann wird sich diese Erkenntnis früher oder später auch bei den Auftraggebern durchsetzen. Dass auf dem Weg dahin viel verbrannte Erde produziert wurde und das Klima der Zusammenarbeit im Projekt nachhaltig beschädigt wurde, ist allerdings sehr wahrscheinlich.

Der einzige, wirkungsvoll und ohne negative Nebeneffekte einsetzbare Hebel zur Konfliktlösung sind die Informationsfaktoren. Geht es um einen Methodenkonflikt, so ist das ohnehin der direkte Weg und wird von allen Beteiligten wahrscheinlich leicht akzeptiert werden.

Der Weg zur Konfliktlösung oder zumindest Deeskalation durch Arbeit an den Informationsfaktoren besteht aus folgenden Schritten:

1. Lösen wir die Alternativen von Personen, sprechen wir nicht von Ihrem und meinem Vorschlag, sondern von Vorschlag A und Vorschlag B. Diese Technik ist der Kern der Harvard-Methode zur Konfliktbewältigung (siehe Link am Ende des Beitrages).
2. Einigen wir uns auf Kriterien, nach denen wir Alternativen bewerten wollen.
3. Sammeln wir alle Informationen, die uns eine Entscheidung anhand dieser Kriterien erlauben.
4. Bewerten wir die Alternativen gemeinsam.
5. Akzeptieren wir, dass die Alternativen nachjustiert werden können. Manchmal müssen auch die Kriterien verändert werden, das ist natürlich mit Vorsicht zu handhaben, darf aber auch nicht völlig ausgeschlossen werden. Man wird durch die Auseinandersetzung mit den Alternativen klüger und sollte das nutzen.
6. Wiederholen wir Schritt 1 bis 5 immer wieder.
7. Wenn die Konfliktlösung unter den unmittelbar Beteiligten nicht gelingt, holen wir eine möglichst neutrale, jedenfalls aber von allen als integer und kompetent eingeschätzte Person als Konfliktberater hinzu. Ich halte das Konzept der Mediation für zu starr, um in zeitkritischen Situationen zu einem guten Ergebnis zu kommen, aber einige Grundregeln sollten von jedem Konfliktberater beachtet werden, vor allem das Gebot der „Allparteilichkeit„. Wiederholen wir Schritt 1 bis 5 unter diesen Bedingungen immer wieder.

Und wenn das alles nichts nützt? Traurige Nachricht am Ende: Nicht alle Konflikte können konstruktiv gelöst werden. Auch Ärzte müssen akzeptieren, dass sie an der Heilung eines Patienten scheitern, Anwälte, dass sie ihrem Mandanten nicht zum Erfolg verhelfen können usw. Dann ist Schadensbegrenzung das einzige Mittel, das bleibt. Sorry, that’s life! Shit happens.

Wie man diese Analyse einsetzen kann, um Strategien des Konfliktmanagements zu entwickeln, habe ich hier beschrieben.

Die Buchempfehlung am Ende:

Konflikte brechen nicht plötzlich aus, sondern durchlaufen verschiedene Phasen. Welche das sind, ist für die Wahl der Strategie des Konfliktmanagements von entscheidender Bedeutung.

Konfliktphasen

Im Folgenden werden 5 Entwicklungsphasen eines  Konfliktes unterschieden (manchmal werden einzelne Phasen auch sehr schnell durchlaufen, so dass man sie kaum bemerkt). Zu Beginn immer eine kurzes Fallbeispiel, Namen und einige Details wurden verändert:

Phase 1:   Noch nicht bewusste Gegensätze

Gerald wurde sehr kurzfristig als Projektleiter installiert. Sein Vorgänger hatte das Handtuch geworfen, weil er – so seine Begründung – die ständige Besserwisserei der Programmleitung und des Programmauftraggebers nicht mehr ertragen wollte. Das Projekt war schon deutlich in Verzug. Hannes, der Programmleiter nahm den neuen Projektleiter sehr freundlich auf, er hatte aber auch keine echte Wahl, denn Gerald hatte schon einige Projekte erfolgreich abgewickelt und genoss das Vertrauen des Programmauftraggebers. Was beide, Gerald und Hannes allerdings zu diesem Zeitpunkt noch nicht wussten: ihr Stil, Projekte abzuwickeln, unterschied sich gravierend. Strikt an Standards orientiert, manche nannten es auch formalistisch, auf der einen Seite Hannes. Immer bereit, unkonventionelle Maßnahmen zu ergreifen und Vorgaben bei Bedarf in Frage zu stellen auf der anderen Seite Gerald. Wer beide kannte, hätte schon zu diesem Zeitpunkt gewusst, dass es Konflikte geben würde; nur die beiden selbst wussten es (noch) nicht. 

In diese Phase ist die Möglichkeit eines Konfliktes den potentiellen Konfliktparteien noch nicht bewusst, möglicherweise aber Personen, die nicht direkt betroffen sind (z.B. einigen Kollegen, die beide gut kennen).

Phase 2: Bewusste, aber nicht geäußerte Gegensätze

Gerald führte als Einstieg in die Projektleitung eine Reihe von Vier-Augen-Gesprächen. Dabei zeigten sich diametral entgegengesetzte Sichten auf den Status des Projektes und auch auf die Ursachen für die aufgetretenen Verzögerungen. Interessant war für ihn vor allem, dass in allen Meetings heftig über Change-Requests mit dem IT-Realisierungspartner, einem großen, internationalen IT-Unternehmen, gestritten wurde. Die meisten dieser „Change-Requests“ erschienen ihm allerdings als ganz normale und schwer abzulehnende Anforderungen an ein funktionierendes System. Auf seine Frage, auf welcher Grundlage etwas als Change eingestuft wurde und wie die Entscheidungskriterien der Genehmigung oder Ablehnung seien, stellte sich heraus, dass es zwar ein Pflichtenheft gab, dieses aber nie von allen Beteiligten formell abgenommen worden war. Die Anwendervertreter im Projekt wiesen darauf hin, dass sie immer schon gesagt hatten, dass dieses Pflichtenheft unvollständig sei und daher keine abschließende Grundlage für die Realisierung sein konnte. Als er Hannes darauf ansprach, reagierte dieser abwehrend und meinte, dass man dieses Gejammer nicht ernst nehmen dürfe. Die Anwender seien einfach nicht bereit, sich auf ein völlig neues System einzustellen und forderten daher ständig Features ein, die sie im jahrzehntelang gewachsenen Altsystem gewohnt waren. Und er erinnerte Gerald daran, dass er ja gerufen worden sei, um diesem „Wünsch-Dir-Was“ ein Ende zu bereiten. 

Den potentiellen Konfliktparteien ist das Bestehen von Gegensätzen bereits bewusst, aber sie verzichten aus verschiedenen Gründen noch darauf, darüber „offiziell“ zu sprechen. Dies kann in der Hoffnung geschehen, dass sich das Problem von selbst erledigen könnte; oder aber es erscheint besser abzuwarten, weil neue Fakten die Sach­lage entscheidend verändern könnten.

Phase 3: Diskussion

Gerald begann in Meeetings, die Sinnhaftigkeit des Streits um Change-Requests in Frage zu stellen. Mit dem Kramen in Dokumenten, im Ticket-System und in Protokollen gehe enorm viel Zeit verloren, am Ende würden doch fast alle Anforderungen genehmigt und das Budget des IT-Realisierungspartners erhöhe sich laufend. Auf beiden Seiten, sowohl Kunde als auch IT-Firma werde sehr viel Overhead investiert, die Arbeit an der Umsetzung der als sinnvoll und notwendig erkannten Anforderungen komme dagegen zu kurz. Er plädierte dafür, einen agilen Ansatz zu verfolgen, vor allem, indem man die Anwender und die Analytiker der IT-Firma direkt zusammen arbeiten ließe. Dieser Vorschlag passte Hannes überhaupt nicht. Das sei Chaos, man verliere völlig die Kontrolle und werde so nie fertig. Außerdem widerspreche das den Projektmanagement-Standards des Unternehmens. Hier waren sich Hannes als Programmleiter des Kunden und das Management der IT-Firma erstmals seit langem einig, wenn auch aus verschiedenen Motiven. Der eine fürchtete, dass seine Programmleitungs-Prozesse in Frage gestellt würden, die IT-Firma fürchtete um ihre Lizenz zum Gelddrucken, da ja bisher alle Diskussionen über Change-Requests zu einer Erhöhung des Budgets geführt hatten und außerdem damit hochdotierte Requirements-Engineers (eigentlich waren es Claim-Manager) verrechenbar ausgelastet werden konnten. Gerald stand mit seinem Vorschlag ziemlich allein und im Regen. 

Die unterschiedlichen Auffassungen werden bereits ausgesprochen, allerdings im Stile eines Austausches von Informationen. Dies kann eine Vorsichtsmaßnahme sein, aber auch ein ernsthafter Versuch, das anstehende Problem auf „friedlichem“ Wege zu lösen.

Phase 4: Offener Konflikt

Gerald ließ sich auf das Spiel mit den Change-Requests ein, allerdings nur als taktische Finte, um das bisherige Vorgehen im Projekt letztlich doch auszuhebeln. Er glich die vorliegenden Dokumente, insbesondere das Pflichtenheft, mit den offenen Change-Requests ab und zeigte auf, dass ein großer Teil der angeblich neuen Anforderungen sehr wohl dort enthalten war. Nicht detailliert ausgeführt, aber zumindest als Überschrift mit einer groben Beschreibung. Damit stellte er sich auf die Seite der Anwender und brachte Hannes als Programmleiter und die IT-Firma in Verlegenheit: wieso war das bisher nicht bemerkt worden?  Gerald verzichtete jedoch darauf, diese Frage weiter zu vertiefen und zu eskalieren, der Schuss vor den Bug genügte ihm. In dieser Situation platzierte er seinen ursprünglichen Vorschlag in etwas modifizierter Form: Die Anwendervertreter und die Analytiker der IT-Firma sollten zu jedem Geschäftsprozess gemeinsam eine Lösungsbeschreibung erarbeiten. Das sollte dann Grundlage einer finalen und für die IT-Firma verbindlichen Aufwands- und Terminabschätzung sein. Allerdings sollte aufgrund der großen Verzögerung gegenüber dem ursprünglichen Terminplan mit der Umsetzung der ersten fertig gestellten Lösungsbeschreibung begonnen werden, während noch an der nächsten Lösungsbeschreibung gearbeitet wurde. Damit setzte Gerald unter Vermeidung von Reizworten wie „agil“ etc. eine iterative und letztlich agile Vorgehensweise durch. Nach einer Durststrecke, die Gerald nur überstehen konnte, weil der Programm-Auftraggeber ihm vertraute, zeigten sich die ersten Erfolge und das Arbeitsklima im Projekt verbesserte sich dramatisch. Hannes war mit dieser Entwicklung überhaupt nicht glücklich, stellte es doch seine ganze bisherige Vorgehensweise in Frage. Aber die Dynamik der direkten Zusammenarbeit überrollte seine Vorbehalte und da Gerald darauf verzichtete, die Vergangenheit zu diskutieren, konnte Hannes das ohne evidenten Gesichtsverlust hinnehmen. Beim Programm-Auftraggeber und vielen anderen Beteiligten war natürlich das Ansehen von Hannes beschädigt, aber das wurde nicht ausgesprochen, man war froh über den nun erfolgreichen Abschluss des Projektes und wollte nicht das Programm destabilisieren, indem man den Programmleiter in Frage stellte. 

Das Bestehen eines Gegensatzes wird angesprochen, das Bemühen um Durchsetzung des eigenen Standpunktes gegen den oder die anderen Standpunkte ist nun offenkundig.

Phase 5: Beendeter Konflikt

Hannes und Gerald hatten eine gute persönliche Beziehung durch gemeinsame persönliche Interessen (lassen wir hier offen, ob es Sport, Kultur, Autos oder sonst etwas war), aber in der Sache, nämlich wie man ein solches Projekt managt, waren sie eindeutig Gegner gewesen. Da Gerald ein extern zugekaufter Projektleiter auf Zeit war, konnte man diese Gegensätze allerdings auf sich beruhen lassen. Wie so oft, gehörte der Erfolg dann doch dem internen Programmleiter, der externe Trouble-Shooter beendete seine Tätigkeit in diesem Unternehmen kurz nach der Produktivsetzung des Systems. Das sind die Regeln, nach denen Beratung funktioniert und das ist so völlig in Ordnung. Wären Gerald und Hannes beide Mitarbeiter des Unternehmens, hätte es wohl ein späteres, neuerliches Aufflammen des Konfliktes gegeben. 

Konflikte wirken nach: Entweder kommt es zu einer für alle Beteiligten überzeugenden oder wenigstens akzeptablen Lösung und der überwundene Konflikt wird nun rückblickend als „reinigendes Gewitter“ erlebt, oder aber es bleiben Ressentiments bestehen. Im letzteren Fall befinden sich die Beteiligten wieder in Phase 2 des nächsten Konfliktes.

Bipolare und multipolare Konflikte

Konflikte müssen nicht auf zwei Einzelpersonen beschränkt sein, auch Gruppen mit weitgehend gleichen Interessen und Sichtweisen können gemeinsam als Konfliktpartei betrachtet werden. Wenn allerdings im Verlauf der Konfliktentwicklung diese Übereinstimmung aufbricht, wird aus dem bipolaren ein multipolarer Konflikt. Wir beschränken uns hier etwas vereinfachend auf bipolare Konflikte, die wesentlichen Aussagen gelten allerdings für alle Konflikttypen gleichermaßen.

Zielszenarien des Konfliktmanagements

In der Praxis sind drei verschiedene Ziele von Bedeutung, die im Verlauf eines Konfliktes von den Beteiligten oder vermittelnden „Konfliktberatern“ angesteuert werden können. Sie sollen im Folgenden kurz charakterisiert werden:

Konfliktlösung:

Darunter verstehen wir eine völlige Angleichung der ursprünglich gegensätzlichen Standpunkte. Dies ist im Allgemeinen nur im Falle von Methodenkonflikten möglich, kaum jemals bei Zielkonflikten oder von Wertdifferenzen getriebenen Konflikten (dazu mehr in einem anderen Blogbeitrag). Wo in Einzelfällen Konfliktlösungen erreicht werden können, ist eine verbesserte Basis für die Bewältigung zukünftiger Konflikte gegeben.

In unserem Fallbeispiel war eine Konfliktlösung nicht realistisch, alle Beteiligten mussten Abstriche machen. Der Auftraggeber musste nochmals Budget aufstocken, Hannes hinnehmen, dass Projektmanagement-Methoden angewendet wurden, die aus seiner Sicht nicht optimal waren und Gerald musste darauf verzichten, seine Projektmanagementmethodik offiziell und in voller Ausprägung zu praktizieren.

Konfliktregelung:

Darunter verstehen wir einen Kompromiss, bei dem eine Gemeinsamkeit der Standpunkte erreicht werden kann, die für die weitere Zusammen­arbeit ausreicht. Die Beteiligten müssen sich hierbei auf Ziele und Methoden einigen, die von allen getragen werden können. Konfliktregelungen sind nicht mit „faulen“ Kompromissen zu ver­wechseln. Diese sind dadurch gekennzeichnet, dass sich die Beteilig­ten um des Friedens willen oder aufgrund äußeren Drucks jeweils etwas entgegenkommen, in Wirklichkeit aber unverändert auf ihren ursprünglichen Standpunkten beharren und auf eine günstige Gelegen­heit warten, diese doch noch (ohne Abstriche) durchzusetzen.

In unserem Fall ergab sich eine Konfliktregelung, die erfolgreiche Produktivsetzung des Systems, wenn auch mit Terminverzug und Budgetüberschreitung, war für alle Beteiligten  trotz aller Abstriche ein höchst positives Ergebnis. Auch die IT-Firma war froh, dass aus einem (wenn auch lukrativen) Chaos-Projekt am Ende doch ein erfolgreiches Projekt geworden war.

Konfliktunterdrückung:

Darunter verstehen wir die Rückführung eines bereits in die Phase 3 (Diskussion) oder Phase 4 (Offener Konflikt) eingetrete­nen Konflikts in das Stadium der „Bewussten, aber nicht geäußerten Gegensätze“ (Phase 2). Dies kann durch ein „Machtwort“ eines Vorgesetzten geschehen, aber auch durch Übereinkunft der Beteiligten, wenn sie befürchten, dass andernfalls negative Folgen eintreten könnten, die schwerer wiegen als die von den einzelnen Konfliktbeteiligten bestenfalls erzielbaren Vorteile.

Der methodische Konflikt zwischen Hannes und Gerald wurde unterdrückt. Da klar war, dass Gerald nach erfolgreicher Mission seine Tätigkeit in diesem Unternehmen beenden würde, war das eine gute Lösung. 

Handlungsoptionen von Konfliktberatern

Personen, die als nicht unmittelbar an einem Konflikt Beteiligte auf den Verlauf eines Konfliktes Einfluss zu nehmen versuchen oder sogar zur Einflussnahme verpflichtet sind, bezeichnen wir als Kon­fliktberater. Ein Konfliktberater kann unterschiedliche Resultate anstreben und unterschiedliche Methoden anwenden. Aus der Sicht der Konfliktforschung können daher zwei Grundprobleme unterschie­den werden:

a) Die Frage der Strategie

Strategische Entscheidungen beinhalten die Analyse der Ausgangs­situation und der Handlungsmöglichkeiten, die Festlegung von Zielen sowie die Auswahl bzw. den grundsätzlichen Ausschluss von bestimmten Handlungsweisen.

b) Die Frage der Taktik

Taktische Entscheidungen beinhalten die Entscheidung für eine bestimmte Maßnahme in einer konkreten Situation; sie sollten in eine Strategie eingebettet sein.

(Es sei darauf verwiesen, dass mit dem Begriff Taktik hier nicht etwa Tricks und Täuschungsmanöver gemeint sind, die sich dafür eignen, einen „Gegner“ mit möglichst geringem Aufwand und Risi­ko zu besiegen; vielmehr wird dieser Begriff hier wertneutral verwendet und schließt damit auch faire und kooperationsorien­tierte Handlungen ein.)

Für die strategischen Möglichkeiten eines Konfliktbera­ters ist es von grundlegender Bedeutung, in welcher Phase eines Konfliktes er eingeschaltet wird bzw. sich einschalten kann.

Geschieht dies bereits in einem der ersten drei Stadien, sprechen wir von präventiver Konfliktberatung. Wird der Konfliktberater erst im Stadium des offenen Konfliktes aktiv, sprechen wir von korrektiver Konfliktberatung.

Wir können nun – wie die folgende Matrix zeigt – sechs grundlegen­de Strategien des Umgangs mit Konflikten unterscheiden:

Generell gilt natürlich, dass präventive Konfliktberatung immer größere Chancen hat, die gesetzten Ziele zu erreichen als eine korrektive Konfliktberatung. Aber das kann man sich bekanntlich nur selten aussuchen.

So ist die Wahrscheinlichkeit, präventiv eine Konfliktlösung (P-L) zu erreichen größer als im Falle korrektiver Beratung (K-L), da sich im Stadium des offenen Konfliktes Positionen oft schon so weit verfestigt haben, dass auch objektiv gegebene Lösungsmöglich­keiten nicht mehr gesehen werden. Es ist eine bekannte Tatsache, dass das Verhandlungsklima großen Einfluss auf das Ergebnis einer Verhandlung hat. Korrektive Konfliktberatung hat dann die relativ besten Chancen auf Erfolg, wenn auf eine Konfliktregelung (K-R) hingearbeitet wird.

Nur als „Notbremse“ kann die auf korrektive Konfliktunterdrückung gerichtete Strategie (K-U) akzeptiert werden; denn die erzielte Beruhigung der Situation ist entweder nicht von langer Dauer oder aber es treten Konfliktverschiebungen auf (dazu mehr hier). Eine präventive Konfliktunterdrückung (P-U) kann jedoch angebracht sein, wenn der Konfliktstoff sich aller Voraussicht nach in Kürze ent­schärfen lässt (z.B. bei einem Konflikt zwischen dem Projektleiter und einem Arbeitspaketverantwortlichem, dessen Aufgabe ohnehin bald abgeschlossen sein wird und der dann nicht mehr dem Projektteam angehört). Konfliktunterdrückung setzt allerdings ausrei­chend starken Einfluss des Konfliktberaters auf die Konflikt­beteiligten voraus.

In der Praxis werden meist die positiven Chancen einer Strategie der präventiven Konfliktregelung (P-R) unterschätzt. Viele Konflikt­berater haben als Ziel nur Konfliktlösungen im Auge und bleiben un­tätig oder versuchen Konflikte zu unterdrücken, weil sie keine Chance für eine Konfliktlösung sehen.

Auf der Grundlage einer Abklärung der Konfliktstrategie ist im Einzelfall festzulegen, mit welchen Maßnahmen die gesetzten Ziele erreicht werden können (also die Frage nach der Taktik im oben beschriebenen Sinne). Dabei be­steht gerade bei taktischen Entscheidungen ein relativ großer Handlungsspielraum für den Konfliktberater – vor allem bei präventiven Strategien.

In unserem Fallbeispiel war kein Konfliktberater verfügbar, das Konfliktmanagement war den Beteiligten überlassen. Gerald übernahm die Steuerung der Konfliktbewältigung. Aufgrund seiner Erfahrung und seiner Social Skills gelang ihm das auch, ohne seine starke Position beim Programm-Auftraggeber aufgrund anderer bereits erfolgreich abgewickelter Projekte wäre ihm das allerdings nicht gelungen. 

Wenn es ein umfassendes und detailliertes Pflichtenheft gibt und dazu eine Fixpreisvereinbarung, dann ist es ganz wichtig, zwischen Fehlern und zusätzlichen Anforderungen zu unterscheiden. Wenn also beim Test oder gar bei der Endabnahme ein Verbesserungsvorschlag auftaucht, dann wird intensiv im Pflichtenheft und in Protokollen, Tickets etc. gesucht, ob diese Anforderung dort schon formuliert wurde und daher im Fixpreis enthalten ist oder ob dafür zusätzliches Budget erforderlich ist. Erfahrene Anwender machen daher versuchsweise eine Fehlermeldung und hoffen, auf diesem Weg das Gewünschte zu erreichen. Das wiederum bringt heftige Gegenreaktionen von Seiten der Entwickler, vor allem, wenn das ein gut organisiertes, budgetgetriebenes Unternehmen ist. Die Auseinandersetzung um solche Fragen kann oft deutlich mehr Aufwand verursachen als die rasche Umsetzung der Anforderung gekostet hätte, aber es geht ja ums Prinzip und es gilt „Wehret den Anfängen!“.

Solche Mechanismen können ein Projekt ganz schön belasten, ein Fallbeispiel habe ich an anderer Stelle schon geschildert. Wie löst man dieses Problem bei agilen Projekten? Ist das ein Wunschkonzert, bei dem Aufwand keine Rolle spielt? Kann wohl nicht sein, aber wie geht man damit um?

Fehler oder Feature – der Unterschied ist am Ende gering

Diese These wird viele provozieren: „Der Unterschied zwischen Fehlerbehebungen und der Implementierung von neuen Features ist minimal“. Technisch gesehen macht es einen Unterschied, ob man in eine bestehende Software eingreift oder ob man „from scratch“ eine Software erstellt. Letzteres ist allerdings die Ausnahme und das aus zwei Gründen: 1. bauen die meisten Softwareprojekte auf bereits vorhandenen Softwarekomponenten bzw. -bibliotheken auf, die angepasst, ergänzt und konfiguriert werden und 2. sobald man in einem Projekt weiter fortgeschritten ist, sind die meisten Features, die man implementiert Eingriffe in bereits vorher geschriebenen Code.

Fehlerkorrekturen sind so gut wie immer Eingriffe in bestehenden Code, der einzige Unterschied ist, dass jemand geglaubt hat, dass dieser Code schon die gestellten Anforderungen erfüllt und sich dabei geirrt hat. In der Auswirkung ist der Unterschied vernachlässigbar: Jeder Eingriff bringt die Gefahr neuer Fehler mit sich und es kann ja sogar der Eingriff selbst schon fehlerhaft sein.

Ob man eingegriffen hat, weil man ein Feature erstmals implementiert oder dies tut, weil der erste Implementierungsversuch nicht vollständig gelungen ist, macht keinen Unterschied hinsichtlich des damit verbundenen Aufwandes und Risikos. Der Unterschied ist einerseits ein emotionaler, es macht mehr Freude, etwas neu zu implementieren und meist wenig Freude, Fehler zu korrigieren. Andererseits ist es aus vertraglicher Sicht oft ein wesentlicher Unterschied, Fehler fallen eventuell unter Gewährleistung und sind von der Entwicklungsfirma zu tragen.

Lassen wir die Emotionen hier beiseite, bleibt nur der vertragliche und damit auch kaufmännische Aspekt. Aber auch der ist stark zu relativieren. In jeder Aufwandskalkulation ist ein gewisser Anteil für Fehlerbehebungen enthalten. Solange dieser Aufwand im Rahmen und das Projekt insgesamt im Budget bleibt, ist der Aufwand für Fehlerbehebungen eine interessante Metrik, aber ansonsten ohne Relevanz.

In einem agilen Projekt wird der Aufwand je User-Story geschätzt, einen echten Fixpreis kann es nicht geben. Auch wenn Autoren mit einem „agilen Festpreis“ werben, es ist kein Fixpreis, sondern eine mehr oder raffinierte Verrechnung nach tatsächlichem Aufwand („time and materials„). Meine Sicht auf das Thema habe ich schon an anderer Stelle dargestellt. Hier soll es um den konkreten Umgang mit Anforderungen und Fehlermeldungen in einem agilen Softwareprojekt gehen.

Priorisierung von Anforderungen – was zählt?

Anforderungen (ob in der Form von User-Stories, Use-Cases, Features etc. beschrieben, macht hier keinen Unterschied) sollten nach standardisierten Kriterien beurteilt werden. Prägnant nennt z.B. Dean Leffingwell folgende Kriterien (s. 209):

1. Der Wert für die Anwender (User Value)
2. Der Schaden, wenn man es nicht realisiert
3. Das Risiko, es umzusetzen
4. Die Kosten der Umsetzung
5. Der potenzielle finanzielle Nutzen (ROI) der Umsetzung.

Nun ist die Frage, ob diese Kriterien sich im Verlaufe des Projektes ändern. Ich sage: Nein! Die Gewichtung der Kriterien ändert sich, aber nicht die Kriterien selbst. Gehen wir zum Ende eines Projektes, also knapp vor dem letzten Deployment. Hier wird das Risiko der Umsetzung (3) eine viel größere Rolle spielen als zu Beginn des Projektes, weil jeder Eingriff erfahrungsgemäß mit dem Risiko einer Destabilisierung des Systems verbunden ist. Daher geht man in dieser Phase oft dazu über, nur bei hohem Score im Kriterium 2 einer Umsetzung zuzustimmen. Das Kriterium 1 wird nicht mehr besonders gewichtet, weil man davon ausgeht, dass alles, was einen Geschäftsnutzen bringt, bereits identifiziert und umgesetzt wurde. Also werden nur noch Fehler korrigiert, die entweder gegen gesetzliche Vorgaben verstoßen und/oder zu Verarbeitungsfehlern mit Außenwirkung führen. Daraus entsteht oft der Eindruck, dass zwischen Fehlerkorrekturen und der Realisierung von Anforderungen ein grundsätzlicher Unterschied besteht.

Es ist aber egal, wie das System destabilisiert wird, auch eine Fehlerkorrektur kann einen massiven Eingriff erfordern und ist daher mit hohem Risiko verbunden. Vielleicht ist dieser Fehler durchaus tolerierbar (per Workaround neutralisierbar). Vielleicht ist hingegen ein zusätzliches Usability-Feature (z.B. eine zusätzliche formale Prüfung von Eingaben) mit geringem Risiko verbunden und senkt die Schulungskosten,  die Kosten für Fehlerkorrekturen in der laufenden Verarbeitung und verbessert so den ROI (5). Dann sollte man das Usability-Feature umsetzen, solange man genügend Kapazität bzw. Budget dafür zur Verfügung hat. Ich muss allerdings anmerken, dass ich noch keinen Auftraggeber erlebt habe, der es wagt, solche Entscheidungen in der heißen Phase eines Projektes zu treffen. Es wird regelmäßig ein Code-Freeze ausgerufen, dieser wird mehrfach aufgeweicht, weil Fehler zu korrigieren sind und jeder, der es wagt, ein Usability Feature in dieser Phase einzubringen, wird wegen mangelndem Verständnis für den Ernst der Lage zurechtgewiesen.
Wenn ein Projekt gut läuft, dann werden solche Themen ohne große Diskussion erledigt, vor allem wenn durch ein agiles Vorgehen enger Kontakt zwischen Anwendern und Entwicklungsteam besteht. Natürlich ist das tendenziell gefährlich, denn die Grenze zur Anforderungsdefinition per Zuruf ist schnell überschritten. Ein Product Owner, der seinen Job gut macht, kann entscheiden, was man auf kurzem Weg erledigt und welche Systemverbesserungen man blockieren muss, auch wenn es auf den ersten Blick harmlos wirkt.

Zusammen gefasst ist meine These: Zwischen Feature und Bug ist der wesentliche Unterschied, dass der Bug eine Abweichung von einer schon definierten Anforderung ist und dass gefordert wird, diese Abweichung zu beseitigen. Sofern es sich um ein Fixpreis-Projekt handelt, muss für diesen Aufwand die Entwicklungsfirma aufkommen und dem Kunden fällt es schwer, darauf zu verzichten, auch wenn es aus einer objektiven Priorisierungssicht sinnvoller wäre, auf diese Fehlerbehebung im Moment zu verzichten und dafür lieber ein zusätzliches Feature umzusetzen, dass hohen Wert für das Geschäft des Kunden hat.

In einem agilen Projekt, das letztlich nach Time&Materials abgerechnet wird, fällt so ein Abtausch leichter. Der Auftraggeber disponiert über die Ressourcen des Realisierungspartners und ob diese für die Behebung eines Fehlers oder für ein neues Feature eingesetzt werden, macht kommerziell keinen Unterschied. Wer jetzt glaubt, ich rede einem verantwortungslosen Umgang mit den Leistungen der Softwareentwickler das Wort, bei dem Fehler beliebig toleriert werden und folgenlos bleiben, bitte ich, meinen schon weiter oben erwähnten Beitrag zu diesem Thema zu lesen.

Hier noch das oben zitierte Buch von Dean Leffingwell, das ich generell sehr empfehlen kann:

Die Quelle ist nicht ganz klar (dazu Wikiquote), aber diese Regel wird oft zitiert und ihre Gültigkeit nie bezweifelt. Auch ich will dem nicht widersprechen, allerdings eine ergänzende Regel aufstellen: Only a fool works without a tool.

Die Frage ist allerdings, welche Tools man wählt und welche Auswirkung die Wahl von Tools auf das Ergebnis haben.

In einem meiner ersten Softwareprojekte hatte der Auftraggeber, ein großes deutsches Versicherungsunternehmen, gerade ein neues Vorgehensmodell für IT-Projekte definiert. Es bestand in einer Abfolge von Formularen, die zu befüllen waren. Rasch stellte sich heraus, dass diese Vorgaben für unser konkretes Projekt nicht zielführend waren. Als wir allerdings vorschlugen, entsprechende Anpassungen vorzunehmen, war der Projektleiter des Kunden strikt dagegen. Wir beantworteten also weiterhin teilweise sinnlose Fragen und ließen wichtige Fragen unbeantwortet. Das Werkzeug, nämlich eine Folge von strukturierten Spezifikationsdokumenten, bestimmte den Inhalt unserer Arbeit. Die eigentliche Aufgabe, nämlich die Vorgaben für ein neues Bestandsführungssystem dieser Versicherung zu erarbeiten, trat immer mehr in den Hintergrund. Das Werkzeug hatte sich verselbständigt. Ich wurde aus dem Projekt bald wegen meiner dauernden Aufmüpfigkeit entfernt und war auch erleichtert. Jahre später hörte ich, dass das Projekt gestoppt und der Projektleiter gekündigt worden waren.

Was habe ich daraus für meine späteren Projekte gelernt?

Keinesfalls, dass die Verwendung von Werkzeugen per se schädlich ist. Allerdings doch ein starkes Misstrauen gegen Vorgehensmodelle und damit verbundene Methoden und Werkzeuge. Man muss immer wieder die Frage stellen, ob diese bei der Arbeit an der eigentlichen Aufgabe unterstützen oder von dieser ablenken.

Es geht nicht ohne Tools, aber sie sind keine Erfolgsgarantie

Nach vielen Jahren Erfahrung kann ich sagen, dass die in der Anforderungsdefinition am häufigsten angewandten Werkzeuge Word, Excel und Powerpoint sind. Wenn es um Projektplanung und Projektcontrolling geht, ist das Excel. Warum? Es sind sehr flexible und leicht zu nutzende Werkzeuge, die man der jeweils gegebenen Aufgabe und Situation anpassen kann. Ihr Nachteil ist, dass man immer wieder auf der grünen Wiese beginnt und jedes Projekt anders vorgehen kann. Daher gibt es auch zahllose Templates mit unterschiedlich hohem Strukturierungs- und Reifegrad, die dann projektspezifisch angepasst werden.

Methoden und Werkzeuge für das Requirements-Engineering gibt es natürlich in großer Zahl, einen Überblick zur aktuellen Literatur findet man hier. Viele leiden allerdings darunter, dass sie für Anwender schwer erlern- und handhabbar sind.

Gute Erfahrungen habe ich in mehreren Projekten mit JIRA gemacht. Die Einrichtung dieses Tools in einer Form, die sich auch für Anwender eignet, lohnt sich allerdings nur in größeren Projekten. Dort ist es aber Pflicht, in so ein Tool zu investieren, weil das Pflegen von Excel-Listen rasch ins Chaos führt.

Entscheidend ist es, den Übergang von Word und Excel zu einem spezifischen Tool nicht zu verpassen. Beginnt man irgendwie und hat man einiges an Inhalt bereits produziert, ist die Umstellung auf ein Werkzeug schwierig; man schleppt erfahrungsgemäß bis zum Abschluss des Projektes Altlasten mit. Daher gleich am Anfang über die Notwendigkeit und Sinnhaftigkeit eines spezifischen Tools nachzudenken und dieses von Anfang an einsetzen. Wenn das verabsäumt wurde, muss man bei einer späteren Umstellung genügend Aufwand dafür einplanen und braucht auch entsprechenden Nachdruck, dass die Umstellung gelingt.

Henne oder Ei, Methode oder Tool – was kommt zuerst?

Oft hört man auch, dass man zuerst festlegen muss, wie man arbeiten will, dann soll man das passende Tool wählen. Klingt auch sehr vernünftig, ist aber trotzdem nicht ideal, wenn man es zu streng sieht. Es ist richtig und wichtig, sich zu überlegen, was man wie abarbeiten will. Aber wenn man das grob skizziert hat, sollte man Tools unter diesem Gesichtspunkt sichten. Dabei lernt man viele Möglichkeiten kennen, an die man nicht gedacht hat, denn in den Tools haben sich die Erfahrungen zahlreicher Menschen mit ähnlichen Aufgabenstellungen niedergeschlagen. Diese Erfahrungen wertet man aus und überarbeitet seine Vorgaben. Dann geht man nochmals an die Toolauswahl und vielleicht wiederholt man diesen Vorgang sogar mehrere Male. Ein Spiralmodell des Vorgehens ist also auch hier der beste Weg.

Wenn Sie regelmäßig über neue Blogposts informiert werden wollen, tragen Sie sich bitte hier ein. Bitte öffnen Sie dann Ihr Postfach und klicken Sie auf den Bestätigungslink, andernfalls wird die Anmeldung nicht wirksam („Double-Opt-In“).

Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.

Das Projekt ist gut gelaufen, die erstellte Software erfüllt die Anforderungen der Anwender und jetzt geht es „nur“ noch darum, diese aus der Entwicklungs- und Testumgebung in die Produktivumgebung zu transferieren, die Daten aus dem Altsystem zu übernehmen und dann freizuschalten. Da kann doch nichts mehr schief gehen, möchte man glauben. Oja, es kann! Beim Go-Live eines Projektes kann noch viel schief gehen, auch wenn vorher noch so gut gearbeitet wurde.

Hier eine Liste der Top 5 Hoppalas aus einer Vielzahl von Projekten. Die Beispiele stammen aus meiner Praxis. Manchmal ging es wirklich schief, oft gelang es gerade noch rechtzeitig, das Problem in den Griff zu bekommen.

a. Die Berechtigungen wurden nicht richtig und vollständig vergeben

Das scheint trivial, ich nenne es aber trotzdem als erstes, weil das geradezu regelmäßig passiert. Ich habe es daher fix auf meiner Checkliste und stoße mehrfach nach. Trotzdem passiert es immer wieder, wenn auch in unterschiedlichem Ausmaß. Dass bei einigen Personen irgend eine Rolle nicht zugewiesen wurde, scheint mir geradezu unvermeidbar. Wenn das großflächig passiert, ist es ein echtes Problem. Man muss daher mit entsprechendem Aufwand früh genug gegensteuern.

Besonders störend ist es, wenn das Problem bei der Schulung auftritt. Teilnehmer sind angereist, Trainer sind bereit, aber man kann nicht richtig beginnen. Außerdem bekommen die künftigen Anwender gleich ein negatives Bild vom neuen System, auch wenn das Problem garnichts mit dem eigentlichen System zu tun hat.

b. Die Schulung wurde nicht frühzeitig und umfassend organisiert

Wer, wann, von wem, mit welchem Zeitaufwand und an welchem Ort geschult werden muss, ist eine nicht zu unterschätzende Planungsaufgabe. Bei großen Anwenderzahlen und regionaler Streuung ist das eine beträchtliche logistische Herausforderung. Die Gefahr, dass man den Schulungsaufwand nach unten schraubt, weil man Aufwand sparen will, ist erheblich und rächte sich gnadenlos.

Wenn man die Logistik als gelöst voraussetzt, bleibt die Frage, wie die Schulung inhaltlich gestaltet wird. Wer kennt das neue System am besten? Natürlich jene, die es entwickelt haben! Diese Personen sind aber meist bis knapp vor der Produktivsetzung mit Entwicklungsaufgaben, Fehlerkorrekturen und Deployments ausgelastet und stehen daher nicht früh genug für eine professionelle Schulungsvorbereitung zur Verfügung. Außerdem sind diese Personen selten in der Lage, an der alltäglichen Praxis der Anwender anzuknüpfen und sie von dort aus zur Nutzung des neuen Systems hinzuführen. Die brennendsten Fragen der Anwender betreffen nur selten die Funktionalität der Software, sondern es geht um organisatorische und fachliche Fragen, zu denen nur Trainer Auskunft geben können, die aus dem Bereich der Anwender kommen.

Hier lohnt sich ein gut organisiertes und personell großzügig ausgestattetes Test-Management. Anwender, die frühzeitig in Tests aktiv waren, sind ideale Trainer. Man muss natürlich schon bei der Planung der Tests und vor allem bei der Zusammenstellung der Testteams an die Schulung denken. Was hier versäumt wurde, kann man knapp vor den Go-Live nicht mehr kompensieren.

Wenn man agil entwickelt, bekommt man die geeigneten Tester quasi als Nebenprodukt. Aber auch hier muss mit ausreichender Kapazität und gegebenenfalls regionaler Streuung gearbeitet werden, einen Erfolgsautomatismus gibt es auch in agilen Projekten nicht.

Bei sehr großen Anwenderzahlen, ich hatte einmal eine Zielgruppe von ca. 8.000 Personen im gesamten Bundesgebiet verteilt, ist E-Learning als vorgeschaltete Basisschulung ein sehr guter Ansatz. Hier gilt ebenfalls eine ausreichende Vorlaufzeit als unbedingte Voraussetzung. Dadurch kann man allerdings den Aufwand der Präsenzschulungen reduzieren und bei der Erarbeitung des E-Learnings auch Personen einbeziehen, die als Trainer nicht zur Verfügung stehen (sei es aus Zeitgründen, sei es wegen mangelnder Trainerskills).

Die Defizite einer mangelhaften Schulungsplanung lassen sich leider nicht kurzfristig ausgleichen und können den Erfolg eines bis zu diesem Zeitpunkt hervorragend laufenden Projekts zunichte machen. Allerdings kann so ein Mangel frühzeitig erkannt und korrigiert werden, wenn man das verabsäumt, handelt es sich um „einen Selbstmord mit Anlauf“.

c. Die organisatorischen Anforderungen der Umstellung wurden nicht kommuniziert

In Entwicklungsprojekten (ob es sich um Individualsoftware handelt oder um Customizing einer Standard-Software muss hier nicht unterschieden werden), konzentriert man sich auf den Zielzustand der Applikation. Wenn man es gut macht, ist damit auch ein Zielzustand der Geschäftsprozesse verbunden, jedenfalls bei den Vertretern der Anwender im Projektteam. Angesichts der vielen Herausforderungen der Entwicklungsphase gerät aber leicht in Vergessenheit, dass die künftigen Anwender diese Überlegungen nicht kennen. Auch deren Führungskräfte sind meist wenig informiert, deren Zeitbudget ist knapp und die Bereitschaft, sich mit einem Software-Projekt auseinanderzusetzen, solange die Produktivsetzung nicht direkt vor der Tür steht, ist gering.

Die Notwendigkeit der Umstellung bisher gewohnter Abläufe trifft die Anwender daher oft unvorbereitet. Auch die Schulung wird oft zu stark als Schulung zur Nutzung der neuen Anwendung gestaltet, die Umstellungserfordernisse von Ist zum Soll bleiben der Improvisationskraft der Anwender überlassen. Das überfordert diese naturgemäß und das bisher so wunderbar laufende Projekt kommt trotz gut organisierter Schulung ins Straucheln.

d. Sekundärthemen wurden vernachlässigt

Der Klassiker: die von der neuen Anwendung erzeugten Dokumente wurden nicht an die Anforderungen bzw. Möglichkeiten des neuen Systems angepasst. Mit dieser Aufgabe könnte man schon sehr früh beginnen, aber da man das ja erst ganz am Ende braucht, fallen die dafür notwendigen Ressourcen regelmäßig der Priorisierung zugunsten akuter Herausforderungen zum Opfer. So lange, bis es definitiv zu spät ist.

Zu diesen typischen Sekundärthemen gehören im anwendernahen Bereich auch Formulare, Hilfetexte, Organisationsrichtlinien, Informationen für Kunden und Geschäftspartner über Änderungen der ihnen vertrauten Abläufe und Systeme.

Im technischen Bereich zählen dazu die Konfiguration von Schnittstellen, die Übertragung von Konfigurationen aus dem Entwicklungssystem in das Testsystem und dann ins Produktivsystem und realistische Lasttests mit geeigneten Skalierungs- und Tuningmaßnahmen.

e. Die Testabdeckung war mangelhaft

Das Generieren von Testfällen, mit denen die ganze Bandbreite an Anwendungsfällen abgedeckt wird, ist eine mühsame und nicht sehr motivierende Aufgabe. Werden professionelle Testmanager eingesetzt, fehlt diesen das praktische Wissen aus der Alltagspraxis, sie sind auf Auskünfte von Anwendern angewiesen; diesen erscheint wiederum vieles so selbstverständlich, dass sie es nicht erwähnen.

Der Produktivbetrieb ist daher – nach meiner Erfahrung so gut wie immer – der erste wirklich vollständige Test. Nicht immer: ich hatte auch schon ein Großprojekt, wo wir es geschafft haben, mit ganz wenigen Fehlermeldungen durch die ersten Monate der Produktion zu kommen. Das gelang nicht zuletzt, weil wir eine Business Rules Engine einsetzten, mit der wir die Korrektheit aller Berechnungen und Geschäftsregeln parallel zur Entwicklung der Anwendung umfassend testen konnten. Solange aber diese Logik untrennbarer Bestandteil der Entwicklungsarbeiten ist, ist eine so gute Testabdeckung schon aus logistischen Gründen schwer möglich, denn ein hinreichend stabiles System steht für Anwendertests nicht früh genug zur Verfügung.

Auch hier hat ein agiles Vorgehen Vorteile, allerdings wird auch hier zu oft nicht systematisch getestet. Am häufigsten werden die „Negativ-Testfälle“ vernachlässigt, man testet, ob das System korrekte Dateneingaben und Anwenderaktionen richtig verarbeitet, man testet aber zu wenige Fälle fehlerhafter Eingaben, fehlerhaft migrierter Daten etc. Diese Lücken schlagen dann nach der Produktivsetzung unweigerlich zu.

Zusammenfassend und abschließend: So wie ein Flug erst mit einer guten Landung positiv verlaufen ist, entscheidet sich der Erfolg eines IT-Projektes erst nach der Produktivsetzung. Der Grundsatz von Stephen Covey, „Schon am Anfang das Ende im Sinn haben“, kann daher für IT-Projekte nicht genug betont werden.

Es gibt zu diesem Thema natürlich noch einige wertvolle Ressourcen im Netz. Hier eine kleine Auswahl:

Are You Ready for Go-Live? Eight Essential Questions

Project Cutover-A vital step in Project Go Live

Ein Optimist der scheitert, hat bis dahin ein besseres Leben gehabt als ein Pessimist der bestätigt wird. Mit diesem Satz hat mir Richard David Precht bei seinem Vortrag auf der PM-Welt 2018 am 13.3.2018 aus der Seele gesprochen. Sein eigentliches Thema war allerdings die Frage, welche Auswirkungen die Digitalisierung auf das Projektmanagement hat. Auf dem Weg zur Beantwortung dieser Frage sagte er vieles, was meiner Meinung nach sehr wichtig und meiner Meinung nach auch richtig ist. Hier einige Punkte ohne Anspruch auf Vollständigkeit.

Dass die Digitalisierung wie die vorherigen drei industriellen Revolutionen doch nicht zu einer Reduktion der Arbeitsmenge führen, hält Precht aufgrund der völlig geänderten weltwirtschaftlichen Konstellation für unwahrscheinlich. Die Theorie von Robert Solow hält Precht für kein Naturgesetz und diese würde sich bei dieser vierten industriellen Revolution nicht bewahrheiten.

Welche Berufsgruppen durch die Digitalisierung ihren Job verlieren, könne man nicht exakt vorhersagen, aber jedenfalls gilt dies für Bus-, Taxi- und LKW-Fahrer, sicher für Banken und Versicherungen. Sicher seien Berufe, in denen es auf Empathie ankommt und auch hochwertiges Handwerk. Insofern ist die Zukunft von Projektmanagern wohl auch als eher günstig anzusehen. Das Umfeld wird sich allerdings gravierend verändern, dazu hier noch etwas mehr.

Die Kompensation dieser Verluste durch neue Berufe im digitalen Sektor hält Precht für quantitativ nicht ausreichend und überdies sind das alles sehr anspruchsvolle Berufe, für die nur wenige die notwendigen Qualifikationen erwerben. Der Anteil der Studienabbrecher in der Informatik liegt bei ca. 80 %, weil das Studium einfach sehr schwierig sei.

Grundsätzlich ist jede digitale Technologie, die Menschen assistiert, zu begrüßen, jede substituierende Technologie hingegen kritisch zu sehen oder abzulehnen.

Es steht für Precht außer Zweifel, dass unser Sozialsystem, das auf der Besteuerung von Erwerbsarbeit beruht, nicht mehr haltbar sein wird. Dass dieses evidente Problem von der Politik ignoriert wird, hat er mit dem Aphorismus kommentiert, dass wir heute viel wissen, es aber nicht glauben, während man in früheren Zeiten wenig gewusst, aber viel geglaubt habe.

In diesem Kontext muss man das „bedingungslose Grundeinkommen“ diskutieren. Darauf ging Precht ausführlich ein und stellte fest, dass dieses von völlig diametralen ideologischen Positionen befürwortet wird. Der eine Pol ist das anthroposophisch-idealistische Lager: man sieht dieses Modell als Weg zur Selbstentfaltung der Menschen. Der andere Pol – z.B. fast alle im Silicon-Valley – haben völlig andere Motive. Man sieht, dass die Arbeit durch Digitalisierung weniger wird, schließlich arbeitet man an vorderster Front daran. Aber mit den Daten von Armen kann man kein Geld verdienen, weil diese zwar viel Zeit, aber kein Geld haben. Daher sieht man das bedingungslose Grundeinkommen als notwendige Voraussetzung für die Aufrechterhaltung der eigenen Geschäftsmodelle.

Die Finanzierung eines bedingungslosen Grundeinkommens durch eine Maschinensteuer hält Precht für praktisch undurchführbar. Selbst wenn man sich auf die Bemessungsgrundlage einigen könnte, wäre das nur im internationalen Gleichklang sinnvoll, andernfalls käme es zu internationalen Wettbewerbsverzerrungen zu Lasten der Länder, die das einführen. Es wäre aber sehr wohl möglich, ein bedingungsloses Grundeinkommen durch Mikrosteuern zu finanzieren. Dazu gibt es ein Modell in der Schweiz, das eine Besteuerung von Finanztransaktionen in Höhe von 0,05 % auf jede Finanztransaktion für ausreichend hält, um ein Grundeinkommen von 2.500 CHF monatlich für alle Schweizer zu finanzieren.

In Deutschland oder Österreich müsste dieser Satz etwas höher sein, weil hier der Anteil der Finanzwirtschaft an der Volkswirtschaft geringer ist. Er schätzt, dass hier ca. 0,2 % notwendig wären um ein Grundeinkommen von € 1.500,- monatlich zu finanzieren (Hartz IV liegt derzeit bei € 1.200,- monatlich, ein Grundeinkommen müsste höher sein).

Finanziell wäre das bedingungslose Grundeinkommen also kein Problem, wenn man es will. Die Frage, wie die Gesellschaft und das Leben jedes einzelnen sich verändert und wie man damit zurecht kommt, bleibt aber offen. Änderungen im Wertesystem (im alten Griechenland arbeiteten nur Sklaven, Frauen und Ausländer, heute gilt Nicht-Arbeit als stigmatisierend) und als Voraussetzung im Bildungssystem sind unabdingbar.

Hier Prechts Zusammenfassung im O-Ton, wobei er zu Beginn auf die oben geschilderten Veränderungen des Arbeitsmarktes Bezug nahm, mein spontaner Audio-Mitschnitt setzt erst danach ein. Einfach auf das Bild klicken, MP3 läuft dann ab, Dauer knapp unter 3 Minuten.

Wenn Sie regelmäßig über neue Blogposts informiert werden wollen, tragen Sie sich bitte hier ein. Bitte öffnen Sie dann Ihr Postfach und klicken Sie auf den Bestätigungslink, andernfalls wird die Anmeldung nicht wirksam („Double-Opt-In“).

Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.

Hier das soeben erschienene Buch zu diesem Thema:

Podcast: Play in new window | Download

Einer von mehreren interessanten Vorträgen im Rahmen der PM-Welt 2018 war der von Conny Dethloff, dem Bereichsleiter für „Agile Product and Data Management“ bei OTTO. Er weckte besonderes Interesse, weil er bekannte, nicht mehr Projektmanagement zu betreiben. Genauer: „Wir haben Projekte als Strukturelement abgeschafft und Produktmanagement eingeführt“. Denn, so zusammenfassend am Ende seines Vortrages: „Projekte sind kein Naturgesetz. Taugen sie als Strukturierungselement nicht mehr, um Wert zu generieren, kann man sie durch Anderes ersetzen“.

Nun ist es immer gut, Dogmen in Frage zu stellen. Andererseits sollte man nicht nur um der Pointe willen bewährte Methoden über Bord werfen. Es lohnt sich also, etwas tiefer zu blicken und zu klären, was konkret gemeint ist. Daraus ergeben sich dann auch die Schlussfolgerungen für die eigene Praxis.

Viable Systems Model

Zunächst meine ich, sollte man den Aufgabenbereich nennen, für den Conny Dethloff verantwortlich ist. Es geht um Business Intelligence (BI), die Identifikation relevanter Daten des Marktes und des Unternehmens. Diese Daten sind in Informationen umzuwandeln, die Entscheidungen ermöglichen und zu Handlungen führen. Er hat diesen Bereich nach Value Streams (Wertschöpfungsketten) gegliedert. Er bezieht sich dabei auf das Viable Systems Model, das auf Stafford Beer (1959) zurückgeführt wird. Dass diese Gliederung als Gegensatz zu Projekten gewertet wird überrascht: Projekte sind temporäre Organisationen, Wertschöpfungsketten sind wie Prozesse dauerhafte Organisationselemente. Es wird klar, dass es für den Alltagsbetrieb des BI-Bereiches einfach keine Projekte braucht, es sind End-to-End-Prozesse die auf einen Wertbeitrag für den Kunden ausgerichtet sind. Das könnte man in der Tat in Projektform abwickeln, allerdings wären das relativ kleine Projekte, die alle gleich strukturiert sind.  Dafür ist Projektmanagement tatsächlich nicht adäquat. Sollte er allerdings die derzeitige Gliederung seines Bereiches, die sich schlicht an der Struktur der (internen) Kunden ausrichtet, umstellen, wäre das wohl am besten in Form eines Projektes abzuwickeln.

Theory of Constraints

Conny Dethloff nennt ein weiteres Paradigma, das er anwendet, die  Theory of Constraints (ToC) von E. Goldratt. Dieses Paradigma bestimmt die KPIs der Wertströme, nämlich: „Durchsatz an fertigen Lösungen, die Outcome generieren“, „Bestand an unfertigen Lösungen innerhalb des Wertstroms“ und „Betriebskosten für die Erstellung der Lösungen“. Nun ist auch die ToC ursprünglich ein Prozessmodell, allerdings gibt es eine authentische Anwendung für das Projektmanagement, das Critical Chain Project Management (CCPM). Der Durchsatz und die Minimierung des Bestandes an unfertigen Lösungen sind dort tatsächlich zentrale Steuerungsgrößen. Die Kosten spielen in der ToC ausdrücklich eine untergeordnete Rolle, die Nennung der Betriebskosten in diesem Kontext ist daher überraschend.

Nun geht es mir überhaupt nicht darum, die Reinheit der Lehre von Projekt-, Produkt- und Prozessmanagement zu verteidigen. Hier gibt es eine derartige Vielzahl an Ansätzen und dementsprechend auch mehr oder minder optimale Empfehlungen zur Umsetzung, dass eine solche Diskussion akademischen Kontroversen überlassen werden soll. Theoretische Verwirrung schadet zwar auch der Praxis, aber ich möchte herausarbeiten, was uns Conny Dethloff an beachtenswerten Impulsen gibt und dabei seinen etwas willkürlichen Umgang mit Management-Paradigmen nicht weiter diskutieren.

Impuls 1: „Projektmanagement“ ist eine Hülle, die viel offen lässt

Was als Projekt deklariert wird und wie dieses abgewickelt wird, hängt von vielen Faktoren ab. Wie groß die Aufgabe ist, welche Skills verfügbar sind, wie hoch das Erfolgs-, Termin- und Kostenrisiko ist, welche Vorgehensweisen in der Organisation gut etabliert sind etc. etc. Ob also etwas erfolgreich umgesetzt wird, hängt weniger davon ab, ob man es als Projekt abwickelt, sondern ob man die den Zielen und Rahmenbedingungen am besten angepassten Mittel wählt.

Das ist die Gefahr von Projektmanagement-Standards, dass ohne viel nachzudenken jedes als projektwürdig eingestufte Vorhaben nach einem fixen Schema abgehandelt wird. Gute Standards sollten daher immer Raum für unterschiedliche Varianten der Projektabwicklung bieten. Festlegungen wie z.B. „Es muss einen Lenkungsausschuss geben“, „Der Projektleiter kommt immer aus dem Fachbereich/der IT“, „Es darf keine duale Leitung geben“, „Projekte sind immer in folgenden Phasen abzuwickeln“, sind kontraproduktiv. Projekte sind per definitionem einmalige oder zumindest ungewöhnliche Aufgabenstellungen, daher kann es kein einheitliches Schema für das Management von Projekten geben.

Impuls 2: Ergebnisorientierung ist wichtiger als Prozessoptimierung

ISO 21100, PMI und PRINCE2 definieren Prozesse, die das Management von Projekten ausmachen. An sich ein guter Ansatz, aber wie immer, kommt es auf die Dosis an. Wenn die Fokussierung auf Prozesse und deren Optimierung zu stark wird, leidet der Erfolg. Am stärksten betont noch PRINCE2 die Bedeutung des Projektinhaltes. IPMA geht auf den Inhalt überhaupt nicht ein, in den Kontext-Kompetenzen würde man dies erwarten, sucht jedoch vergeblich.

Ich sehe diesen Aspekt bei allen PM-Standards als krass unterbewertet, denn der Inhalt ist von dominierender Bedeutung ist: „Content is king!„. Ich würde mich niemals darauf einlassen, z.B. ein Bauprojekt zu managen. Aber auch schon in meinen Kompetenzbereich, dem Management von IT-Projekten, würde ich ohne hinreichendes Verständnis für die Inhalte (sowohl der Branche als auch der eingesetzten Technologie) keinen Auftrag annehmen; im Interesse des Auftraggebers und auch im eigenen Interesse, denn ich möchte nicht scheitern, schon gar nicht mutwillig.

Wenn es also der Erfolgswahrscheinlichkeit dient, sind die unterschiedlichsten und ungewöhnlichsten Organisationsformen von Projekten zulässig, wenn das Wertströme, Fraktale, Viable Systems etc. sind, kein Problem, solange das Ergebnis stimmt.

Impuls 3: Das Einzige, was zählt, ist der Kunde

Ganz im Sinne von Geffroys provokantem Buch „Das Einzige, was stört, ist der Kunde„, eine der von mir so geschätzten paradoxen Interventionen, ist eben der Kunde das Maß aller Dinge, auch im Projektmanagement. Das gilt auch für die Organisation der Projektarbeit. Projekte sind temporäre Organisationen, daher ist es auch möglich und sinnvoll, diese so zu gestalten, dass sie optimal zur Kundenorganisation passen. Ein Statement wie „Das widerspricht unserem Projektmanagement-Standard“ sind ein Krisensymptom, außer, der Satz wird sinngemäß so fortgesetzt: „Aber wir werden uns an ihre Anforderungen so anpassen, dass das bestmögliche Ergebnis gesichert ist“. Das heißt nicht, dass man völlig prinzipienlos jeder willkürlichen Anforderung folgt, aber es erfordert eine sehr intensive und von einer positiven Einstellung geprägte Auseinandersetzung mit den spezifischen Gegebenheiten des konkreten Vorhabens. In einem Dialog auf Augenhöhe werden Lösungen entstehen, die das Beste aus beiden Welten in einer einmaligen Weise kombinieren.

Wenn Sie regelmäßig über neue Blogposts informiert werden wollen, tragen Sie sich bitte hier ein. Bitte öffnen Sie dann Ihr Postfach und klicken Sie auf den Bestätigungslink, andernfalls wird die Anmeldung nicht wirksam („Double-Opt-In“).

Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.

Hier noch einige Buchtipps zur Theory of Constraints und deren Implikationen für das Projektmanagement:

Ein erfahrener Springreiter springt nicht höher, als es das aktuelle Hindernis erfordert. Das ist zweifellos vernünftig, es schont die Kräfte für die nächste Herausforderung. Ist das auch die richtige Einstellung wenn es um die Entwicklung einer Anwendung geht? Ich meine: Nein!

Bühne frei für ein Wunschkonzert?

Heißt das, dass ich dafür bin, „gold plating“ zu betreiben, jedes Usability Feature umzusetzen und Automatismen zu implementieren, wo immer jemand eine Idee hat, was man noch automatisieren könnte? Nein, bin ich nicht. Aber ich lehne es auch ab, eine Anforderung nur deshalb zu verwerfen, weil sie nicht zwingend notwendig ist. Ich finde es seltsam, wenn Top-Manager massiv darauf drängen, alle Anforderungen abzublocken, die nicht unbedingt notwendig für den Betrieb der Anwendung sind. Man müsste sie fragen, wozu sie als Dienstwagen einen großen BMW, Audi oder Mercedes fahren, obwohl man mit einem Dacia auch von A nach B kommt. Und man muss nicht beim Meinl am Graben oder beim Käfer einkaufen, es gibt alles, was ein Mensch zum Essen und Trinken braucht auch beim Lidl. Polemischer Vergleich? Naja, ein wenig schon, aber nicht völlig aus der Luft gegriffen. Denn so wie man bei Autos Komfort, Sicherheit, Zuverlässigkeit und auch „Freude am Fahren“ als Entscheidungskriterien akzeptieren muss, sollte man auch bei IT-Anwendungen akzeptieren, dass diese auch Freude machen dürfen, wenn man mit ihnen arbeitet.

Ja oder nein – wie soll man entscheiden?

Natürlich ist es eine Frage der Möglichkeiten und damit der Priorisierung, wie weit man hier gehen kann. Aber Usability und Effizienz ist nicht nur eine Frage des Aufwandes. Es ist mindestens im gleichen Ausmaß auch eine Frage der Kreativität. Und es ist zum allergrößten Teil eine Frage der Fähigkeit und Bereitschaft, den Anwendern genau zuzuhören und ihre Wünsche ernst zu nehmen.

Die Wünsche ernst nehmen heißt aber nicht, diese 1:1 umzusetzen. Damit soll nicht einer überheblichen Einstellung im Sinne von „Wir wissen besser, was der Kunde will als der Kunde selbst“ das Wort geredet werden. Aber ein Designer entwickelt Lösungen, die Kunden überraschen. Lösungen, die eine bessere Erfüllung der Kundenbedürfnisse bieten, als wenn man genau die Vorstellung des Kunden umgesetzt hätte. Ein guter Architekt analysiert die Kundenwünsche sehr genau, leitet daraus Kriterien für gute Lösungen ab. Dann entwickelt er mit seiner speziellen Expertise eine Lösung, die diese Kriterien erfüllt. Ich möchte in keinem Haus wohnen, das genau nach meinen Vorgaben gebaut wurde! Und klassisch Henry Ford: „Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt: schnellere Pferde.“

Priorisierung bei IT-Projekten

Was bedeutet das für IT-Projekte? Wenn man User-Stories sammelt, ist das ein guter Weg, um Wünsche der Anwender möglichst unverfälscht zu erfahren. „Dann hat er die Teile in seiner Hand. Fehlt, leider! nur das geistige Band“, so sagt treffend Goethes Mephisto. Ein Design, eine Architektur entsteht nicht durch Addition von Einzelanforderungen. Sie ist ein eigenständiger kreativer Akt, dessen Ergebnis mit den einzelnen Anforderungen abgeglichen wird, wodurch sich sowohl das Design als auch die Anforderungsdetails verändern. Dieser Prozess wird meist mehrfach durchlaufen. Die Anforderungen bleiben weitgehend konstant, der Architekturentwurf kann sich mehrmals völlig verändern.

Wo macht Architektur den entscheidenden Unterschied?

Nun konkretere Beispiele aus der IT: Ob ich die Geschäftsregeln hart programmiere oder in eine Business Rule Engine auslagere, ist eine Architekturentscheidung. Nur in seltenen Fällen finde ich diese als User Story eines Anwenders vor. Ob ich eine Prozess-Engine implementiere oder nicht, ist natürlich von der Variabilität der Geschäftsprozesse abhängig. Ebenso von den Möglichkeiten der Entwicklungsplattform, die ich nutze und es hat auch etwas mit Kosten zu tun. Die Gestaltung des User Interface ist in den meisten Fällen durch die technische Plattform weitgehend vorgegeben bzw. nur im Rahmen der von dieser gebotenen Möglichkeiten gestaltbar. Es gibt Rahmenbedingungen, die man auch in einem agilen Projekt nicht ändern kann und es gilt: „Gute Architektur kommt nicht von Gelegenheitsarchitekten“.

Setzen wir voraus, dass ein angemessenes Budget für das Projekt zur Verfügung steht. Das heißt keineswegs, dass Geld keine Rolle spielt. Gerade enge Vorgaben setzen oft Kreativität frei und ergeben Lösungen, die man mit mehr Budget nicht gefunden hätte, weil man nicht danach gesucht hätte. Aber wenn ein Projekt deutlich unterdotiert ist, gibt es kein Wundermittel, um es zum Erfolg zu führen. Dazu habe ich an anderer Stelle meine Meinung gesagt. Der notwendige Aufwand hängt von vielen Faktoren ab, die Anwenderanforderungen sind nur einer davon. Auch dazu hier mehr. Die Annahme, dass die Budgetvorgaben realistisch sind, ist also nicht nur notwendig, sie ist auch wahrscheinlich.

Zu bescheiden ist auch nicht gut

Wenn User-Stories gesammelt werden, wiederhole ich als Product-Owner immer wieder: Bitte keine vorauseilende Resignation! Nennen Sie alle Wünsche an die Anwendung, wir werden alle als User-Stories in den Backlog aufnehmen. Das heißt allerdings nicht, dass sie auch realisiert werden. Manche Anforderungen werden in späteren Phasen des Projektes als unzweckmäßig erkannt, manche als unnötig bis störend. Manche erweisen sich als extrem aufwändig in der Realisierung, diese werden dann nochmals hinterfragt und es wird nach Alternativen gesucht, mit denen die Anforderung mit geringerem Aufwand erfüllt werden kann.

Und ich stelle auch noch eine Frage, in späteren Phasen der Anforderungsanalyse: Was würde Sie begeistern? Was wäre ein wirklich cooles Feature? Was dann kommt, weist direkt auf den Engpass der Ist-Situation hin. Und was sich auch regelmäßig zeigt: Es sind Features, von denen die Entwickler meinen, das sei doch nichts Besonderes und kein großer Aufwand. Wenn das so ist, umso besser. Wenn es doch mehr Aufwand und nicht so einfach umzusetzen ist, dann lohnt es sich aber, mehr darüber zu diskutieren. Vielleicht kann man andere Anforderungen zurückstellen, wenn man das coole Feature bekommt. Das ist ein Vorgang, der zwar Verzicht erfordert, aber insgesamt trotzdem mit positiven Emotionen verbunden ist. Die Anwender sind ja Realisten, sie wissen, dass es Grenzen gibt, meist weniger das Budget, sondern die verfügbaren Ressourcen an Entwicklern und Testern.

Am Ende steht also: wir machen soviel wie möglich. Vorrang hat alles, was wirklich wichtig ist. Und zumindest ein Luxus-Feature sollte sich ausgehen, wenn wir sparsam mit unseren Ressourcen umgehen.

Wenn Sie regelmäßig über neue Blogposts informiert werden wollen, tragen Sie sich bitte hier ein. Bitte öffnen Sie dann Ihr Postfach und klicken Sie auf den Bestätigungslink, andernfalls wird die Anmeldung nicht wirksam („Double-Opt-In“).

Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.