Schlagwort-Archive: Anforderungskatalog

Projekte scheitern am Top-Management

Unter dem Titel Verhalten des Linienführungskräfte im Projektmanagement veröffentlichte Dr. Stefan Hagen in seinem pm-blog eine interessante Liste mit 10 häufigen Managementfehler1. Der zweite und elfte Eintrag der Liste lautet

Die Projektteams werden direkt oder indirekt gezwungen, den Best-Case zu planen. Wenn dieser dann nicht eintritt, wird das Team oder der/die Leiter/in verantwortlich gemacht

Das ist leider nur allzu wahr. Allerdings handelt es sich um ein einfaches Gefangenendilemma, aus dem es noch immer kein Entkommen gibt. Wenn das Unternehmen das Projekt gewinnen will, muss es ein attraktives Angebot machen. Da man heute Attraktivität mit „billig“ oder gar „gratis“ verwechselt, erhält derjenige mit dem niedrigsten Preisangebot den Zuschlag. Daher bietet der Verkäufer das Projekt 10% unter dem Preis an, der der Projektleiter gerechnet hat, nachdem ihm der Verkäufer sagte, er soll nur den best-case rechnen.

Ein weiterer Eintrag der Liste heisst:

Unklare Aufträge, kaum klare Zielvorgaben

Das ist meines Erachtens kein Fehler. Ich nenne das unterspezifizierte Initialkonditionen2. Stellen Sie sich vor, alle Wissensspeicher (Bücher, Web, etc.) sind auf einmal weg. Nur das Wissen in den Köpfen der Menschen existiert noch, und Sie hätten den Auftrag, innerhalb einer kurzen Zeit ein Lexikon zu schreiben. Sie müssen aufschreiben, was Ihnen in den Sinn kommt. Na, was glauben Sie, wie vollständig die erste Auflage Ihres Lexikons würde? Es ist äusserst schwierig, sich etwas aus den Fingern zu saugen, wo noch nichts da ist. Das Wissen, was man will, bildet sich erst im Verlauf des Projekts. Ein Projekt ist eine Wissensgenerierungsmaschine.

Folgendes ist ein Fehler, der schlicht auf Ignoranz beruht:

Die Ressourcen werden bewusst permanent überlastet

Manager meinen, sie müssten ihre Ressourcen immer zu 100% auslasten. Dabei wird aber das Unternehmen höchst ineffizient, wie schon Elyahu Goldratt bewies3. Stellen Sie sich vor, Sie hätte nur zwei Mitarbeiter. Der erste erledigt eine Arbeit in 5 Minuten, der zweite braucht zur Weiterverarbeitung 10 Minuten. Was glauben Sie, was passiert, wenn beide zu 100% ausgelastet werden? Das Unternehmen wird schnell seine Tore schliessen und die Bilanz deponieren. Natürlich darf in diesem Beispiel die erste Ressource stets nur zu 50% ausgelastet sein. Im Alltag, und vor allem wenn Wissen verarbeitet wird, ist die Sache natürlich nicht so eindeutig. Aber dennoch lässt sich mit ein wenig Nachdenken verstehen, dass Leute nicht zu 100% ausgelastet werden dürfen, wenn die Zusammenarbeit effizient sein soll.

Stefan Hagens Lösungsansätze können mit „aktive Managementawareness“ zusammen gefasst werden.
Die besten Erfahrungen habe ich dort gemacht, wo periodisch unkomplizierte Steeringboards stattgefunden haben, die aus Mitgliedern des Top-Managements bestanden. Als Projektleiter konnte ich meine Sorgen auf den Tisch legen und direkt mit dem höchsten Chef besprechen. Dieses Vorgehen hat mindestens zwei Voraussetzungen:

  1. Der Top-Manager muss die Projektleiter kennen und mit ihnen schon mal ein Bier getrunken haben.
  2. Die Unternehmenskultur muss so sein, dass ich Probleme auch dann beklagen kann, wenn mein direkter Vorgesetzte anwesend ist

