Projektmanagement

Die Erfahrungsfalle

von Kishore Sengupta und Tarek K. Abdel-Hamid und Luk N. Van Wassenhove

Auch geübte Manager machen Fehler - und zwar immer wieder die gleichen. Experimente mit Hunderten von Führungskräften zeigen, warum Projekte so oft aus dem Ruder laufen und wie man dies ändern kann.

Angenommen, Sie suchen einen erfahrenen Chef für ein Team von Softwareentwicklern. Dann müsste Alex auf ihrer kurzen Liste ganz oben stehen. Alex ist ein typischer Vertreter der vielen Hundert Projektmanager, die an unserem Forschungsprojekt zu erfahrungsbasiertem Lernen in komplexen Situationen teilgenommen haben. Alex ist mittlerweile ein Routinier und hat fast sein gesamtes Berufsleben lang Softwareprojekte geleitet. Angefangen hat er seine Karriere mit der Entwicklung von Forschungssoftware für die Nasa; später trug er die Verantwortung für immer komplexere Projekte in der Privatwirtschaft und in staatlichen Organisationen.

Wir haben Alex gebeten, seine Fähigkeiten im Rahmen eines Computerspiels unter Beweis zu stellen. Er sollte ein fiktives Softwareprojekt leiten - von der Planungsphase bis hin zur Überwachung und Steuerung des Projektfortschritts und zum Überprüfen der Ergebnisse. Mit einem vorgegebenen Zeitrahmen und Budget sollte er maximale Qualität erzielen (gemessen an der Zahl der Fehler, die am Ende nicht beseitigt sind).

Alex' Entscheidungen und Ergebnisse waren repräsentativ für die gesamte Gruppe. Er begann mit einem kleinen Team aus vier Entwicklern und konzentrierte sich hauptsächlich auf die eigentliche Programmierarbeit. Diese Taktik zahlte sich anfangs aus. Die Produktivität des Teams war hoch, und die Entwickler kamen schnell voran. Als das Projekt aber mit der Zeit umfangreicher wurde als ursprünglich angenommen, traten die ersten Probleme auf. Vergrößern wollte Alex sein Team nicht, also mussten die vorhandenen Mitarbeiter noch eine Schippe drauflegen, um im Plan zu bleiben. Eine hohe Fehlerquote, Verschleißerscheinungen und Burn-out bei den Mitarbeitern waren die Folge.

Jetzt war Alex bereit, das Problem mit zusätzlichen Mitarbeitern anzugehen, aber es dauerte natürlich einige Zeit, bis weitere Entwickler gefunden und eingearbeitet waren. Schnell fiel das Projekt hinter den Zeitplan zurück. Erst in dieser Phase zeigte sich allmählich auch, dass Alex anfangs die Qualitätssicherung vernachlässigt hatte. Die Zahl der Softwarefehler nahm exponentiell zu, und sie zu beheben erforderte sehr viel Zeit und Aufmerksamkeit. Das Fazit am Ende des Projekts: zu spät fertiggestellt, Budget gesprengt und jede Menge Fehler.

Wir haben Alex nach dem Spiel aufgefordert, die Simulation zu analysieren. Hatte ihn das Ausufern des Projekts überrascht? War es die hohe Fehleranzahl, die ihn schockiert hatte, oder die Tatsache, dass Neueinstellungen so schwierig waren? Alex sagte - wie die meisten Teilnehmer -, dass solche negativen Überraschungen bei den meisten seiner Projekte mittlerweile leider der Normalfall seien.

Unternehmensleitungen rechnen aber eigentlich nicht mit Qualitäts- und Personalproblemen, wenn sie erfahrene Manager für wichtige Projekte einsetzen. Sie gehen davon aus, dass Projektmanager wie Alex nach so vielen Berufsjahren wissen sollten, wie man solche Probleme effizient löst - oder von vornherein vermeidet. Bei unseren Experimenten hat sich jedoch gezeigt, dass erfahrene Manager nicht unbedingt auch hervorragende Ergebnisse liefern. Mit Computersimulationen haben wir die Entscheidungsprozesse von Projektmanagern in verschiedenen Situationen analysiert. Und unsere Ergebnisse deuten darauf hin, dass Alex und die anderen Projektleiter während des Spiels aus ihren Erfahrungen nicht die richtigen Schlüsse gezogen haben. Offenbar haben sie bei neuen Entscheidungen nicht die Konsequenzen früherer Entscheidungen berücksichtigt, und auch nach schlechten Ergebnissen änderten sie häufig nichts an ihrem Vorgehen.

