Episoden

Uhrwerk

Multiprojektmanagement – Ein System ist mehr als die Summe seiner Teile

Sie sind unglücklich mit Ihrer Entwicklungsabteilung

Vor allem sind Sie unglücklich mit dem Output. Sie entwickeln nicht schnell genug, Sie entwickeln nicht genug Produkte, Sie stehen unter Druck zu liefern. Der Druck ist schon hoch, für Sie und die Mannschaft und dennoch geht immer etwas schief. Ein Termin wird gerissen, eine Punkt des Lastenheftes fällt unter den Tisch, die Kosten sowohl des Projektes, als auch des Produktes laufen weg. Das wollen Sie verbessern, das müssen Sie verbessern. Aber wie, darüber will ich mit Ihnen heute reden.

Verspätung von Projekten

Kennen Sie das? Der Druck ist da und Sie wollen vertrauen zurückgewinnen, nein eigentlich ist es schon so weit, dass Sie Vertrauen gewinnen müssen. Und dann diese Nachricht: Das Projekt Charlie verspätet sich um 6 Wochen. Der bisherige Plan lässt sich nicht halten. Muss das gleich so eine große Verschiebung sein? Sie schauen sich den Plan selber an, lassen die Mannschaft berichten und ja, es wird länger dauern. Sie hätten nur gerne eine kleinere Verschiebung oder mindestens doch früher davon gewusst. Schließlich haben Sie vor drei Tagen der GF gerade berichtet, dass alles in Ordnung sei und jetzt das, 6 Wochen.

Das erste, was unter Druck auf der Strecke bleibt ist die Wahrheit. Keiner hat Ihnen das angekündigt, vielleicht haben sie es auch alle nicht gesehen, oder nicht sehen wollen. Aber das kann doch nicht sein, dass so etwas vom Himmel fällt.

Projekte dauern zu lange

Und wenn alle Projekte sich mehrfach verspäten, dann dauern sie auch zu lange. Erstens schon mal länger als geplant. Das kostet Glaubwürdigkeit. Das tut weh, weil damit das Risiko einher geht, dass alle Aussagen hinterfragt werden.

Zweitens länger als im Business case, der Projektergebnisrechnung vorgesehen. Die Projekte sind also wirtschaftlich schwächer als geplant, schwächer als gedacht. Also werden sie wieder hinterfragt. Es wird neu priorisiert, gestrichen, umformuliert. Nur was passiert eigentlich mit den Projekten, in die schon viel Blut, Schweiß und Tränen eingeflossen sind wenn sie angehalten werden. Schlimmstenfalls entstehen Zombieprojekte. Nicht lebendig und nicht tot. Es wird nichts mehr gemacht, aber die Ressourcen werden nicht sauber freigegeben. Auch in den Köpfen der Organisation. Eine typische Nichtentscheidung.

Besser die Projekte werden richtig beendet und abgewickelt. Die Ressourcen werden wieder frei, die Mitarbeiter können sich wieder neuem zuwenden. Aber wer einmal Blut, Schweiß und Tränen in ein Projekt gesteckt hat und zusehen muss, wie es gestrichen wird, der steckt das nächste Mal nur noch seine Arbeitsleistung rein. Auch das wirkt sich auf die Produktentwicklung aus. Von der Arbeitskraft, die einfach verpufft ist und nie Werte geschaffen hat ganz zu schweigen. Wir verdienen ja kein Geld mit einem halbfertigen Produkt.

Also doch besser keine Projekte streichen, nur was macht man mit einem Projekt, das bei neuer Betrachtung nicht mehr wirtschaftlich ist? Weiter machen oder einstellen? Dazu muss man sich anschauen, nach welcher Wirtschaftlichkeitsrechnung Sie diese Entscheidung stellen wollen.

Schauen Sie Sich die ganze Projektlaufzeit an? Also auch in die Vergangenheit? Und machen dann eine umfassende Wirtschaftlichkeitsrechnung und stellen fest: Mit dem Business Case würden Sie das Projekt so nicht starten. Nur, seien wir da ganz klar. Wer so denkt hat den grünen Tisch nicht verlassen. Sie haben nicht die Möglichkeit, die Zeit zurückzudrehen und zu entscheiden, ob Sie das Projekt machen oder nicht. Das war gestern. Diese Entscheidung ist hypothetisch. Sie hat in der Realität nichts zu suchen.

