Podcast: Play in new window | Download

Subscribe: Apple Podcasts | RSS

Heute habe ich wieder Maik Pfingsten im Interview. Bereits in Podcastfolge 82 hatte ich mich mit ihm über das Trouble Shooting bei größeren Projekten unterhalten. Heute geht es um Projektmanagement und das für viele häufig leidige Thema Lastenhefte.

Maik Pfingsten

Maik Pfingsten

Maik ist Speaker, Podcaster und Mentor mit dem Schwerpunkt Systems Engineering. Er hat über 13 Jahre Erfahrung als Systemingenieur und Troubleshooter besonders in der Automobilentwicklung.

Im Bereich Systems Engineering und TroubleShooting hat er sich zu einem inspirierenden Vordenker entwickelt. Unternehmen, die seine Betrachtungsweisen nutzen, sind u.a. Zeiss, Fresenius Medical Care, HILTI, Valeo, Daimler, T-Systems und viele mittelständische Technologieunternehmen.

Ich unterhalte mich heute mit ihm über das Thema Lastenhefte. Was genau ist das eigentlich und worauf sollte man da achten?

Erfolgreich Lastenhefte schreiben

Wenn Sie sich näher mit Lastenheften beschäftigen wollen: Für sein Buch klicken Sie einfach hier:

„Erfolgreich Lastenhefte schreiben: Eine Schritt-für-Schritt-Anleitung aus der Praxis eines Troubleshooters“

Das Buch ist dann für Sie geeignet,  wenn Sie auf einer der folgenden Fragen mit Ja antworten:

• Sie möchten Ihr Lastenheft verbessern, wissen aber nicht, wo Sie beginnen sollen?
• Sie haben in Ihrem Entwicklungsprojekt festgestellt, dass Ihr Lastenheft problematisch ist und Sie daran noch arbeiten müssen?
• Sie haben versucht, Ihr Projekt ohne Lastenheft voranzubringen, allerdings ohne Erfolg?

Genau für solche Situationen finden Sie in Maik’s Buch eine Schritt-für-Schritt-Anleitung und Herangehensweise.

Personal Kanban

Im letzten Leadership-Barcamp ist Maik auch auf das Kanban Konzept eingegangen.

Kanban kommt eigentlich aus der Produktion, aber man kann es auch sehr effektiv bei Projekten wie auch beim Selbstmanagement einsetzen.

Eine spannende Herangehensweise und wie immer bei Maik: Aus der Praxis für die Praxis!

Im Interview empfiehlt Maik das Buch „Personal Kanban„. Hier der Link:

Personal Kanban: Visualisierung und Planung von Aufgaben, Projekten und Terminen mit dem Kanban-Board

Das Leadership-Barcamp

Mit Ivan Blatter und Maik Pfingsten veranstalte ich am 11. und 12. November 2016 das dritte Leadership-Barcamp.

Maik Pfingsten auf dem 2. Leadership-Barcamp in Aktion!

Da freue ich mich schon sehr drauf, weil die zwei bisherigen Leadership-Barcamps hervorragend aufgenommen wurden. Die Teilnehmer wie auch Ivan, Maik und ich waren begeistert von der Intensität, der Offenheit und der Qualität des Austauschs der Teilnehmer untereinander.

Bloggerkollege und Teilnehmer des Leadership-Barcamps Torsten Pretzsch hat es so formuliert:

„Man hat gemerkt, wie in den Sessions die Energie geflimmert hat und wie die Teilnehmer engagiert bei der Sache waren.“

Teilnehmer Stephan Kreuzberg hat es folgendermaßen auf den Punkt gebracht:

„Ich habe schon viele andere Konferenzen besucht, aber noch nie eine solche angenehme Gesprächskultur und so viel Interaktion zwischen den Teilnehmern erlebt und frische Ideen erhalten.“

Wenn Sie am 3. Leadership-Barcamp Interesse haben, schauen Sie einfach mal vorbei. Einfach hier klicken: Leadership-Barcamp.