Unsere Befragungen haben ergeben, dass den Teilnehmern die Probleme, die während des Spiels aufgetreten sind, durchaus bewusst waren. Auf einer Skala von 1 bis 5 sollten die Testpersonen außerdem bewerten, wie gut das Spiel ihre Erfahrungen aus echten Projekten widerspiegelte, wobei 5 für völlige Übereinstimmung stand. Der Durchschnittswert lag bei 4,32. Das bedeutet: Unsere Experimente bildeten die realen Gegebenheiten bei Softwareprojekten sehr genau ab. Es heißt aber auch: Die Projektmanager hatten Schwierigkeiten, im Experiment die richtigen Entscheidungen zu treffen, obwohl sie in ihrem Berufsalltag bereits ähnliche Situationen erlebt hatten. Dies lässt nur den Schluss zu, dass sie aus den realen Erfahrungen während ihrer Arbeit nichts gelernt haben.

Auf den folgenden Seiten wollen wir drei wahrscheinliche Ursachen für diese offensichtliche Lernschwäche näher untersuchen und schlagen eine Reihe von Maßnahmen vor, mit denen Unternehmen dafür sorgen können, dass der Lernprozess wieder in Gang gesetzt wird.

Warum Projektmanager nicht dazulernen

Wer eine Entscheidung trifft, stützt sich auf sein vorhandenes Wissen, in der Wissenschaft als mentales Modell bezeichnet. Mentale Modelle bestehen größtenteils aus Annahmen über Ursache-Wirkungs-Beziehungen der Umwelt. Wenn Menschen sehen, was als Folge ihrer Entscheidungen geschieht, speichern sie dies als neue Information ab und erwerben Erkenntnisse über die Zusammenhänge ihres Umfelds. Erkenntnisse, von denen die Entscheidungsträger glauben, dass sie auf andere Situationen übertragbar sind, werden in das mentale Modell aufgenommen. Auf den ersten Blick wirkt dieses Vorgehen sehr rational. Jemand formuliert eine Hypothese über einen Kausalzusammenhang, verhält sich entsprechend und interpretiert anschließend das Ergebnis seines Verhaltens, um die ursprüngliche Hypothese zu bestätigen oder zu korrigieren.

Das Problem ist aber: Der Mechanismus scheint nur in relativ einfachen Situationen mit simplen und leicht feststellbaren Ursache-Wirkungs-Beziehungen zu funktionieren. In komplexeren Situationen, zum Beispiel bei einem Softwareprojekt, funktioniert dieser Lernmechanismus häufig nicht. In den Experimenten mit unseren Testpersonen haben wir drei Arten von Komplikationen festgestellt, die bei realen Projekten auftreten und dazu führen können, dass der Lernprozess unterbrochen wird.

Zeitlicher Abstand zwischen Ursache und Wirkung

In der Praxis treten Ursache und Wirkung zeitversetzt auf, und es ist mitunter schwierig, sie miteinander in Verbindung zu bringen. Wir wollten sehen, wie Manager mit diesem Problem umgehen. Daher haben wir unsere Testpersonen im Rahmen einer Computersimulation ein mittelgroßes Projekt zur Entwicklung von Satellitensoftware leiten lassen. Im Laufe des Projekts wurden immer mehr Zusatzanforderungen an die zu entwickelnde Software gestellt, und der Projektumfang nahm beträchtlich zu.

Wir entwarfen vier Szenarien, bei denen zwischen der Entscheidung, einen neuen Mitarbeiter einzustellen, und dessen Eintreffen sowie zwischen dem Eintreffen und der Einarbeitung unterschiedlich lange Zeiträume lagen. Jeder Proband bekam zu Projektbeginn eines der Szenarien zugewiesen. Die Gesamtdauer des simulierten Projekts betrug 18 Monate, und alle zwei Monate mussten die Teilnehmer überprüfen, ob ihre Personalstärke noch angemessen war. Nach Projektende analysierten wir, wie gut die Manager mit den Zeitspannen umgegangen waren. Dazu haben wir ihre Personalentscheidungen sowohl mit dem fiktiven Prototyp eines naiven Managers verglichen, der zeitliche Verzögerungen nie berücksichtigt, als auch mit dem eines perfekten Managers, der diese immer einkalkuliert.