Die Entscheidung, die Sie heute fällen können ist einstellen oder weitermachen. Aber niemand wird Ihnen die bisherigen Kosten zurückgeben. Das sind sunk cost. Das Geld ist weg und niemand bringt es zurück. Wenn das Ihre Kultur ist, können Sie jetzt einen Schuldigen suchen, aber das ändert nichts an der Tatsache, dass die einzige Entscheidung, die Sie jetzt fällen können ist: Einstellen oder weitermachen.

Einstellen heißt: Geld ausgegeben haben, das keiner mehr zurückgibt. Und dafür null Gegenwert erhalten. Also abschreiben. Fehler gemacht. Aufstehen, aufräumen, weiter machen.

Oder weiter machen. Und weitermachen heißt weiter Geld ausgeben. Aber hier ist die Frage, was haben Sie schon geschafft? Wieviel ist noch zu tun? Und wenn Sie Sich anschauen, wieviel Sie noch ausgeben müssen und was sie dann zurückerhalten, nämlich den kompletten Erlös aus einem fertig entwickelten Produkt. Ist das Rest-Projekt dann nicht doch gut.

Es gibt Projekte, bei denen ist es die richtige Entscheidung, sie fertig zu machen, weil der gesamte Projektnutzen am Ende kommt, obwohl es keinen Sinn machen würde, sie anzufangen. Das klingt paradox, liegt aber an den sunk cost: Sie entscheiden darüber einen Teil der Kosten auszugeben, um den kompletten Erlös zu erhalten. Im Einzelfall ist das dann die richtige Entscheidung. Für das Unternehmen ist es aber fatal, wenn das häufiger vorkommt.

Wenn Sie so organisiert sind, dass sie immer tolle Projekte starten, die gut aussehen und die Firma nach vorne katapultieren werden, dann aber sich verspäten und die Kalkulation sich so verschiebt, dass Sie das Projekt nie hätten starten sollen, dann tun Sie Ihrer Firma nichts gutes. Dann machen Sie ein unwirtschaftliches Projekt nach dem anderen und das schlägt dann auch auf Ihr Unternehmen durch.

Besser Planen und mehr managen

Die offensichtliche Reaktion bei soviel Schlendrian ist es, die Zügel anzuziehen und mehr zu planen und mehr zu managen. Geht ja offensichtlich nicht ohne. Der Projektplan wird detaillierter, der Aufwand steigt, mehr Berichte, mehr Hinterfragen, weniger Vertrauen.

Aber wird das Projekt dadurch besser? Befriedigt das nur das Bedürfniss nach Zucht und Ordnung, oder ist das wirklich zielführend? Ich persönlich glaube da gar nicht daran, dass mehr Kontrolle hilft. Vor allem nicht, wenn das heißt, dass die Entscheidungen weiter oben in der Hierarchie gefällt werden. Das heißt nämlich nur, dass die Entscheidungen noch später kommen, die Manager sind ja ach so beschäftigt. Und sie werden häufig schlechter. Liegt auch an schlechten Entscheidungsvorlagen, aber hat meist damit zu tun, dass weiter oben in der Hierarchie weniger Wissen über die Details vorhanden ist und dadurch Entscheidungen hier häufig mal unerwünschte Nebenwirkungen haben. Es hat einen Grund, warum in normalen Zeiten, die Entscheidungen so nah an der Arbeit wir möglich gefällt werden.

Aber unterstellen wir einfach mal, dass sich manche Projekte besser benehmen, wenn sie stärker kontrolliert werden. Dann haben wir immer noch den ganzen Overhead durch mehr Planung und mehr Kontrolle, der unser Projekt und die Arbeitsleistung belastet. Das kann eine gute Investitions sein, aber ändert nichts daran, dass in einer angespannten Zeit, jetzt noch weniger Ressourcen in die inhaltliche Arbeit gehen und mehr verwaltet wird.

Kompliziert und Komplex

Sehr spannend ist in diesem Zusammenhang die Frage, welche Projekte denn überhaupt geeignet sind, von mehr Planung zu profitieren. Ein einfaches Problem wird Sie nicht so schmeißen, dass Sie in die Verzweiflung kommen, es mit großem Projektmanagementoverhead zu bändigen. Die fallen raus. Die komplizierten Probleme, die sind es doch, Das hieße ja, das Sie vorher wissen, was Sie Schritt für Schritt machen müssen. Sie haben eine Ursache Wirkungsbeziehung und auch wenn Sie etwas komplizierter ist, so ist sie doch grundsätzlich durch Analyse erschließbar.