Die beiden Voraussetzungen sind leider ziemlich anspruchsvoll.

1Hagen, S. Verhalten der Linienführungskräfte im Projektmanagement. pm-Blog, 29. April 2010.
http://pm-blog.com/2010/04/29/verhalten-der-linienfuhrungskrafte/

2Addor, P. Projektdynamik – Komplexität im Alltag. S. 151. Reinhold Liebig Verlag. Frauenfeld 2010

3Goldratt, E. & Cox, J. Das Ziel. Campus Verlag. Frankfurt a.M. 2008

Von Nichts kommt nichts

Zwar kann durchaus etwas aus dem Nichts entstehen (Energie des Vakuums), aber sicher keine vollständigen Anforderungskataloge.

Ich mache mir zuweilen einen Sport daraus, Gesprächspartner, die behaupten, dass sie mit Projekten zu tun haben, nach ihren Erfahrungen zu befragen. Insbesondere bin ich interessiert zu wissen, wie sie mit Problemen umgehen. Kaum einer will wissen, wovon ich spreche. Wenn ich erkläre, dass es doch zu Termin- und Budgetüberziehungen kommen könne, tun sie so, als hätten sie davon zwar schon gehört, aber nie selbst erlebt. Da geht es mir wie mit Autofahrern, die z.B. bei der Rückfahrt nach längeren Feiertagen im Stau stecken bleiben. Ich kenne keinen. Jeder, den ich frage, stritt bislang ab, jemals in einem längeren Stau gesteckt zu haben. Schliesslich sei das nur eine Frage der Organisation, wann man wo lang fährt. Und keiner der Autofahrer, die ich kenne, ist derart unbeholfen, z.B. nach Ostern am falschen Tag zurück zu fahren und erst noch über eine Strecke, die für Staus bekannt ist. Genauso wenig kennen ich privat Projektleiter, die in ihren Projekten Schwierigkeiten haben. Nur bei meinen Kunden gibt es schwierige Projekte. Gemäss Standish Chaos Report 2004 sind immer noch weniger als 30% aller Projekte erfolgreich1. Ich kann einfach nicht glauben, dass alle meine privaten Bekannten in diesen 30 erfolgreichen Prozente tätig sind. Aber sie sind sich alle einig, dass es bestimmt an der ungenauen Zieldefinition liege, oder – was auf dasselbe heraus kommt – an der Unvollständigkeit der Anforderungsbeschreibung.

Sie erinnern sich an meinen Beitrag Migrations- und Integrationsprojekte sind anders nach dem der Standish Chaos Report zum Schluss kommt, dass die Hauptursache von Schwierigkeiten in Projekten mangelhafte Zieldefinitionen und unvollständige Anforderungskataloge sind. Aber der Report bezieht sich auf Entwicklungsprojekte. In Migrations- und Integrationsprojekten können Ziele nie definitiv festgeschrieben werden, denn erst beim Bau eines Systems tauchen die richtigen Fragen auf, deren Antworten Teil der Zieldefinition sind. Anforderungs- und Spezifikationsänderungen durch den Kunden liegt selten an seinem Charakter. Natürlich gibt es immer wieder Leute, die aus persönlicher Unzufriedenheit oder Unentschlossenheit nie wissen, was sie wollen und ihre Wünsche laufend ändern. Hat eine solche Person beim Kundenunternehmen die „richtige“ Stelle inne, dann kann sie jedes Projekt vergiften. Letztendlich handelt es sich um ein Führungsproblem. Bevor jedoch der Projektleiter des Lieferanten eine Eskalation machen kann, muss er ein gut dokumentiertes „Sündenregister“ des Kunden-Projektleiters vorlegen können. Bis er das hat, wird das Projekt bereits sehr schief liegen. Es ist anzunehmen, dass er bis zu diesem Zeitpunkt ebenfalls Fehler gemacht hat, die ihm dann in einem unschönen Kreuzfeuer vorgeworfen werden, vielleicht sogar vom eigenen Management.