Alle Teilnehmer stimmten in ihren Entscheidungen mehr oder weniger mit dem Prototyp des naiven Managers überein - unabhängig von den Zeitvorgaben ihres Szenarios. Offenbar waren sie nicht in der Lage, die Auswirkungen von Verzögerungen bei ihrer Planung zu berücksichtigen. Dies deutet darauf hin, dass ihr mentales Modell auf einem simplen Situationskontext basiert, bei dem zwischen Entscheidung und Resultat der Entscheidung praktisch keine Zeit verstreicht. Wie groß und welcher Art die Zeitabstände waren, spielte für das Ergebnis eine wichtige Rolle: Teilnehmer, die mit langen Personalbeschaffungs- und Einarbeitungszeiten zurechtkommen mussten, kamen stärker ins Straucheln als Probanden, die mit kürzeren Zeitspannen operieren mussten. Und die Einarbeitungszeit richtig einzuschätzen machte den Teilnehmern stärker zu schaffen, weil Verzögerungen hier schwieriger zu erkennen sind als bei der Personalbeschaffung. Überproportional stark bergab ging es mit der Leistung der Manager, wenn sowohl die Personalbeschaffung als auch die Einarbeitung lange dauerten. Manager mit diesen Vorgaben hatten 83 Prozent mehr Personalaufwand und eine um 40 Prozent längere Projektlaufzeit als Testpersonen mit kurzen Personalbeschaffungs- und Einarbeitungszeiten.

Interessanterweise beschlossen viele Testteilnehmer auch in späten Projektphasen noch, neue Mitarbeiter ins Team zu holen, obwohl sie anschließend sagten, dass dies nicht zu empfehlen sei. Bei den Nachbesprechungen haben wir die Probanden gefragt, was sie für die beste Vorgehensweise halten, wenn ein Projekt zeitlich aus dem Ruder läuft. Die meisten erfahrenen Projektmanager sagten, sie würden kein neues Personal einstellen, sondern zu anderen Mitteln greifen: die Rahmenbedingungen des Projekts ändern, sich auf wenige zentrale Punkte konzentrieren oder das geplante Projektende verschieben. Doch im vorangegangenen Testprojekt hatten sie sich anders verhalten. Wir haben den Teilnehmern in einer zweiten Simulation Gelegenheit gegeben, noch einmal ein fingiertes Projekt zu managen, weil wir sehen wollten, ob sie ihr Verhalten ändern würden. Aber jene Manager, die mit großen zeitliche Verzögerungen umgehen mussten, stellten erneut auch in späten Projektphasen Mitarbeiter ein. Über ein bestimmtes Wissen zu verfügen bedeutet also offensichtlich nicht, dass man auch automatisch danach handelt oder in der Lage ist, es umzusetzen.

Fehleinschätzungen

Die Entscheidungen, die ein Manager im Laufe eines Softwareentwicklungsprojekts trifft, hängen von grundsätzlichen Einschätzungen zu Projektbeginn ab. So beeinflusst etwa die geschätzte Produktivität der Teammitglieder die Entscheidungen über die Größe des Teams, und diese bestimmt wiederum die tatsächliche Arbeitsleistung. Das Problem ist nur, dass die meisten Manager mit ihren anfänglichen Schätzungen danebenliegen.

Um herauszufinden, wie sie mit Fehleinschätzungen umgehen, haben wir in einem weiteren Experiment den Entscheidungszyklus von Projektmanagern unter die Lupe genommen. Wir haben den Testpersonen Schätzwerte für die Produktivität ihres Teams vorgegeben. Im Laufe des Projekts sollten die Leiter dann auf Basis der erzielten Fortschritte in regelmäßigen Abständen die tatsächliche Produktivität bewerten. Zu Beginn erhielt jeder Manager eine von drei Standardschätzungen, wie viele Aufgaben sein Team pro Person und Tag erledigen kann. Für die drei Standardwerte wählten wir einen niedrigen, einen mittleren und einen hohen Wert, um das Phänomen abzubilden, dass verschiedene Prognosetools häufig zu ganz unterschiedlichen Werten für ein und dasselbe Projekt gelangen. An drei Punkten während des Spiels mussten die Testpersonen die Schätzungen aktualisieren: am Ende der Entwurfsphase (5. Monat), in der Mitte der Programmierphase (10. Monat) und am Ende der Programmierphase (15. Monat). Zu jedem dieser Zeitpunkte erhielten die Manager als Entscheidungsgrundlage aktuelle Statusberichte zum Projektfortschritt mit neuen Produktivitätsschätzungen. Diese sollten sie prüfen und anschließend ihre eigene Einschätzung abgeben.