Viele technische Probleme sind so. Wenn Sie den Weg haben, ist es vielleicht aufwändig ihn zu gehen, aber ihn zu gehen führt berechenbar zum Erfolg. Also sauber planen, sich nicht belügen und dann abarbeiten. Je weniger vom Pfad der Tugend abgewichen wird, desto besser der Erfolg.

Aber es gibt auch andere Probleme, die wir im Rahmen der Produktentwicklung zu lösen suchen. Das sind die sogenannten komplexen Probleme. Komplexe Probleme haben die Eigenschaft, dass Ursache und Wirkung zwar beobachtet werden kann aber nicht im Vorfeld analysiert werden kann, weil die Kausalität unbekannt ist. Sie entzieht sich also der Planung. Sie können nur versuchen und beobachten und daraus lernen.

Projektmanagement ist zutiefst ein Werkzeug der Lösung komplizierter Probleme. Für komplexe Probleme eignen sich die agilen Methoden, die sich gerade in der Softwareentwicklund durchgesetzt haben. Software ist komplex. Gerade die Schnittstelle zum Menschen ist hier besonders davon betroffen, da menschliches Verhalten zu tiefst komplex ist.

Aber auch im Maschinenbau werden Produktentwicklungsprojekte immer mehr Lösung von komplexen Problemen. Gerade in Märkten, die schon länger keine Anbietermärkte mehr sind, sondern Nachfragermärkte ist gerade die Frage, ob die Kunden ein Produkt kaufen eine komplexe Sache, die am besten ausprobiert wird und die sich entsprechend der Planungssicherheit entzieht.

Je mutiger desto komplexer und desto weniger planbar

Und nicht zuletzt sind gerade die von Komplexität betroffen, die in ihren Produktenwicklungen große Schritte machen. Neue Technologien entwickeln oder erstmalig einsetzen, neue Märkte oder Nischen erobern, neue Vertriebskanäle und Supply Chains ausprobieren. Gerade diese mutigen großen Schritte sind besonders unberechenbar und vorhersagbare Ursache-Wirkungs-Beziehungen versagen.

Also gerade diejenigen, die besonders mutig vorangehen, können sich am wenigsten durch mehr Planungsoverhead den Erfolg kaufen. Die Unsicherheit lässt sich in komplexen Situationen nicht wegplanen.

Starten starten starten

Wenn einzelne Projekte unsicherer werden, dann lässt sich das Risiko doch durch mehr gleichzeitige Projekte auffangen. Frei nach dem Motto, eins wird schon durchkommen. Am grünen Tisch heißt diese Strategie nicht alle Eier im gleichen Korb haben. In der Praxis bedeutet dieses Vorgehen, dass wir die Unfähigkeit ein Projekt pünktlich abzuliefern als Begründung dafür benutzen, mehrere Projekte zu starten. Als ob dadurch, dass sich die Arbeitszeit und Aufmerksamkeit auf mehrere Projekte verteilt, gesichert wäre, dass die Projekte jetzt besser laufen.

Einstein wird das Zitat zugeschrieben: “Die Definition des Wahnsinns ist, immer dasselbe zu tun und ein anderes Ergebnis zu erwarten.”

Der Wunsch ist verbreitet, bei nicht funktionierenden Projekten wenigstens eins zu haben das funktioniert. Und wenn alle mehr oder weniger notleidend sind, dann ein neues anzufangen, bei der der Business case noch nicht mit der Realität kollidiert ist.

Schlechtestes bekommt Aufmerksamkeit

Es ist häufig auch so, dass bei mehreren Projekten genau dasjenige die gesamte Managementattention, also diese knappe Ressouce Aufmerksamkeit hat, das am schlechtesten läuft. Und damit da Ruhe einkehrt, werden dann so lange Ressourcen verschoben, bis ein anderes Projekt tiefer in der Tinte steckt.

Kennen Sie diese Geschichte von Krebsen im Eimer? Frisch gefangene Krebse im Eimer wollen wieder zurück ins Wasser und müssen dazu aus dem Eimer klettern. Diejenigen, die der Oberkante am nächsten sind, klettern auf den Rand zu und versuchen sich hochzuziehen. Die Krebse weiter unten stecken Zangen und Beine aus und ziehen die wieder zurück. Blödes Verhalten. Schlechte Motivation: Wenn ich es nicht herausschaffe, dann sollen die anderen auch nicht raus. Aber das ist nur die Wirkung, die Intention der Krebse ist ja nur auch raus zu kommen. Dabei halten sie sich an allem fest, was in Reichweite ist. Dumm, wenn das die Krebse weiter oben sind, und diese wieder heruntergezogen werden. Gut gemeint ist nicht gut gemacht. Am Ende entkommt kein Krebs.