Es gibt momentan noch Frühbucher Tickets! Deswegen schauen Sie direkt mal nach. Ich verspreche Ihnen, die Teilnahme lohnt sich!

Das inspirierende Zitat

gefunden auf der Webseite der Uni Würzburg:
für Quelle bitte hier klicken!

„Sag mir, wie ein Projekt beginnt und ich sage Dir, wie es endet.“

Diese These bestätigen die berühmten Worte des Baumeisters des Turms von Pisa zum Projektstart: „Wird schon schief gehen!“

unbekannt

Weiterführende Links:

• Das 3. Leadership-Barcamp
• Webseite von Maik Pfingsten
• Maik’s Online-Bibliothek: Erfolgreich Lastenhefte erstellen
• Erfolgreich Lastenhefte schreiben
• Wie detailliert sollte ein Lastenheft sein?
• Personal Kanban – Wie ich heute effektiver bin!
• Troubleshooting im Projektmanagement – Interview mit Maik Pfingsten
• Maik’s Podcasts:
  1. Lifestyle Entrepreneur
  2. Systems Engineering Leadership
  3. Der TroubleShooter
• Zeit fürs Wesentliche gewinnen.

Das transkribierte Interview mit Maik Pfingsten

Geropp:

Maik, warum laufen eigentlich so viele Projekte schief? Woran liegt das denn, deiner Meinung nach, dass so ein Projekt häufig weder vom zeitlichen, noch vom Budget-Rahmen eingehalten wird.

Pfingsten:

Ich vergleiche das immer mit einem schönen Bild, Bernd. Und zwar, ich erlebe das oder habe es auch vor allem als aktiver Trouble-Shooter immer häufig erlebt: Du hast die Situation: Da wird ein Bagger bestellt. Dann wird eine große Grube ausgehoben. Dann werden irgendwie Tonnen von Ziegelsteine in diese Grube reingeschoben. Anschließend werden 20 Ingenieure drum rum gestellt und dann kriegen die den Auftrag, baut ein Haus. Und hinterher wundern sich alle, dass die Garage in der ersten Etage ist und der Schornstein so an der Seite rausguckt und so weiter.

Das ist häufig die Situation, wo wir in unserem professionellen Umfeld mit dieser Frage umgehen oder mit Projekten umgehen und es wundert mich immer so sehr, wenn wir das Ganze privat machen, sprich wir würden jetzt 500.000 Euro in unser neues Häuschen anlegen.

Da würde keiner auf die Idee kommen, so vorzugehen, sondern da wäre uns völlig klar, wir gehen erst zum Fachmann, in dem Fall ein Architekt. Der klärt mit uns die Anforderungen. Der klärt mit uns die Wünsche. Der dokumentiert das und packt das in einen Bauantrag. Und ein Teil dieses Bauantrags sind eben die Lasten, also das, was wir als Ingenieure im Systemkontext eben Lastenheft nennen.

Geropp:

Ja. Okay. Das verstehe ich. Aber das heißt, es geht um ein Lastenheft. Jetzt gibt es häufig den Punkt, dass gesagt wird, ja es gibt auch noch ein Pflichtenheft. Vielleicht kannst du da mal ein bisschen den Unterschied zwischen beidem sagen.

Pfingsten:

Also wir müssen unterscheiden zwischen einem Lastenheft und einem Pflichtenheft. Beides sind wichtige Dokumente, wenn es, gerade in Projekten und im Projektmanagement, darum geht erfolgreich zu sein. Beide haben aber einen unterschiedlichen Ziel und Zweck.

Das Lastenheft ist im Grunde die Dokumentation der Wünsche und der Anforderungen der Kunden oder Schrägstrich Auftraggeber, die sagen, was sie gerne hätten. Was gerne das wäre, was am Ende so rauskommen soll. Welches Problem sollte gelöst werden mit dem, was da geschaffen wird. Das heißt, typischerweise gibt es zwei verschiedene Szenarien, was Lasten angeht und Lastenhefte.