Wir sagten den Teilnehmern, dass der Personalbestand und der Zeitplan auf Basis ihrer Schätzung angepasst werden würden. Tatsächlich wurden die Einschätzungen der Teilnehmer in dem Spiel jedoch nicht berücksichtigt. Alle Testpersonen bekamen identische Statusberichte, damit wir vergleichen konnten, wie sich die Einschätzungen der Teilnehmer entwickelten. Unsere Vermutung war, dass sie sich mit der Zeit einander angleichen würden: Projektmanager, die mit niedrigen Schätzungen gestartet waren, würden diese im Verlauf anheben, und diejenigen, die mit hohen Werten begannen, würden sie sukzessive senken.

Doch was geschah wirklich? Die Schätzungen näherten sich nicht an. Es gab sogar einen deutlichen Trend zu konservativen Korrekturen. Alle Testpersonen korrigierten die Schätzungen im Projektverlauf nach unten, ganz gleich, ob sie mit einem hohen oder einem niedrigen Wert begonnen hatten. Wenn man den Projektmanagern zwei Schätzungen vorlegte (ihre alte und eine neue auf Basis des Statusberichts), stützten sie sich bei ihren Korrekturen immer auf den niedrigeren Wert. Dies ist vermutlich dadurch zu erklären, dass Projektleiter versuchen, sich möglichst viele Ressourcen für ihr Projekt zu sichern.

Zielfixierung

Zu Beginn eines Projekts setzen sich Manager in der Regel Ziele in Bezug auf Kosten, Zeitaufwand und andere Faktoren. Doch in den meisten Fällen ändern sich im Laufe des Projekts die Rahmenbedingungen, oder es treten unvorhergesehene Dinge ein. Die ursprünglichen Ziele sind dann Makulatur und müssen revidiert werden.

Wir wollten sehen, ob die Manager ihre Ziele als Reaktion auf einen veränderten Projektumfang wirklich anpassen würden. Um dies herauszufinden, ließen wir sie in zwei Testgruppen ein Projekt leiten, bei dem die Anforderungen im Verlauf deutlich zunahmen. Jede Gruppe erhielt zu Beginn zwei Zielvorgaben. Die Probanden der "Kostengruppe" sollten 944 Personentage nicht überschreiten und das Projekt binnen 272 Arbeitstagen abschließen. Die Testpersonen der "Qualitätsgruppe" sollten das Projekt mit möglichst wenigen Fehlern und ebenfalls fristgerecht abschließen.

Wir haben die Teilnehmer darauf hingewiesen, dass dies lediglich vorläufige Ziele seien - auf der Basis von Informationen, die zu Projektbeginn zur Verfügung standen - und dass der Erfolg der Teilnehmer am Gesamtergebnis gemessen werden würde. Der Projektumfang wurde nach einem Viertel der Projektzeit ausgeweitet. An diesem Punkt hätten die Projektmanager ihre anfänglichen Vorgaben noch revidieren und Überschreitungen bei Budget oder Zeit einplanen können, um das ursprüngliche Qualitätsziel zu halten. Wir forderten die Teilnehmer nicht explizit dazu auf, ihre Ziele neu zu bewerten, aber wir ließen ihnen diese Möglichkeit bewusst offen.

Doch keine der Gruppen revidierte als Reaktion auf die veränderte Situation ihre Vorgaben. Stattdessen hielten die Teilnehmer beider Gruppen an ihren anfänglichen Zielen fest und schafften schließlich allesamt kein optimales Ergebnis. Die Kostengruppe wollte ihre ursprüngliche Kostenvorgabe einhalten und stellte deswegen weniger Mitarbeiter ein, als nötig gewesen wären. Dafür nahm sie in Kauf, dass das Projekt später abgeschlossen wurde. Den angepeilten Kostenrahmen überzog die Gruppe dank ihres Sparkurses zwar nur um 59 Prozent, aber sie brauchte 17 Prozent mehr Zeit, um das Projekt fertigzustellen, und die Zahl der Fehler schoss in die Höhe.