Im allgemeinen deutet Changing Requirements and Specifications auf die Tatsache hin, dass im Laufe des Projekts das Wissen über den Projektgegenstand zugenommen hat, was eine Redefinition der Ziele notwendig macht. Ein flexibler und erfahrener Projektleiter antizipiert das und sucht das Gespräch mit dem Auftraggeber. Gemeinsam müssen sie einen Weg suchen, der den veränderten Rahmenbedingungen gerecht wird, ohne dass das Projekt allzu sehr darunter leidet. Wirft der Lieferant dem Auftraggeber in einem verbockten Projekt jedoch vor, er hätte laufend die Ziele oder Spezifikationen geändert, disqualifiziert er sich selbst, indem er zugibt, die Notwendigkeit einer Reformulierung nicht erkannt zu haben.

Ein vollständiger Anforderungskatalog oder eine vollständige Zieldefinition würde bedeuten, dass der Auftraggeber im Voraus seine Bedürfnisse bis in das letzte Detail aufzählen kann. Man weiss aber schon lange, dass dies nicht möglich ist. Beispielsweise haben Fischhoff et al. Versuchspersonen verschiedene Versionen eines Diagramms gezeigt, das beschreibt, wie ein Auto funktioniert1. Die verschiedenen Versionen unterschieden sich in der Vollständigkeit. Die Versuchspersonen wurden gefragt, ob ein Auto, das gemäss diesem Diagramm aufgebaut ist, anspringen würde. Die Versuchspersonen bemerkten fehlende Teile kaum. Selbst das Weglassen so wichtiger und allgemein bekannter Teile wie Zündung und Benzinversorgung wurden kaum bemerkt. Die Versuchpersonen waren daher nicht in der Lage, lückenhafte Diagramme zu komplettieren. Wenn es also für ein im Betrieb stehendes und weitverbreitetes System wie das Auto nicht möglich ist, auch nur die primitivsten Anforderungen zu notieren, so ist es für ein noch zu entwickelndes und zu bauendes System erst recht unmöglich.

1B. Fischhoff et al. Fault trees: Sensitivity of estimated failure probabilitiesto problem representation. Journal of Experimental Psychology: Human Perception and Performance, 1978, 4, 330-334

Reisen Sie in jeder Jahreszeit in eine andere Region!

Kürzlich wurde mir eine wunderbare Aufgabe gestellt. Vier Personen wollen vierteljährlich eine Reise in eine von vier Regionen unternehmen. Jedes Jahr soll jede Region genau einmal besucht werden. Keine Region soll zweimal hintereinander und je in derselben Jahreszeit besucht werden. Abwechslungsweise sollen die vier Personen die Reisen organisieren. Keine Person soll zweimal hintereinander eine Reise organisieren müssen. Darüber hinaus soll jede Person eine Reise in eine Region und in einer Jahreszeit nur einmal organisieren müssen.

Es wird schnell klar, dass die Reiserei nach vier Jahren die Bedingungen erschöpft hat. Länger als vier Jahre lassen sich die Bedingungen nicht aufrecht erhalten. Trotzdem ist schon nur die Formulierung der Aufgabe ein Problem für sich. Zwar sollten die meisten Menschen rasch verstehen, was Sache ist, aber eine präzise Formulierung aller Bedingungen ist schwierig. Ich bin mir noch nicht sicher, ob obige Aufgabenstellung die Bedingungen vollständig enthält und die Aufgabenstellung eindeutig beschreibt. Erstaunlich, wenn man bedenkt, dass die Situation nur ein paar hundert Möglichkeiten offen lässt, dass es nur um dreimal vier Elemente geht und diese nur während vier Jahren gespielt werden. Für eine so einfache Situation bietet die Formulierung der Anforderungen bereits ein Problem.