Entweder bist du halt ein Zulieferer, Maschinenbau. Ja. Hast einen Hersteller, deinen Kunden, der sollte dir ein Lastenheft geben, wo er sagt, ich hätte gerne – ne so groß, so breit, so schwer, diese Farbe und what ever.

Das ist so die eine typische B2B-Situation. Es gibt noch eine zweite. Und da begleite ich viele Kunden, gerade so Firmen, wie Hilti und Zeiss. Die haben die Situation. Die haben keinen Kunden.

Das ist nicht irgendein Bauarbeiter, eine Baustelle und schreibt dem Hilti jetzt sein Lastenheft für den nächsten Akku-Schrauber. Das heißt, die haben in der Regel ein Marketing, ein Produktmanagement, was versucht bestmöglich diesen Kunden abzubilden und seine Wünsche zu verstehen.

Das heißt, das Lastenheft ist ein Dokument, ein Artefakt, eine Spezifikation, die auf der Seite des Kunden liegt, wo auch die Verantwortung für liegt und quasi, wie beim Hausbau, eingangs in dem Beispiel, dokumentiert, was du dir wünscht. Das heißt noch lange nicht, dass du alles kriegst. Das ist nämlich der wichtige Teil.

Und jetzt kommen wir zum Pflichtenheft. Ein Pflichtenheft ist die Antwort des Projektes auf die Lasten. Also das heißt, ich kriege ein Lastenheft, in der Hoffnung, dass es mit Sinn und Verstand gemacht worden ist. Auch das ist eine Kunst für sich.

Habe ich die Situation, dass ich eben sage, okay, das mache ich. Okay, das mache ich, mache ich aber ein bisschen anders. Und das. Und das. Und das lehne ich ab. Ja, das ist das absolute Recht, was ein Projekt hat, ja auch so ein Lastenheft zu reagieren und antwortet mit einem Pflichtenheft.

Wir sind sogar in Deutschland an einem Punkt, dass wir das Ganze natürlich auch standardisiert haben. Es gibt dazu entsprechende DIN-Normen, die ganz klar definieren, was ist ein Lastenheft, was ist ein Pflichtenheft und es gibt noch einen ganz wichtigen, wesentlichen, weiteren Aspekt gerade wenn ich so im technischen Umfeld unterwegs bin im Mittelstand.

Wir sind es gewohnt mit Kunden, ja Verträge zu machen. Was weiß ich – da ist ein großer Maschinenbau-Konzern, ich erfinde jetzt mal was, was weiß ich, Druckmaschinen baut und der braucht für seine Druckmaschine eine Teilkomponente.

Aber was an sich schon wieder ein komplexes System ist, was mit einem 40-Tonner irgendwo vom Werkshof gefahren wird. Das heißt, in der Vorprojektphase sind diese beiden Firmen am Tisch, wo der Einkäufer und der Vertriebler zusammensitzen und alles klären, Geld, Zeit und alle Sachen. Das ist der kaufmännische Teil.

Wir haben aber noch einen technischen Teil und das sind eben diese Sachen Lasten und Pflichten. Also wirklich, was wünscht sich der Kunde und wie antwortet ein Projekt darauf. Und sie sind ein wesentlicher Bestandteil häufig auch von vertraglichen Zusammenarbeitsverhältnissen zwischen verschiedenen Unternehmen.

Geropp:

Das heißt, wenn ich dich richtig verstehe, auf dem Pflichtenheft basiert eigentlich dann nachher das, wo ich mich zu verpflichte als der Lieferant und sage, ich habe das Lastenheft gelesen. Das ist, was ich dir anbieten kann.

Pfingsten:

Genau.

Geropp:

Okay.

Pfingsten:

Das wird selten gemacht, ist aber der genau auf dem Punkt der Aspekt.

Geropp:

Das wäre für mich die Frage. Das wird selten gemacht, weil dein Buch heißt ja auch Lastenhefte, das heißt ja nicht Pflichtenhefte. Das heißt, im Rahmen eines Projektes bezieht man sich dann doch wieder auf die Lasten, auf das Lastenheft oder die Lastenhefte. Woran liegt das, dass das so häufig falsch läuft mit diesen Lastenheften?