Das Qualitätsteam stellte dagegen zu viele neue Mitarbeiter ein. Die Spieler dieser Gruppe blieben zwar unter ihrer maximal zulässigen Fehlerzahl, aber sie überzogen die Projektzeit um 9 Prozent und lagen satte 107 Prozent über dem vorgegebenen Budget. In manchen Fällen war es geradezu kontraproduktiv, sich an die alten Ziele zu halten: Die Teilnehmer der Kostengruppe waren häufig so damit beschäftigt, ihre Kostenvorgaben einzuhalten, dass sie die Qualitätssicherung völlig oder größtenteils vernachlässigten. Dabei verursachten sie so viele Fehler, dass die Korrekturmaßnahmen letztlich dazu führten, dass die Projektkosten doch überschritten wurden.

Diese Ergebnisse zeigen: Wenn man Projektmanagern nicht ausdrücklich vorschreibt, dass sie ihre Ziele revidieren müssen, halten sie an den anfangs gesteckten Vorgaben fest - selbst wenn diese aufgrund neuer Entwicklungen nicht mehr angemessen sind. Warum die Manager sich so verhalten, liegt auf der Hand. Die meisten lernen schon sehr früh in ihrem Berufsleben, dass es wichtig ist, die von außen auferlegten Ziele zu erreichen. Diese Erkenntnis nehmen sie in ihr mentales Modell auf. Im Alltag wird diese Haltung oft noch verstärkt. Vorgaben zu korrigieren wird in vielen Unternehmen gleichgesetzt mit Scheitern. Manager lernen schnell, dass es ihrer Karriere mehr nützt, wenn sie ihre Ziele erreichen - selbst wenn dies zu einem schlechteren Gesamtergebnis führt. Bei einer Haltung, die so tief im mentalen Modell verankert ist, verwundert es nicht, dass sie sich auch auf die Entscheidungsfindung in unserer Simulation ausgewirkt hat, auch wenn den Teilnehmern bewusst war, dass der Erfolg letztlich an den Projektergebnissen gemessen werden würde.

Wir haben also herausgefunden, dass es für Manager schwer ist, sich von ihren mentalen Modellen zu lösen, die auf Erfahrungen aus relativ einfachen Situationen basieren oder die ihnen von anderen vermittelt wurden. Treten im Laufe eines Projekts Komplikationen auf, ignorieren die Manager diese einfach oder versuchen, Faustregeln anzuwenden, die nur in simplen Situationen funktionieren. Sie verändern ihre mentalen Modelle nicht in einer Weise, die es ihnen ermöglichen würde, die Situation grundlegend zu verbessern. Für Unternehmen, die nach wie vor Wert darauf legen, dass die Mitarbeiter "on the job" lernen, ergeben sich zwei Schlussfolgerungen:

Erstens: Die beeindruckende Qualifikation von Managern wie Alex sagt nur wenig darüber aus, wie gut sie komplexe Projekte leiten können. Viele Unternehmen machen immer wieder die Erfahrung, dass es nichts bringt, einen Routinier durch einen anderen zu ersetzen. Trotz ihrer Erfahrung mit komplexen Projekten ändern die Projektleiter praktisch nichts an ihren mentalen Modellen, die sie in einfacheren und einander ähnelnden Situationen entwickelt haben. In manchen Fällen fahren Unternehmen sogar besser damit, jemanden ohne Erfahrung einzusetzen.

Das soll nicht heißen, dass alle Manager ohnehin dieselben Entscheidungen treffen. Und es ist durchaus möglich, dass ein Projekt wegen günstiger Umstände gut verläuft oder dass manche Manager sogar gleichbleibend gute Ergebnisse abliefern. Der springende Punkt ist, dass die meisten Projektmanager - selbst die mit einem hervorragenden Lebenslauf - bei ihren Projekten nicht kontinuierlich gute Ergebnisse erzielen oder sich gar verbessern. Und selbst wenn Projektleiter ihre Ergebnisse beständig steigern, ist die Verbesserung vermutlich nur auf eine geringfügig unterschiedliche Erfahrung in der Vergangenheit zurückzuführen und beruht nicht darauf, dass sie systematisch und kontinuierlich aus komplexen Projekten gelernt hätten.