Eine mathematische Aufgabe ist in jedem Fall ein Projekt. Zum Beispiel könnte sie am Anfang einer Dissertation stehen. Die Dissertation und damit die Lösung der Aufgabe ist das Projekt. Manchmal sprengt sie die Terminvorgaben. Es gibt Aufgaben, die erst nach Jahrhunderten gelöst werden. Die einfache Aufgabe, zu entscheiden, ob jede gerade Zahl (grösser als 2) die Summe zweier Primzahlen sei, ist seit 1742 immer noch ungelöst (auf die 1 Mio Dollar ausgesetzt ist). Wenn eine mathematische Aufgabe ein Projekt ist und in unserer (einfachen) Reise-Aufgabe die Formulierung der Anforderungen schon Schwierigkeiten macht, wieviel schwieriger ist es, die Anforderungen in einem wirklich komplexen Projekt zu formulieren?

Die Beschäftigung  mit der Problemstellung erhöht unser Wissen, auf was man achten muss, womit sie zu tun haben könnte, welche Zusammenhänge bestehen, usw. Z.B. wird einmal klar, dass wir es bei der Aufgabe mit einer binären Relation auf der Menge der Permutationen von vier Elementen zu tun haben. Es gibt 24 Permutationen von vier Elementen. Man kann sie als Deckbewegungen eines Teraeders interpretieren. Was hat die Reisetätigkeit zweier Paare mit einem Tetraeder zu tun? Es ist genau wie in einem Migrations- und Intergrationsprojekt: die Beschäftigung mit dem Projektgegenstand erhöht unser Wissen, worauf zu achten ist und welche Fragen wir stellen müssen. Es ist unmöglich, am Anfang eines Projekts die richtigen Fragen zu stellen, denn wir haben noch gar nicht das relevante Wissen dazu. In unserer Reiseaufgabe steht am Anfang natürlich die Frage nach den vier Jahresprogrammen. Wenn man sich etwas mit der Aufgabe beschäftigt kommt der Verdacht hoch, dass die Aufgabe nicht lösbar sei. Dann möchte man wissen, warum sie nicht lösbar ist und welches die Lösung ist, die die Bedingungen am wenigsten verletzt. Auch in Migrations- und Integrationsprojekten könnte sich herausstellen, dass die gewünschte Aufgabe nicht so zu erfüllen ist, wie man sich das ursprünglich vorgestellt hatte und auch dort geht es dann darum, die bestmögliche Lösung zu finden. Eine solche Einsicht verändert die Laufzeit des Projekts, stellt die Budget- und Terminvorgaben in Frage und kann zu Konflikten führen.

In unserer Reise-Aufgabe muss man nun die Fragestellung ändern. Aber wie formuliert man die neue Problemstellung? Man stellt z.B. irgend einmal fest, dass zwei Permutationen a und b dann miteinander in Relation stehen, wenn die zweite Stelle von a gleich der dritten Stelle von b ist, nämlich z.B. dann wenn im Sommer Region 3 besucht wurde. Man möchte jetzt wissen, wie viele Permutationspaare sich in einer gewissen Relationsklasse befinden und wie sich zwei Relationsklassen überschneiden. Aber wie formuliert man das? Was ist genau abzuklären? So können auch während eines Projekts Fragen auftauchen, die die Projektmitarbeiter, sowohl auf Kunden- als auch auf Lieferantenseite, nicht genau formulieren können. Man weiss nur, das es da irgend etwas abzuklären gilt. Aber was? So ist die Gefahr gross, dass man einfach mal los testet und prüft und schraubt, einfach in der Hoffnung, einmal auf eine Erkenntnis zu stossen, die genau das ist, wonach man gesucht hat. Das ist natürlich fatal, denn damit kann man viel Zeit verlieren.
Ich möchte damit sagen, dass unser Wissen mit der Projektarbeit zunimmt, und wir erst ab einer gewissen Menge an Wissen überhaupt sagen können, was wir eigentlich erwarten oder eben nicht erwarten. Zielformulierung, Wissen und Beschäftigung mit dem Gegenstand bedingen einander. Ohne dass wir uns eingehend mit dem Projektgegenstand beschäftigt haben, haben wir zu wenig Wissen, um die richtigen Fragen zu stellen und sagen zu können, was wir wollen.