Pfingsten:

Also die Schwierigkeit an sich ist ja, die Lastenhefte liegen, wie ich eben sagte, in der Verantwortung des Kunden Schrägstrich, derjenige, der den Kunden abbildet oder Auftraggeber ist.

Und gerade Unternehmen, die diese Situation haben, wie beispielsweise Hilti und Zeiss, die ich eben gerade so ein bisschen angerissen habe, die jetzt keine direkten eins zu eins Kunden haben.

Wo jetzt ein Daimler zum Bosch geht und sagt, ich will da eine Einparkhilfe. Dann sagt der Bosch, alles klar, lieber Daimler, gib mir ein Lastenheft. Da ist es eindeutig. Aber es gibt viele, viele Firmen, gerade in unserem doch sehr mittelständisch geprägten Kontext, die haben in dem Sinne keinen Kunden, den sie jetzt direkt sagen, schreib mir bitte mal ein Lastenheft und dann ist es Aufgabe des Marketings, des Produktmanagements so ein Lastenheft zu schreiben.

Aber das sind Leute, die haben ganz andere Ausrichtungen. Die haben weder Zeit, noch Lust, noch Laune ein Lastenheft zu schreiben und dann kommen Projekte einfach in Schwierigkeiten, weil sie brauchen eigentlich ein Lastenheft, um sauber zu definieren, was sie hinterher umsetzen sollen.

Geropp:

Also wenn ich dich richtig verstehe, sind das ja eigentlich fast alle internen Projekte auch in normalen Firmen, mittelständische oder größere Firmen, wo gesagt hat, ja wir brauchen da dies oder jenes und das muss jetzt in der und der Abteilung umgesetzt werden, da müsste basieren auf dem Lastenheft. Da hat man nicht Lasten-Pflichten-Hefte, sondern nur das Lastenheft.

Pfingsten:

Genau. Jetzt kommen wir gerade in diesen Konstellationen an einen sehr smarten Punkt und zwar, wie ich schon sagte, die Leute, die eigentlich die Verantwortung für das Lastenheft tragen, haben weder die Lust, noch die Zeit, noch die Ahnung so was zu schreiben.

Alle Beteiligten in diesem Spiel wissen, ja eigentlich wäre es schon schön, aber ich glaube Lastenheft ist das am wenigsten erotischste, was du dir vorstellen kannst in so einem Projekt. Keiner hat Bock da drauf, aber alle wissen, sie brauchen es.

Im Grunde mit dem Buch habe ich jetzt einfach mal mein Vorgehen beschrieben, wie ich Lastenheft erstellt habe als Trouble-Shooter, weil das ist ein wesentlicher Teil, wenn ich in so ein Projekt hereingesprungen bin.

Wir hatten das ja in der vorherigen Episode, wo ich mal hier bei dir im Gespräch war. Brauchte ich am Anfang irgendwie eine verlässliche Basis, um darauf basierend die Strategie aufzubauen und durchzubringen, wie wir in sechs Monaten eben erfolgreich wieder mit dem Projekt auf dem Gleis sind.

Und dieses Handwerkszeug ein Lastenheft zu schreiben, ist nicht kompliziert. Ich muss das im Grunde, wie ein Kochrezept wissen und kann auf dieser Basis vorgehen. Und jetzt kommt der Bogen zu dem Punkt, zum Beispiel interne Projekte.

Ich empfehle da häufig zu sagen, weißt du was, liebes Marketing, liebes Produktmanagement, wir wissen ja, ihr habt da keine Lust, keine Zeit, keine Ahnung und wir brauchen eigentlich als Projekt so was, ja. Warum denn nicht hingehen und mit Sinn und Verstand als Serviceleistung des Projektes, ja der Entwicklungsabteilung, wer auch oder IT-Abteilung, wer auch immer jetzt das Projekt dann hinterher umsetzt, für das Marketing, für den Auftraggeber, fürs Produktmanagement zu sagen, wir schreiben dir das Lastenheft.