Die zweite Schlussfolgerung hängt direkt mit der ersten zusammen. Wenn es kaum einen Unterschied macht, wie groß die fachliche Qualifikation ist, machen Projektleiter irgendwann nicht mehr ihre eigenen Entscheidungen für ein gescheitertes Projekt verantwortlich, sondern andere Faktoren, zum Beispiel überehrgeizige Vorgaben oder die Forderungen der Finanzabteilung (oder - wie in vielen Fällen - einen Verkäufer, der dem Kunden zu viel versprochen und unrealistische Projektziele gesteckt habe). Wenn sich diese Einstellung erst einmal durchsetzt, suchen die Manager am falschen Ort nach Lösungen für ihre Probleme. Diese Haltung kann der sichere Weg in die Katastrophe sein.

Wie Vorgesetzte Lernen erleichtern

Unsere Untersuchung deutet zwar darauf hin, dass der Lernzyklus bei den meisten Managern komplexer Projekte nicht mehr funktioniert. Aber die Unternehmen können Abhilfe schaffen. Sie können mit einer ganzen Reihe von Maßnahmen dafür sorgen, dass Manager auch aus komplexen Situationen lernen. Einige unserer Empfehlungen nehmen die Probleme des erfahrungsbasierten Lernens einfach als gegeben hin und unterstützen Manager dabei, diese Probleme durch andere Arten des Lernens zu vermeiden. Weitere Ansätze versuchen dagegen, die Schwierigkeiten direkt anzugehen und den Mechanismus der Erkenntnisgewinnung und -verarbeitung zu verbessern. Unternehmen, die sich an die folgenden Empfehlungen halten, werden schnell feststellen, dass ihre Fähigkeit, die Ergebnisse im Projektmanagement zu verbessern, kontinuierlich zunimmt.

Mehr kognitives Feedback erteilen

Bei Projekten gibt es viele Informationen, insbesondere Feedback über die Projektergebnisse, die in Statusberichten festgehalten werden. Aber in Situationen mit unklaren Ursache-Wirkungs-Beziehungen ist ergebnisbasiertes Feedback kein wirksames Mittel, um Erkenntnisse zu gewinnen oder die Ursachen eines Problems zu ergründen. Stattdessen benötigen Manager Feedback, das ihnen Aufschluss über die Zusammenhänge zwischen wichtigen Variablen der Projektumgebung gibt, besonders im Projektverlauf. Solche Informationen werden kognitives Feedback genannt.

Die Grafik oben liefert ein Beispiel dafür: Sie zeigt den Zusammenhang zwischen der Anzahl der Mitarbeiter, die mit Qualitätssicherung befasst waren, und der Fehlererkennungsquote in den ersten 80 Tagen eines Projekts. In diesem Fall hat der Manager die Qualitätssicherung erst im Verlauf des Projekts ausgeweitet. Die Quote der gefundenen Fehler steigt zwar dementsprechend an, allerdings zeitversetzt und nicht proportional, weil ja verstärkt an der Fehlererkennung gearbeitet wird. Später sinkt die Quote wieder, was darauf hindeutet, dass nun die meisten Fehler erkannt werden; der Projektmanager kann die Anzahl der Mitarbeiter in der Qualitätssicherung jetzt auf diesem Niveau belassen oder sogar wieder reduzieren. Diese Art Feedback ist zwar nicht frei von Fehlern, aber sie liefert den Projektleitern Erkenntnisse über dynamische Zusammenhänge.

Unsere Untersuchung hat gezeigt, dass dies klare Vorteile bringt: Manager, die in unserer Simulation kognitives Feedback bekamen, hatten ein besseres Verständnis der Gesamtsituation und trafen Entscheidungen, die zu besseren Ergebnissen führten. Wir raten Unternehmen, kognitives Feedback zu einem festen Bestandteil ihrer Statusberichte zu machen. Wir haben festgestellt, dass diese Art des Feedbacks sogar noch nützlicher ist, wenn Daten verschiedener Projekte kombiniert werden. So können Auswirkungen bestimmter Maßnahmen auch über mehrere Projekte hinweg analysiert werden.

Ein führender Hersteller von Unternehmenssoftware setzt bei seinen Entwicklungsprojekten kognitives Feedback ein. Das dortige Management ist sich einig, dass die Projektleiter dadurch bessere Erkenntnisse gewinnen. Und sie scheinen tatsächlich bessere Entscheidungen zu treffen: Die Firma hat errechnet, dass der Anteil der Problemprojekte binnen drei Jahren um 56 Prozent gefallen ist.

Lesen Sie im zweiten Kapitel, wie Sie Ziele besser setzen und warum sich Simulationen lohnen. Konzentrierter planen, besser entscheiden