So geht das ihren Projekten auch. Wenn eins so schlecht läuft, dass es Ressoucen von anderen abzieht, erreichen Sie am Ende damit nur, dass keines wirklich gut läuft.

Weiße Knöchel am Lenkrad

Gerade wenn mehrere Projekte betroffen sind ist dem Problem nicht über besseres Projektmanagement der einzelnen Projekte beizukommen. Das liegt erstmal nahe und man bekommt das Gefühl, etwas getan zu haben, aber hilft es?

Ein bisschen erinnert mich mehr Kontrolle und mehr Aufsicht an einen Autofahrer, der bei überfrierender Nässe unterwegs ist. Er weiß, dass er ein Problem hat. Er weiß, dass das Auto jederzeit ausbrechen kann. Er weiß, dass er etwas tun muss, um das Auto im Griff zu behalten und sicherzustellen, dass am Ende nicht er im Graben liegt. Was macht er? Er fasst das Lenkrad fester. Das ist für die Richtung des Autos zuständig und wenn er das Lenkrad nur gut festhält, dann fährt das Auto geradeaus. Die Knöchel sind schon weiß vom festen Zupacken, also bleibt das Auto auf der Straße.

Das ist völlig absurd sagen Sie. Langsam fahren hilft, zu hause bleiben hilft, hinter den Räumfahrzeugen fahren hilft, Winterreifen helfen. Aber Lenkrad festhalten? Was für ein hilfloser Versuch. Und dennoch gehen wir an Projekte in Not vielfach mit weißen Knöcheln ran und versuchen sie wieder auf Kurs zu lenken. Die Ursache, die wir uns anschauen müssten, liegt ganz woanders.

Sie wollen mehr leisten, müssen mehr leisten und fragen sich wie

Was können Sie denn tun? Ich will Projektmanagement nicht grundsätzlich die Wirksamkeit absprechen, fern davon. Eine mögliche gemeinsame Ursache, warum bei Ihnen regelmäßig Projekte notleidend werden liegt in der Ausbildung der Projektleiter und dem allgemeinen Verständnis von Projektmanagement begründet. Wer seine Projektleiter nicht unterstütz, indem er sie unterstützt, die neue Rolle auch auszufüllen, der hat sich eine Umgebung geschaffen, in der Projekte immer mal wieder schief gehen werden. Das lässt sich beheben, indem Mitarbeiter zu Projektleitern werden, die diese Rolle wollen, die verstanden haben, dass das eine andere Rolle als fachlicher Mitarbeiter ist und denen das notwendige Handwerkzeug mitgegeben wird, ihre Rolle auszufüllen. Dazu kommt noch ein Umfeld, dass diese Projektleiter unterstüttzt. Linienmanager, die ihre Rolle bei der Unterstützung der Projekte kennen.

Ein anderer Grund ist die realistische Erwartung an die Projekte. Wenn bei Ihnen Projekte geplant werden wie der Stuttgarter Bahnhof oder der Berliner Flughafen, (Erst ganz klein und wirtschaftlich und nachher sind alle an Bord) dann dürfen Sie Sich nicht wundern, wenn regelmäßig Kosten und Aufwand explodieren. Realistische Planungen sind wichtig, damit die Entscheidungen, die auf Basis der Daten gefällt werden auch richtig sind. Das kann man lernen und hier dürfen Sie nachsteuern, wenn regelmäßig die Planung an der Realiät vorbei geht.

Ein dritter Punkt, den ich gerne einbringe ist der, das Projekte häufig im luftleeren Raum geplant werden. Sie werden so geplant, als würden nur sie existieren. Es entsteht ein schöner Plan, der ist dann auch Basis für die Projektergebnisrechnung, für den business case und dann wird eine Entscheidung basierend auf ROI, Gegenwartswert oder internem Zinsfuß getroffen. Also nur aus dem Projekt heraus ohne zu berücksichtigen, ob andere Projekte die gleichen Ressourcen benötigen. Das passiert erst, wenn das Projekt verabschiedet ist und versucht wird, die verschiedenen Projekte unter einen Hut zu bekommen. Nur in dem Moment, wo ein Projekt Rücksicht auf das andere nimmt, verlängern sich die Laufzeiten und die schönen business cases sind hinfällig.