Die Verantwortung bleibt bitte schön immer noch bei dir, aber wir wissen, wie man solche Dokumente schreibt, ja und dann machen wir das für dich. Hat den großen Vorteil, du hast als Projekt von vornherein die Hand drauf, dass da nicht der totale Quatsch drin steht, kannst du es schon mal so schreiben, da gibt es ein bisschen mehr als nur einfach zwei, drei Sätze, ja.

Da gibt es ein bisschen Spielregeln, wie man so was macht. Requirements Engineering, ich will da gar nicht zu tief eintauchen, aber dann kann ich von vornherein die Hand drauf halten und das auch nach allen Regeln der Kunst ein Lastenheft sauber mit Sinn und Verstand entsteht. Jetzt weder da so eine zwei Seiten Geschichte, wo keiner was mit anfangen kann, noch so ein Palletten-Ding, ja, wo man drei bis sechs Monate mit zugange ist, überhaupt mal sich durchzulesen und am Ende ist ja vielleicht nur ein Drittel davon relevant.

Und das führt dazu, dass ich dann als Projekt das Ding herziehen kann und sagen kann, ich nehme den allergrößten, ich übernehme den allergrößten Teil in mein Pflichtenheft. Es ist ja eh schon sauber für mich okay gewesen und den Rest lehne ich dann vielleicht ab oder sage, das machen wir vielleicht später.

Geropp:

Was würdest du denn sagen, sind so die Hauptpunkte, wenn man ein Lastenheft erstellt? Was sind so die Sachen, wo man am meisten drauf achten musste? Wo du auch am meisten siehst, da wird am meisten Mist gebaut, wenn so ein Lastenheft erstellt wird?

Pfingsten:

Also ich sag mal der erste und wesentlichste und wichtigste Punkt überhaupt, ist sich klar zu machen, für wen wird denn das System entwickelt? Für wen? Wer ist denn der Benutzer des Ergebnisses, was überbleibt, wenn das Projekt abgeschlossen ist.

Also ist jetzt völlig egal, ob du sagst, ich baue jetzt irgendwie, was weiß ich, so ein Teilsystem für eine Druckmaschine für unseren Kunden oder es ist ein internes IT-Verbesserungsprojekt. Projekte sind ja zeitlich begrenzte Tätigkeiten, ja.

Es sind klares Start und klares Ende und wenn dann quasi das Projekt abgeschlossen ist, bleibt ja, ist das Ziel ja, dass ein Ergebnis da ist, egal, ob es jetzt in Stahl ist oder ob es jetzt irgendwie organisatorisch oder IT-strukturell ist oder what ever. Es hat ja einen Zweck. Das bedeutet, es gibt einen Benutzer dieses Ergebnisses. Und es gibt jemanden, und dieses, was auch immer das Ergebnis ist, ich nenne es jetzt mal das System, erfüllt einen Zweck für den Benutzer, weil sonst bräuchten wir das ja nicht. Das ist wichtig sich klar zu machen.

Ein konkretes Beispiel jetzt mal aus der Automobilbranche. Da gibt es einen Zulieferer, der eine Einparkhilfe als System anbietet und es gibt einen Hersteller, der die einbaut. Und diese Konstellation ist es natürlich für den Zulieferer eigentlich so, der Kunde ist dann der Daimler, VW, BMW, wer auch immer, ne. Die sind aber nicht der Benutzer.

Der Benutzer dieser Einparkhilfe ist meine Mutter, die mit 70 plus in Dortmund in einer Tiefgarage rumrangiert und sich sicherer fühlt damit, dass jetzt so ein System ihr hilft jetzt nicht irgendwie anzuecken mit dem Auto. Und dann kommen wir nämlich an den nächsten Punkt. Dann klären wir diesen Nutzenversprechen von diesem System und damit können wir viel, viel einfacher entscheiden, was in ein Lastenheft reingehört und was nicht. Sonst wird oft aus Angst alles reingeschrieben.

Geropp:

Ja. Okay. Jetzt hast du ja viel Erfahrung mit größeren Projekten, gerade die so aus dem Ruder gelaufen sind. Wir hatten das ja auch schon in der Podcast-Folge 82 besprochen. Wenn so ein Projekt droht so richtig aus dem Ruder zu laufen, was empfiehlst du den Verantwortlichen dann zu tun?

Pfingsten:

Also das aller erste und wichtige ist, sich, glaube ich, wirklich bewusst zu machen, wie steht es denn um mein Projekt. Oder ich sage mal, bin ich schon im Trouble-Shooting oder nicht?

Projekte haben mit Sicherheit auch mal intensive Phasen, wo es auch mal hoch hergeht, aber auch Phasen, wo es auch mal alles relativ smart läuft.

Es gibt aber durchaus Indikatoren, nenne ich es ganz bewusst, die so ein bisschen wie so ein Fieberthermometer sagen, okay, es könnte sein, dass dieses Projekt gekippt ist und das ist wichtig sich das bewusst zu machen. Ich nenne das die 50 Prozent Regel. Es ist einfach eine Daumenregel. Dicke Daumenregel:

Mein Budget ist um die Hälfte gekürzt worden, meine Mannschaft ist um die Hälfte gekürzt worden oder die Anforderungen sind verdoppelt worden. Das sind immer so die drei Indikatoren, die für mich klar machen, da läuft was komplett schief und ich glaube, dieses sich bewusst zu machen, ist der allererste Schritt und dann eben als zweiten Schritt zu gucken, ist mir klar, was meine Lasten sind, was am Ende rauskommen soll? Was davon können wir überhaupt noch umsetzen und eine klare Strategie aufbauen.

Geropp:

Wenn es wirklich so hart auf hart geht, wann ist es da sinnvoll sich von außen Hilfe zu nehmen?

Pfingsten:

Es gibt mehrere, verschiedene Rollen, die in diesem Kontext Unterstützung bieten könnten. Das eine ist natürlich das, was ich selber früher operativ auch gemacht habe, ist der Trouble-Shooter. Das heißt, ich gehe als externe Führungskraft, Management-Funktionen, Projektmanagement-Funktion in diese Projekte rein und ziehe diesen Karren gemeinsam mit dem Team aus dem Dreck, weil neben den rein fachlich, sachlich, methodischen Sachen, kommt da natürlich auch noch viel Führung und Softskill-Themen dazu. Ja und diese Leute, die aktiv Trouble-Shooting über Jahre machen, haben da eben halt das ganze Handwerkszeug, um das umzusetzen.

Es gibt einen zweiten Punkt, warum das durchaus Sinn macht, solche operativen Externen dazu zu holen – Spezialisten. Die stecken nicht in dem politischen Machtkampf drin. Mir als Projektleiter war das ziemlich egal, was für Machtkämpfe gelaufen sind.

Ich habe eine Situation mal gehabt, erinnere ich mich noch sehr lebhaft dran, bei einem großen Automobil-Hersteller. Wir hatten Status-Meeting. Da war ein Hauptabteilungsleiter, der ist aber so was von unter der Gürtellinie mit allen Leuten da umgesprungen, den habe ich mir in der Mittagspause auf dem Flur an die Seite gezogen und habe gesagt,

„Herr Dr. Müller, Meier, Schmitz, sorry, ich, ich sag es jetzt mal so radikal, rette Ihnen hier Ihren Arsch, dass Sie Ihre Karriere machen können, wenn dieses Projekt läuft, geht es gut. Wenn dieses Projekt scheitert, dann haben Sie ein Problem mit Ihrer Karriere. Bitte schön, ich erwarte, dass Sie mich mit Respekt behandeln und klar mit mir kommunizieren.“

und seitdem war der echt freundlich zu mir. Ja, das kann ich mir leisten.

Geropp:

Das kannst du als Außenstehender machen, ja.

Pfingsten:

Weil ich ihm sage, im Zweifel hätte ich gesagt, weißt du was, ist nicht meine Karriere, die da baden geht, ich muss ja dein Projekt nicht retten. Das ist der eine Punkt. Das sind die eher operativen Rollen. Was durchaus auch sehr viel Sinn macht und da komme ich in einen ganz anderen Aspekt, das sind Mentoren.

Mentoren sind Menschen, die in diesem Themenfeld schon ein paar Runden gedreht haben. Die einfach sagen, ich kann als Mentor mein Wissen weitergeben. Und es gibt einen großen, einen kleinen, aber sehr feinen Unterschied zwischen einem Mentor und einem Coach.

Coach sind Leute, die auch durch viel Training und Ausbildung quasi dieses Skill haben im richtigen Moment die richtigen Fragen zu stellen. Die müssen nicht zwingend Profi-Rennfahrer der Formel eins vorher gewesen sein, um trotzdem extrem exzellente Coaches zu sein. Das ist beim Mentor was anderes.

Ein Mentor war vielleicht mal früher Top Formel Eins Fahrer und gibt dieses Wissen eben weiter und gibt Tipps und sagt, okay, in der Situation würde ich es jetzt so und so und so machen. Und diese Mentoren-Rolle ist unglaublich wichtig und unglaublich wertvoll, weil dadurch sparen sich die Projekte und damit hinten raus natürlich die Unternehmen, viele, viele blutige Nasen, die sie auf dem Weg sonst sich einholen. Und das ist im Grunde – sind Mentoren, man könnte es jetzt sehr flapsig sagen, so was ähnliches, wie ein Versicherungsschein, ja, dass ich eben Zeit und Geld spare und nicht alle Fehler selber mache.

Geropp:

Ja, okay, verstehe ich. Ich habe noch ein anderes Thema, was aber in dieses Projektgeschäft sehr gut reinpasst, was ich gerne kurz mit dir besprechen möchte. Und zwar im letzten Leadership-Barcamp hast du das Kanban-Konzept erläutert.

Das kommt ja, wenn ich das richtig verstehe, eigentlich aus der Produktion, aber du verwendest es auch in Projekten und zwar recht erfolgreich und gerade bei so Abwicklungen und Visualisierung von großen Projekten. Aber du hast es da den einzelnen Leuten auch gezeigt fürs Selbstmanagement. Auch Selbstmanagement bei Führungskräften. Und da würde ich gerne, dass du ein bisschen was zu sagst.

Was steckt genau hinter Kanban? Was sind die Prinzipien und wie kann, ja, ich es als Führungskraft bei meinem Selbstmanagement auch einsetzen oder halt bei Projekten?

Pfingsten:

Also der Erfinder des Kanbans ist der Toyoda, also der alte Toyota-Unternehmer, der Ende der 1940er, ich glaube, 1947 rum, Kanban als Produktionsmethode in seiner Fertigung hat einbauen lassen. Basiert auf dem Engpass-Prinzip. Das heißt, ich erkenne über diese Methode halt Engpässe und kann diese Engpässe entsprechend bearbeiten und dadurch in Summe wesentlich höhere Qualität und wesentlich weniger, ja ich sage mal, Slagzeit also beziehungsweise die, ich habe mehr Durchsatz. So. Das ist im Grunde eine ganz alte Geschichte. Fertigungsingenieure nicken jetzt wahrscheinlich alle mit dem Kopf und sagen, ja haben wir im Studium gehabt, ist jetzt auch nichts Neues.

Ende der 1990er Jahre, Anfang 2000 sind Leute aus dem IT-Projektmanagement, aus der agilen Projektmanagement-Szene so durch Zufall da drüber gestolpert und haben gesagt, okay, wir müssen, wenn wir das für Geistesleister einsetzen, also für Menschen, die ihre Arbeit hauptsächlich mit dem Gerät zwischen den beiden Ohren erledigen, doch vielleicht ein paar Sachen ein bisschen anpassen, aber im Grunde die Idee ist die gleiche. So.

