Schlagwort-Archive: unterspezifizierte Initialkonditionen

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

Bye, bye Requirements Engineering

Im Zusammenhang mit Anforderungen sind die Funktionen eines Systems zentral. Auch blosse Eigenschaften können Funktionen sein. In Zertifiziert für das Unmögliche: Anforderungen formulieren habe ich gesagt, dass in Migrations- und Integrationsprojekten meistens Standardsysteme zum Einsatz kommen, die allenfalls customized werden. Solche Projekte können nicht vollständig spezifiziert werden, weil niemand in der Lage ist, alle Funktionen eines (Standard-)systems zu kennen. Denken Sie z.B. an ein Automobil, genauer gesagt, einen Personenwagen (PW). Glauben Sie, sie könnten die Funktionen eines PW aufzählen? Wahrscheinlich sind Sie nicht einmal in der Lage, auch nur 10% aller Funktionen eines PW aufzuzählen, und dies nicht nur wegen des Problems unterspezifizierter Initialkonditionen, von dem Fischhoff et al. berichten1. Es gibt immer auch hidden functions. Klaus Pohl berichtet, dass allein die Steuerung einer PW-Elektronik 2’500 Funktionen umfasst2. Jede dieser Funktion ist auch eine Funktion des PW. Natürlich interessieren Sie sich allenfalls für ein halbes Dutzend dieser Elektronikfunktionen, der Rest sind eben hidden functions, mit denen Sie sich gar nicht erst auseinandersetzen wollen. Aber können Sie sicher sein, dass sich nicht eine dieser 2’500 Funktionen für Sie negativ manifestieren wird? Es könnte doch sein, dass sich eine dieser unzähligen Funktionen mit der Zeit für Sie als lästig bemerkbar machen wird. In vollständigen Anforderungen an das System PW hätten Sie diese Funktion ausdrücklich untersagt, wenn Sie sie im Voraus gekannt hätten. Hidden Functions von IT-Systemen, die in komplexe Umgebungen eines informationsintensiven Unternehmens integriert werden müssen, stören oft andere Systeme, weil die Entwickler nicht alle Umgebungen kennen konnten, in welchen ihr System jemals in Einsatz gelangt.

Im übrigen gibt es Funktionen, die eigentlich Funktionenkomplexe sind. Beispielsweise ist doch die wichtigste Funktion eines PW, dass er fahren möge. Meinen Sie „fahren“ oder „transportieren“? In jedem Fall verbirgen sich hinter beiden Funktionenkomplexen viele Einzelfunktionen, wie z.B. vorwärts fahren, rückwärts fahren, im Schritttempo vorwärts fahren, sehr schnell vorwärts fahren. Meinten Sie „transportieren“, so sind Einzelfunktionen eine Person transportieren, mehr als eine Person transportieren, im Rahmen des Strassenverkehrsgesetz transportieren, Waren transportieren, mehr als einen Kubikmeter Waren transportieren, usw. Die Unterteilung eines Funktionenkomplexes ist sehr willkürlich. Wann haben Sie hinreichend unterteilt? Wann haben Sie zu sehr fragmentiert? Was ist überhaupt noch eine Funktion? Schliesslich gibt es Sekundärfunktionen. Z.B. kann ein PW auch die Funktion haben, Ihnen gesellschaftliches Ansehen zu verleihen, oder zumindest Ihnen den Eindruck zu geben, dass Sie wegen Ihres PW zu mehr gesellschaftlichem Ansehen gelangen.

Ein System kann auch implizite Funktionen haben. Das sind solche, die niemand spezifiziert und entwickelt hat. Alle die 2500 Funktionen der Elektroniksteuerung mussten einzeln spezifiziert und implementiert werden. Auch die Funktion, gesellschaftliches Ansehen zu verleihen, wurde zumindest teilweise explizit spezifiziert, z.B. durch ein schnittiges Design oder durch entsprechendes Marketing. Ein Porsche kostet nicht nur so viel, weil er wirklich so gut ist, sondern auch, um eben den Namen Porsche als Nobelmarke zu platzieren. Aber ein PW kann auch Funktionen haben, die nicht spezifiziert worden sind.

Wie wir sehen ist es nie möglich, abschliessend zu sagen, wieviele Funktionen ein System hat oder haben kann. Bye, bye Requirements Engineering!

1B. Fischhoff, P. Slovic & S. Lichtenstein. Fault Trees: Sensitivity of estimated failure probabilitiesto problem representation. Journal of experimental psychology: Human Perceptions and Perfomance. 4/1978, 330-334

2Klaus Pohl. Leitfaden für modellbasiertes Requirements Engineering und Requirements Management softwareintensiver Eingebetteter Systeme
gefördert durch das BMBF im Rahmen der Forschungsoffensive „Software Engineering 2006“