Hier dürfen Sie nachsteuern, wenn das bei Ihnen vorkommt. Wenn sie basierend auf dem business case das Projekt beschließen und die Mannschaft dann versucht, mehrere verabschiedete Projekte zu jonglieren und scheitert oder leidet.

Das Ziel der Produktentwicklung ist es nicht, alle Projekte im Plan und Budget abzuschließen. Das klingt erstmal ketzerisch, aber bleiben Sie kurz mit mir an Ball.

Das Ziel ist es den Unternehmensgewinn zu steigern.

Das Ziel ist es nicht alle Projekte im Plan und Budget abzuschließen. Das Ziel ist es den Unternehmensgewinn in der Zukunft maximal zu steigern. Es geht mal wieder ums Geld verdienen und Geld ist Potential für den Sinn der Unternehmung. Wenn wir dieses Ziel herunterbrechen und verschiedene Produktentwicklungen starten, um dieses Ziel der Gewinnsteigerung zu erreichen, dann kann man schon mal den Wald vor lauter Bäumen nicht mehr sehen und denken, dass jedes Projekt abzuliefern den Gewinn am zuverlässigsten steigert. Das könnte klappen, wenn alle Projekte leise durchlaufen. Das tun sie meist nicht.

Die Frage ist also nicht: Wie halte ich alle Projekte auf Kurs? Sondern: Wie erreiche ich den maximalen Gewinn? Es kann Sinn machen, ein Projekt bewusst zurückzustellen, damit ein anderes Projekt fertig gestellt werden kann, das Produkt an den Kunden ausgeliefert werden kann und wir wieder Geld verdienen.

Die beste Leistung besteht nicht darin, alle Projekte gleich schlecht zu managen, sondern bewusst Prioritäten zu setzen und einzelne Projekte vor anderen abzuschließen.

Systemperformance statt Einzelperformance

Warum ist das so? Warum leistet das System Produktentwicklung eines Unternehmens mehr, wenn wir nicht nur die einzelnen Projekte managen, sondern ganz bewusst die Abhängigkeiten und Verknüpfungen managen?

Ein Produktentwicklungsprojekt schafft Werte wenn es fertig gestellt wird. Produkt entwickelt, Fertigung angelaufen und wir verkaufen das Produkt an Kunden. Ob die Konstruktion besonders schnell war, oder der Einkauf sich super Mühe gegeben hat ist egal wenn sich das nicht auf das gesamte Projekt auswirkt. Nur die Gesamtleistung zählt. Wie beim Fussball, da werden auch nicht die individuellen Schüsse auf das Tor gezählt. Es zählt nur der abgeschlossene Angriff. Ball im Tor. Egal von wem und wie. Es werden keine halben Tore gezählt.

Ein Produkt verdient nur Geld, wenn es entwickelt, eingeführt und verkauft wird. Vorher nicht.

Und das ist auch das gefährliche in der Produktentwicklung. Wir fühlen uns wohl in unseren Rollen als Konstrukteur, Versuchsingenieur, Einkäufer, Logistiker, Vertriebler. Aber Geld verdienen können wir nur zusammen.

In der Fabrik ist das Material sichtbar

Die Fabrik hat es etwas einfacher. Jeder sieht es, wenn eine Maschine nicht weiter kommt und rumsteht. Eine Maschine, die nicht weitergebaut wird und rumsteht fällt auf.

Wenn ein Teil fehlt, kann nicht weiter gebaut werden, wer nicht weiter baut, wird nicht fertig. Eine nicht fertig gestellte Maschine wird nicht abgenommen, eine Maschine, die nicht abgenommen ist wird nicht versand und wird kein Umsatz. Jeder weiß das, jeder sieht die Maschine, die rumsteht und jeder wird vervös. Das Problem, die Maschine, die nicht weitergebaut wird ist sichtbar.

Wissensarbeit sichtbar machen

Das ist in der Entwicklung anders. Wissensarbeit ist nicht sichtbar. Es sind Bits und Bytes im Rechner. Die Arbeit ist unsichtbar, die Probleme sind unsichtbar und keiner wird nervös. Sie dürfen die Arbeit sichtbar machen. Sichtbar machen heißt managebar machen. Managen heißt Probleme auch mal preemptiv zu lösen.

Aber dazu muss das Problem sichtbar werden. Stellen Sie Sich dochmal folgende Situation vor: Ein Konstrukteur hat ein Problem mit einem Teil. Ihm fehlen Informationen. Er fragt nach und steckt fest. Also fängt er das nächste Teil an. Er ist wieder beschäftigt und hat etwas sinnvolles zu tun. Die Rückfrage ist nicht so dringend, er arbeitet ja produktiv.