Die haben damals angefangen eben Kanban dann im Projektmanagement einzusetzen. Und diese Vorgehensweise habe ich selber übernommen dann in meine Projekte 2010, weil ich die Situation hatte, dass ich damals noch als aktiver Trouble-Shooter viel unterwegs war. Meine Auftraggeber immer die Situation hatten, da ist ein teuer bezahlter Kerl, der ist aber nie an dem Arbeitsplatz, wenn ich mal eine Frage habe und ich brauchte eine Visualisierung, dass eben was passiert im Projekt und konnte mit dieser Kanban-Methode, mit diesen Zettelchen, die dann wandern über dieses Board eben ihm sichtbar machen, auch wenn ich nicht da war, konnte er sehen, da wandern Zettel, also es muss ja wohl was passieren.

Das war so im Prinzip der Ursprungsantrieb bei mir. Dann natürlich gleichzeitig auch die Steuerung und dazu eben halt so eine Zwei-Wochen-Sprint-Geschichte immer gesagt, wer schiebt denn in den nächsten zwei Wochen welches Zettel bis wohin, welchen Zettelchen bis wohin und bin dann über ein Buch gestolpert, das nennt sich Personal Kanban. Das heißt, das sind dann wiederum Leute gewesen aus dieser Szene, die gesagt haben, das ist ja eigentlich ganz cool für Projekte.

Ich muss sagen, ich habe das auch bei meinen ganzen internationalen Projekten gemacht. Ich habe darüber Teams in Ägypten, Teams in China, Teams in Indien, USA und so weiter gesteuert. Mache das heute noch mit meinen eigenen Unternehmungen, dass ich verschiedene Kanban-Boards habe für verschiedene Projekte und ich habe damals dann dieses Buch gelesen und habe gesagt, das ist eigentlich eine verdammt pfiffige Idee, dass ich hingehe und diese Grundidee Visualisierung, Engpass, ja, eben so aufbaue, dass ich damit quasi meine eigene Arbeit organisiere.

Es gibt so das geflügelte Wort, Kanban ersetzt quasi eine To-Do-Liste und zwar in einer Art und Weise, dass du nie wieder das Problem hast, dass du alle zwei Monate vor lauter Frust deine To-Do-Liste zerreißt, weil sie ist so lang geworden, hast keine Ahnung, wie der Status der einzelnen Punkte ist, also schmeißt du sie weg und machst eine neue Excel-Liste. Das hast du nicht mehr.

Ich habe auch alles schon versucht von To-Do-Listen und allen möglichen Art und Weisen, mit Outlook und so weiter meine Arbeitsaufgaben zu organisieren, dass ich rechtzeitig mich um meine Sachen kümmere. Heute mache ich das Personal-Kanban und ja dem entsprechend habe ich viel mehr Zufriedenheit, weil ich habe gleichzeitig auch die Möglichkeit für mich zu visualisieren, die Sachen sind erledigt. Also eine Aufgabe ist ein Kärtchen. Das wandert dann so drüber und das wandert in die letzte Spalte dann und ich kann am Ende des Monats hingehen und mir die Spalte dann angucken und habe plötzlich doch selbst das zufriedene Gefühl: okay, hast ja doch diesen Monat eine ganze Menge bewegt.

Geropp:

Maik ich bedanke mich recht herzlich bei dir. War wieder richtig spannend mit dir.

Pfingsten:

Sehr gerne. Vielen Dank Bernd.

Geropp:

Danke.

Podcast abonnieren

Um meinen Podcast zu abonnieren und keine zukünftigen Folgen mehr zu verpassen, klicken Sie einfach auf einen der folgenden Links:

Hier klicken, um via iTunes zu abonnieren!

Hier klicken, um via RSS Feed zu abonnieren!

Ihr Feedback

Wie gefällt Ihnen diese Folge meines Podcasts? Ich freue mich über Feedback und Anregungen. Schicken Sie mir einfach eine E-Mail an info(at)berndgeropp.de.

Wenn Ihnen der Podcast gefällt, bewerten Sie ihn doch bitte auf iTunes! Das hilft, den Podcast bekannter zu machen und auf iTunes sichtbarer zu werden. Für die Bewertung einfach hier klicken! Danke!