Jetzt frage ich Sie als Manager. Ist das ein Problem oder ist das keins? Wollen Sie so etwas wissen oder ist das egal? Kein Problem, es arbeiten ja alle und Ingenieure, die ausgelastet sind, sind gut.

Stellen sie sich vor, das kommt häufiger vor. Jeder Konstrukteur hat das mehrmals erlebt und Konstruktionen geschoben, weil Informationen gefehlt haben oder andere Schwierigkeiten aufgekommen sind. Und keiner hat das als Problem angesehe, weil ja alle sich mit anderen Dingen beschäftigen konnten. Bei der Auzählung der fertigen Konstruktionen kommen wir voran, jede Woche werden Teile als fertig gemeldet. Immer noch kein Problem?

Jetzt kommen wir an das Ende des Projektes. Nur ein kleiner Teil von Teilen muss noch konstruiert werden. Leider sind das genau die Teile, bei denen irgendwelche Probleme aufgetaucht sind. Die deswegen liegen geblieben sind, weil es nicht voran ging. Jetzt wird im Projekt 95% fertig gemeldet und nicht ein einziges der Problemteile ist fertig. Geschweige denn durch die anderen Abteilugen. Können Sie Sich vorstellen, was das mit dem Projektplan macht? Immer noch kein Problem?

Doch wenn Ihre Kultur jetzt einen Schulidgen sucht, dürfen Sie noch etwas nachsteuern. Aber die Frage, die mich interessiert ist: Wann hätte man das erkennen könnnen? Wann hätte man das erkennen müssen, um noch Zeit zum gegensteuern, zum managen zu haben? Nur sichtbare Probleme sind mangbar. Wenn alle beschäftigt sind, heißt das nicht, dass das Projekt noch auf Kurs ist.

Prozess als Prozess managen

Die Kette: Funktionsklärung, Konstruktion, Beschaffung, Qualitätssicherung, Versuch, Montage, Auslieferung wird in jedem Produktentwicklungsprojekt dutzende oder hunderte Male durchlaufen. Und deswegen dürfen Sie diesen Prozess auch als Prozess managen. Mit allen damit verbundenen Vorteilen.

Wenn dieser Prozess bewusst gestaltet wird, dann führt das dazu, dass diese Kette, die über mehrere Abteilungen des Hauses gehen vernünftig zusammenarbeiten. Klar ist aber auch, dass das je nach Härte der Silostruktur ein ganz schönes Umdenken in der Organisation auslösen kann. Raus aus dem Silo, raus aus der Fachidiotie, hin zu einem Miteinander für den Kunden.

System performance

Wenn Sie diese Prozesskette durch die Brille der Prozessmanagementwerkzeuge sehen, dann fällt Ihnen auf, wie wenig die individuelle Leistung relevant ist für die Gesamtperformance. Klar, ein Bereich, der seine Entchen gar nicht hintereinander hat kann alles lahmlegen. Das war aber vorher schon so. Nur jetzt sehen wir das als Problem des Prozesses und können darauf reagieren. Können das managen und verbessern.

Aber was passiert mit einer motivierten Abteilung, die besonders tolle Arbeit macht? Nun auch bei der wird sichtbar, wie sehr dieses individuelle Heldentum nicht zu verbessertem Output beiträgt. Denn sie sind Teil eines Prozesses und wie eine Kette nur so stark ist, wie ihr schwächstes Glied, so wird der Prozess bestimmt durch seinen langsamsten Prozess. Vor diesem stauen sich die Arbeitspakete dahinter drehen die Mitarbeiter teilweise Däumchen. Das ist gut, denn jetzt wird sichtbar woran es hängt. Nicht, und das kann man gar nicht häufig genug wiederholen, um Schuldige zu finden, sondern um sichtbar zu machen, wer Hilfe braucht, wo Sie anfassen dürfen, damit alle Ihre Arbeit machen können und der Prozess fortschreitet.

System ist mehr als die Summe der Teile

In diesem Sinne ist der Prozess auch ein typisches System. Das heißt, es ist mehr als die Summe seiner Teile und die Teile profitieren davon, dass sie nicht individuell sondern als Teil des Systems gemanaged werden.

Da der Prozess nur am Flaschenhals beschleunigt werden kann, macht es keinen Unterschied, wenn in den anderen Prozessschritten Verbesserungen umgesetzt werden. Ausnahme: Diese Verbesserung wirkt sich auf den Flaschenhals aus. Klar, Sie können Kostensenkungen an einzelnen Stationen des Prozesses erreichen, auch wenn diese nicht der Flaschenhals sind, aber Durchsatzsteigerungen bekommen Sie nur am Flaschenhals hin.

Also, was heißt es, den Prozess als System zu managen? Nun, Durchsatzverbesserungen erreichen Sie nur am Flaschenhals. Wenn der Leiter einer anderen Abteilung nicht zufrieden mit dem Durchsatz ist, kann er mit Kapazitätssteigerungen in seinem Bereich nichts erreichen. Er wird nicht mehr schaffen, weil durch den Prozess als Ganzes nicht mehr durchgeht als der Flaschenhals durchlässt.

Die Optionen sind halt nur die, die sich auch auf den Flaschenhals auswirken. Er kann, wenn er nach dem Flaschenhals sitzt, Arbeitspakete etwas unreifer übernehmen und einen Teil der Arbeit damit vom Flaschenhals zu sich verlagern. Zum Beispiel kann die Anlage der Teile im ERP-System von der Konstruktion auf den Einkauf verlagert werden. Viele der Tätigkeiten benötigen den Konstrukteur, der sich jetzt darauf konzentrieren kann, die Komponenten nur im Konstruktionssystem zu pflegen. Der Abteilungsleiter kann, wenn er vor dem Flaschenhals sitzt, Arbeit zu sich verlagern, in dem Arbeitsschritte, die sonst am Flaschenhals gemacht werden würden jetzt stromauf gemacht werden.

Und, und das sieht man eigentlich viel zu selten: Natürlich kann auch Personal ausgeliehen werden. Wir können natürlich immer Personal von einer Funktion zu einer anderen schieben. Wenn man eine Organisation mit ihrer Hierarchie betrachtet, dann ist das nicht so offensichtlich, und wird deswegen auch erschreckend wenig gemacht, aber wenn Sie anfangen, den Prozess zu betrachten und auch als Prozess zu managen, dann springen solche Ansätze ins Auge.

Nur ein abgeschlossener Prozess schafft Werte

Es ist banal, aber nur ein abgeschlossener Prozess schafft Werte. Alle Zwischenschritte sind nur Aufwand. Kosten. Erst mit Abschluss des Prozesses bis zum Kunden und Geldeingang, sind die Werte final geschaffen, als dazwischen sind nur Rechengrößen, sollten aber nicht mit realisisertem Gewinn verwechselt werden.

Und auch das wird bei einer Prozess betrachtung sichtbar. In der Silodenke können Abteilungen verführt werden, zu denken, Sie hätten einen Wert geschafft, weil ihr Arbeitsschritt fertig ist. Nur, wenn das Teil dann vor dem Flaschenhals auf einem großen Stapel Teile liegt, dann ist in Summe das Projekt nicht vorangekommen. Dieser Blick auf das Fertig machen ist eines der großen Geschenke, die Sie erhalten, wenn Sie Sich an die Prozesssicht gewöhnen.

Reihenfolge

Und es hilft auch, bei dem Verständnis, dass es besser ist, ein Entwicklungsprojekt fertig zu machen, bevor Sie ein neuer angehen. Natürlich können Sie mehrer Projekte gleichzeitig bearbeiten, aber nicht an der gleichen Stelle. Es ist kein Problem, Ein Projekt in der Anforderungsklärung zu haben, eins im Systemdesign, eins in der Konstrutkion, eins in der Beschaffung, eins im Versuch, eins im Produktionsanlauf. Solange die Projekte sich nicht auf den Füßen stehen, ist alles gut, aber drei Projekte in der Konstruktion sorgt einfach nur dafür, dass die Kapa gedrittelt wird und alle Projekte langsamer bearbeitet werden und länger dauern als notwendig wäre.

Aber auch da hilft es von der Planung der Projekte als unabhängige Aktivitäten hin zu einer Projektsicht, die alle Projekte in Form der zugehörigen Arbeitspakete sieht.

PEP, Projekt Und Prozess

In dieser Episode ging es nicht um den PEP, den Produtkentwicklungsprozess, der beschreibt, welche Stufen ein Produktentwicklungsprojekt durchlaufen muss, sondern um die Prozesse, auf die sich die Projekt abstützen. Hier im Beispiel der Prozess von der Konstruktion bis zum freigegebenen Teil. Dieser Prozess wird für jedes Projekt dutzende bis hinderte Male durchlaufen und für das ganze Portfolio der Entwicklungsprojekte schnell auch mal tausend Mal im Jahr.

Dieser Prozess entscheidet über die Effizienz Ihrer Produktentwicklung, weil die einfache Frage, wie viele neue Teile Sie pro Monat erzeugt bekommen bestimmend ist für die Frage, wie viel Sie entwickeln können. Der andere Hebel, der der Effektivität ist die Frage, was Sie entwickeln. Unterschiedliche Projekte haben unterschiedliche Beiträge zu Ihrem Unternehmensgewinn und die richtigen Produkte auszuwählen hilft aus der begrenzten Kapazität das meiste herauszuholen. Wer sich dafür interessiert kann nochmal in die Folgen zu Priorisierung und COD3 reinhören.

Vorgehen

Was können Sie konkret also tun? Sie haben verstanden, dass Sie den unterliegenden Prozess bewusst gestalten dürfen und fragen Sich jetzt: Wie?

Der Erste Schritt ist die Anerkenntnis, dass hier ein Projekt existiert, der davon profitiert als Prozess über mehrere Abteilungen wahrgenommen zu werden und geführt zu werden. Dazu müssen Sie die unterschiedlichen Abteilungen ins Boot holen. Sie dürfen mit den Kollegen eine gemeinsame Prozessdarstellung machen und herausarbeiten, wer was wenn macht.

Wenn Sie den Konsenz darüber haben, dann dürfen Sie Sich die Werkzeuge bereitlegen, den Prozess zu managen. Gerade für Wissensarbeit ist es wertvoll, die Arbeitspakete sichtbar und anfassbar zu machen. Also ein Abstraktes Arbeitspaket darzustellen. Meine persönliche Präferenz sind hier Whiteboards in Form von Kanban Boards, da mit diesen ein gut dokumentierter gemeinsamer Wissenstand erreicht werden kann.

Manche bevorzugen elektronische Tools, ich mag das Board, weil ich es für sinnvoll halte, die abstakten Arbeitspakete dinglich als Karten zu visualisieren und nicht eine Abstraktum durch ein anderes Abstraktum zu ersetzen.

Auf dieser Visualisierung, die stets die Gegenwart darstellt und schon viel hilft, lassen sich Visualisierungen aufbauen, die helfen die Vergangenheit darzustellen und dadurch die Zukunft besser zu verstehen. Cumulative Flow Diagramme sind für mich da im Zentrum, aber es gibt noch ein paar andere Darstellungen. Die Cumulative Flow Diagramme kompaktieren die Prozesssicht so gut, dass sie sich auch eignen, ein paar Hierarchieebenen höher in enger Frequenz wahrgenommen zu werden. Sie müssen lediglich erklärt werden. Wenn Sie also Geschäftsführer eines Mittelständlers sind oder Entwicklungsleiter in einer großen Entwicklung, dann können Sie mit den CFD jeden Tag mittels Blickdiagnose erfassen, wie der Prozess tickt und werden nicht mehr überrachst.

Kombinieren Sie die Effizienz eines Prozesses mit der Innovationsfähigkeit eines Projektes

Mit den CFD lassen sich Aussagen über die Prozessperformance in der Zukunft machen, die sehr gute Vorhersagekraft haben. Sie sind sehr gut geeignet, um Termine in die Projektplanung der individuellen Projekte zurückzumelden. Nutzen Sie dies, um die Projektleiter von der Fleißarbeit der Verfolgung von vielen kleinen Teilen zu entlasten und gleichzeitig verlässlichere Projektplänge zu erreichen.

Dabei bleiben viele Aktivitäten natürlich im Projektmanagement. Das wesen eines Produktentwicklungsprojektes ist ja das Betreten von Neuland, dafür sind ja die Projektmanagementwerkzeuge da. Aber die Fleißarbeit unten im Maschinenraum, die überlassen Sie doch eher der gut geschmierten Abläufe eines Prozesses.

Multiprojektmanagement

Für mich ist das ein wesentlicher Teil von Multiprojektmanagement. Derjenige, der mit der Abarbeitungsgeschwindigkeit der Arbeitspakete zu tun hat. Ich werde an anderer Stelle noch über andere Aspekte sprechen, aber hier haben Sie den großen Hebel in der Hand, um viele der Ressourcenkonflikte und Planungsaufwendungen, die damit zusammenhängen zu erschlagen.