Kaizen 2 go 017 : Prozesse in Projekten

 

Inhalt der Episode

  • Projekt vs. Prozess
  • Der Nutzen, die Kunden und die Benutzer – Beispiele aus der Automobil- und Medizintechnik
  • Lastenhefte – was sie sind aber auch nicht sind – welche Herausforderungen bei der Erstellung entstehen – Produkt- vs. Projektanforderungen, wie sie differenziert werden und welche Probleme entstehen, wenn das ignoriert wird
  • Was häufig in Projekten schief läuft und was man dagegen tun kann.
  • Prozesse als institutionalisiertes Organisationswissen und die Instanz, die dieses Wissen organisiert
  • Prozesse für Freiberufler & Solopreneure – deren Dokumentation, Visualisierung und kontinuierliche Verbesserung
  • Barcamp für Business Podcaster

Notizen zur Episode

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode jetzt bitte bei Apple Podcasts.
Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

(Teil)automatisiertes Transkript

Eine KI-generierte Zusammenfassung finden Sie am Ende des Transkripts.

Episode 017 : Prozesse in Projekten

Herzlich willkommen zu dem Podcast für Lean Interessierte, die in ihren Organisationen die kontinuierliche Verbesserung der Geschäftsprozesse und Abläufe anstreben, um Nutzen zu steigern, Ressourcen-Verbrauch zu reduzieren und damit Freiräume für echte Wertschöpfung zu schaffen. Für mehr Erfolg durch Kunden- und Mitarbeiterzufriedenheit, höhere Produktivität durch mehr Effektivität und Effizienz. An den Maschinen, im Außendienst, in den Büros bis zur Chefetage.

Götz Müller: Heute habe ich Mike Pfingsten bei mir. Mike Pfingsten ist eigentlich die Person, oder nicht nur eigentlich die Person, die mich zum Podcasten gebracht hat. Er betreibt nämlich mehrere Business-Podcasts, hat da auch ein, finde ich, wunderbares E-Book dazu geschrieben, das die einzelnen Schritte zum Business-Podcast beschreibt. Er war früher Troubleshooter in seiner Angestellten-Tätigkeit, aber in seiner Freiberuflichkeit dann. Hat dort Entwicklungsprojekte gerettet. Und weitere Details, da möchte ich ihm einfach das Wort geben, dass er sich selber vorstellt.

Maik Pfingsten: Ja, hallo Götz. Schön, dass ich dabei sein darf. Im Grunde hast du schon… Ich bin von Hause aus Diplom-Ingenieur Mechatronik, war zunächst fünf Jahre angestellt, zunächst erst als Software-Ingenieur, hinter als Projektleiter, System-Ingenieur, Troubleshooter in der Automobilbranche bei einem großen Zulieferer. Ich bin 2005 in die Selbstständigkeit gegangen, in die Freiberuflichkeit. Ich wollte die Welt sehen und eben auch, ich sag mal, wie so ein Handwerksgeselle auf Wanderschaft gehen, verschiedene Projekte, verschiedene Firmen und was eben halt dann relativ schnell klar war, war das Thema Projekte retten. Und so habe ich über zehn Jahre lang als Freiberufler, also erst als Angestellter und dann als Freiberufler, da Projekte gerettet. Große, internationale, komplexe Projekte wieder auf die Füße gestellt, aufs Gleis, sodass hinten raus das Projekt dann doch noch zum guten Ergebnis kam.

Götz Müller: Ja. auf der einen Seite mit dem, was ein Projekt ausmacht, klarer Anfang, hoffentlich klares Ende und den Prozess auf der anderen Seite, der ja diesen Anfang und Ende nicht kennt.

Maik Pfingsten: Ja.

Götz Müller: Wie siehst du diese Dualität zwischen Projekt und Prozess, speziell unter dem Aspekt Entwicklung?

Maik Pfingsten: Genau. Also für mich ist ein Prozess und auch die Dokumentation des Prozesses oder die Beschreibung, die drumherum sich dann auch ergibt, im Grunde eigentlich, ich sage mal, kondensiertes Wissen, Lösungswissen des Unternehmens. Also ein Unternehmen hat eine Kompetenz, irgendein, System, ein Produkt zu entwickeln und über die Jahre eben halt für sich selber Methoden, Vorgehensweisen, Templates und Checklisten und alles, was dazugehört, um so ein Produkt zu entwickeln oder etwas als Ergebnis herauszubekommen. Es muss ja nicht zwingend nur ein Prozess sein, um ein Entwicklungsprojekt zu begleiten. Es können auch Einkaufsprozesse oder sowas sein. Also im Grunde etwas, wo ein Unternehmen, egal ob jetzt zehn Leute, hundert oder tausend, für sich selber quasi erarbeitet hat über die Jahre. Wenn wir so vorgehen, dann kommt in der Regel eigentlich immer ein ganz gutes Ergebnis hinten raus. Das ist aus meiner persönlichen Sicht ein Prozess. Ja, das kann ich absolut unterschreiben.

Götz Müller: Mein Gefühl ist immer, dass aber dieses Bewusstsein, ich habe ja hier einen Prozess, obwohl ich so etwas Einmaliges wie Projekte habe, dass dieses Bewusstsein jetzt nicht so stark ausgeprägt wird.

Maik Pfingsten: Ja, es wird gerne an die Seite geschoben, weil es stört ja auch. Beziehungsweise es ist ja auch manchmal bei großen Unternehmen mit komplexen Systemen und komplexen Produkten, die dort entwickelt werden, oft so, dass es ja auch eine sehr umfangreiche Prozessbeschreibung ist. Und jetzt kommen wir zu dem ganz wichtigen Punkt, was ist ein Projekt? Ein Projekt hat in Konsequenz ja einen Auftrag, in irgendeiner Form ein Produkt zu entwickeln, was ja für den Kunden, der das Produkt kauft, einen Nutzen stiften soll.

Maik Pfingsten: Und jetzt habe ich auf der einen Seite dieses Produkt, dieses klare Projekt mit Anfang und Ende und eine Zielvorgabe. Und ich habe diesen riesengroßen Prozessbeschreibungs-Dokumentationsumfang aus Sicht des Unternehmens, wo im Grunde dieses kondensierte Wissen drin ist. Und was häufig aus meiner Sicht so irgendwie auch durcheinandergeworfen wird, ist, die Aufgabe des Projektes ist jetzt hinzugehen und zu sagen, Das ist unser Standardprozess, wie wir ein Produkt entwickeln. Aufgrund unserer Komplexität oder Nichtkomplexität, der Größe des Teams, der Verteilung des Systems, Neuigkeit, also ist es eine sehr innovative Technologie oder ist es eine Weiterentwicklung eines bestehenden Produkts und so weiter, gehe ich hin und gucke mir diesen Standardgesamtprozess an und entscheide, ganz wichtig zum Anfang eines Projektes, was aus diesem Prozess brauche ich, muss ich machen und was vielleicht brauche ich gar nicht. und lass es weg. Das sogenannte Tailoring. Das wird häufig gar nicht gemacht, sondern oft ist es so, das erlebe ich als aktiver Troubleshooter noch ganz stark, das wird alles an die Seite geschoben nach dem Motto, da haben wir keine Zeit für, wir machen ja ein Projekt.

Maik Pfingsten: Und hinterher ist es im Grunde eigentlich schwierig zu sagen, okay, warum habt ihr diese ganzen Sachen weggelassen? Ja, weil wegen, wir hatten keine Zeit und wo habt ihr es dokumentiert? Nee, haben wir nicht. Das ist oft so ein bisschen dieses Problem, was dann in dem Zusammenhang mit Prozess so ein Projekt entsteht?

Götz Müller: Ja, also das kann ich absolut nachvollziehen. Ich war zwar nicht im Automobilbereich, sondern in der Telekommunikationstechnik unterwegs, aber auch da sind es ja äußerst komplexe Systeme. Und genau der gleiche Aspekt, das Tailoring, das in der Regel nicht so gemacht wird, wie man es denn tun sollte. Also entweder wird zu viel weggelassen, sondern braucht man nicht. Oft ist es gar keine bewusste Entscheidung, in meiner Erfahrung, sondern aus Zeitgründen, aus den unterschiedlichsten Gründen, macht man halt Dinge einfach nicht. oder das andere extrem ist. Passiert gern dann, wenn man neue Projektmanager hat, die jetzt gerade mal auf einer Schulung waren und sie dann so gelernt haben, wie man das eigentlich tun sollte. Dann wird manchmal mit der Kanone auf Spatzen geschossen.

Maik Pfingsten: Ja, total.

Götz Müller: Ein Punkt, der mir gerade so nochmal durch den Kopf schoss ist, Das Entwicklungsprojekt hat natürlich unter Umständen, zumindest gedanklich, wenn man sich das denn so bewusst macht, auch andere Kunden im Unternehmen. Wenn ich zum Beispiel ein Auto entwickle, dann muss ich ja mal differenzieren zwischen demjenigen, der vielleicht irgendwann mal Autos fährt. Aber der Kunde meines Entwicklungsprojektes ist ja eher meine Fertigung. Und ich glaube, dass aus diesem Aspekt auch das eine oder andere Problem entsteht, wenn man sich diese zwei Unterschiede so gar nicht klar macht. Weil ich könnte ja ein wunderbares Auto bauen, das keiner fahren will. Oder ich könnte ein wunderbares Auto bauen, das sich ganz toll fahren lässt, das man aber nicht produzieren kann.

Maik Pfingsten: Ja, also das ist aus meiner Sicht auch ein ganz spannendes Thema und zwar an dieser Stelle, du hast ein Produkt oder ein System und dieses im Kern erzeugt es einen Nutzen. Also ich begleite mittlerweile seit ein paar Jahren als Mentor viele Entwicklungsprojekte aus unterschiedlichen Branchen, Automotive ein Stück weit noch, aber mittlerweile ganz viel Medizintechnik oder auch Firmen wie Hilti sind dabei mit ihren Werkzeugprodukten. Da ist es so, da entwickelt dieses Projekt ein System und dieses System erzeugt ein Nutzen. Also ein konkretes Beispiel, was jeder bei uns aus dem Auto kennt, ist eine Einparkhilfe. Dieses schön mit den vier Sensoren hinten und dem Piepsen. Da ist der Kernnutzen, sag ich mal so flapsig, für meine Mutter, die Sicherheit beim Rückwärts-Einparken nirgendwo gegen zu dutschen.

Das heißt, der Kunde für dieses System ist jetzt nicht der Autohersteller, sondern eigentlich, in Anführungsstrichen, meine Mutter, weil die dieses System ja auch nützlich empfindet. Das haben wir zum Beispiel übertragen in der Medizintechnik, hat jetzt auch gerade ein sehr interessantes Projekt begleitet. Der Kunde ist nicht das Produktmanagement und das Marketing von diesem Medizintechnikhersteller, sondern das ist eigentlich der Arzt, der dieses medizintechnische Produkt im Alltag bei sich in seinen Handlungen einsetzt. Für den muss es einen Nutzen stiften. Aber wir haben halt Einschränkungen, es muss produzierbar sein, es muss sich an Standardnormen halten, die in der Branche gelten und so weiter und so weiter. Das heißt, es ist immer sehr hilfreich, sich damit zu beschäftigen, was ist eigentlich der Nutzen meines Produktes, der Nutzen meines Systems für denjenigen, der hinter der Benutzer ist. Also meine Mutter oder der Arzt oder die Krankenschwester oder bei Hilti sind es halt beispielsweise die Handwerker. Und das ist ein ganz, ganz wesentlicher Punkt. Und dann wird mir auch klar, wenn wir uns auf Projekte und Prozesse schauen, zu sagen, okay, welche Prozesse brauche ich denn jetzt, um sicherzustellen, dass dieser Nutzen auch am Ende rauskommt und welchen brauche ich jetzt vielleicht gerade nicht, weil es ist eine Weiterentwicklung vom bestehenden Projekt oder so.

Götz Müller: Genau, und letzten Endes ist die Dualität zwischen Auftraggeber einerseits, der ja typischerweise in unserem Umfeld nicht der Nutzer ist, und dann aber die Beurteilung, was war denn der Erfolg, nicht nur im magischen Dreieck sich zu bewegen, sondern eben hinterher dann für den eigentlichen Nutzer den Nutzungserfolg sicherzustellen. Und ich glaube, dieses Bewusstsein tritt gern mal wieder immer mal wieder in den Hintergrund beziehungsweise ist nicht genügend im Bewusstsein dass es diese Dualität gibt dass es dieses Spannungsfeld auch gibt Ja,

Maik Pfingsten: Aber ich bin völlig bei dir und das ist ein ganz wichtiger Punkt, dass wir das auch versuchen, beide bewusst zu machen in unserem Podcast und zwar, das ist der einzige Grund warum der Kunde bei mir ein Produkt kauft Wenn ich ein mittelständisches Maschinenbautechnologieunternehmen bin und ich ein Produkt entwickle und dieses Produkt im Kern einen Nutzen hat, Kauft es der Kunde nur, weil dieser Nutzen da ist? Sprich, ich muss mich schon sehr bewusst damit beschäftigen, welchen Nutzen stiftet mein Produkt bei dem Kunden? Und das kann beliebig schwierig sein, weil ich sage mal, in der Automobilindustrie hast du halt diesen Dreisprung. Da ist ein Zulieferer, der macht dieses Einpacksystem, der verkauft das an einen Hersteller, was weiß ich, nehmen wir jetzt mal beispielsweise VW, aber den VW kauft meine Mutter. In diesem Beispiel. In anderen Situationen hast du es so, Beispiel Zeiss oder Hilti, als solche klassischen Unternehmen, die haben ein Marketing, ein Produktmanagement, das versucht bestmöglich diesen Kunden abzubilden.

Aber im Grunde sind sie es ja nicht, die das kaufen, sondern die sagen der Entwicklung, dem Entwicklungsprojekt, was ihre Wünsche sind an das zu entwickelnde neue Produkt, neue System. Also das ist so ganz typisch und deswegen ist es wichtig, dass die Projekte sich damit beschäftigen, was ist der Kernnutzen, den sie stiften. Weil an diesem Kernnutzen kann ich verschiedene Entscheidungen dran aufhängen. Ich kann die Entscheidung dran aufhängen, welche Standardprozesse aus unserem Prozessbaukasten brauche ich, was brauche ich nicht. Welche Art des Projektmanagements in welchem Umfang macht Sinn. Was sind denn die technischen Lasten, die ich umsetzen will später in meinem Projekt, also die Anforderungen an das System. Dinge kann ich wunderbar eben an diesem Kernnutzen messen und entscheiden das ist gut, das hilft sehr viel weiter, wenn wir das machen oder im Gegenteil, wenn wir das machen, dann machen wir den Nutzen kaputt.

Götz Müller:
Ja und dann haben wir noch den Effekt, wir sind ja alle Ingenieure und Ingenieure sind scharf drauf, tolle Sachen zu entwickeln und da kommt es glaube ich doch immer mal wieder vor, dass halt am Kunden, am Markt, am Nutzer vorbei entwickelt wird. Da wird ein tolles Leistungsmerkmal entwickelt. Wir kennen es, glaube ich, alle, wenn wir hier vor einem Monitor sitzen, in den verschiedenen Softwaren. Allein das, was mir an Word oder an Pages, wenn ich mich in der Apple-Welt bewege, zur Verfügung stellt und wie viel davon nutze ich eigentlich wirklich.

Maik Pfingsten: Genau, genau. Also wirklich dieses am Problem des Kunden sich zu orientieren und wie kann ich ein Produkt, ein System entwickeln, was einen hohen Nutzen stiftet. Also ich nehme mal das Beispiel von meiner Mutter. Die ist jetzt, die Gute ist über 70, fährt in Dortmund regelmäßig zum Markt und in der Innenstadt in ein Parkhaus. Und das ist eine klassische Situation, wo sich meine Mutter einfach unsicher fühlt, unwohl fühlt. Auch wenn es mit ihrem kleinen Polo ist, trotzdem fühlt es sich unwohl. So, das heißt, es gibt ja jetzt drei verschiedene Arten dieser Einparkhilfe. Es gibt die einfache, die nur hinten überwacht. Es gibt die, die hinten und vorne überwacht. Beide Systeme empfindet meine Mutter als hilfreich, weil bei dem einen weiß sie zumindest beim rückwärts einparken. Wenn es dann Dauer piept, bin ich dran an der Wand. Bei dem anderen weiß ich, okay, vorwärts und rückwärts hilft es mir beim Einparken. Aber es gibt ja mittlerweile auch schon Generationen, die zum Beispiel eine Rückfahrkamera haben. Oder gar halb oder ganz automatisch einparken können. Solche Systeme würden bei meiner Mutter aber wiederum, den Effekt auslösen, dass sie sich überfordert fühlt. Weil dann ist da eine Kamera und dann piepst es und dann bewegt das Auto noch von alleine das Lenkrad und da fühlt sie sich dann wiederum nicht mehr wohl bei. Das heißt, genau sich auch bewusst zu machen, wer ist da eigentlich mein Benutzer.

Und welches Problem hat er, in dem Fall meiner Mutter, das Einparken im Parkhaus in Dortmund und wo ist die Grenze des Nutzens, den ich stiften kann. Weil klar, so ein Teil- oder vollautomatisches Einparken ist natürlich ein hoher Nutzen, weil das Auto das im Grunde alles selber erledigt. Aber wenn ich mit der Technologie-Auto per se gar nicht so glücklich bin, sondern eigentlich in dieser Parkhaussituation eigentlich froh bin, wenn die Kiste in der Parklücke steht, kann so ein System dann auch überfordern. Das heißt, es hat zwar theoretisch einen hohen Nutzen, aber vielleicht eher für mich, der so ein geekiger Technik-Nerd ist und sich darüber freut, dass das Auto von selber das Lenkrad dreht. Bei meiner Mutter wird das wahrscheinlich dann wiederum andere emotionale Reaktionen aus. Und das ist immer ganz wichtig, sich ganz bewusst zu machen.

Götz Müller: Ja, und das sind ja dann Dinge, die letzten Endes in einem Lastenheft beschrieben werden. Was soll ich tun? Wie ich es dann tue, wird ja dann erst im Pflichtenheft, im Projekt entschieden. Und da möchte ich jetzt auf den Punkt Lastenhefterstellung auch mal kurz eingehen. Ich glaube, das ist eine ganz gute Überleitung. Da bist du ja aktuell auch aktiv. Was sind denn so die Herausforderungen für deine Kunden? Woran scheitern sie vielleicht auch? Womit kämpfen sie, wenn sie Lastenhefte erstellen?

Maik Pfingsten: Also das Wichtigste ist, wenn wir uns darüber unterhalten, was ein Lastenheft ist, sich auch bewusst zu machen, was ein Lastenheft nicht ist. Und zwar, ein Lastenheft ist eine Beschreibung der technischen Anforderungen an das zu entwickelnde Produkt, zu entwickelnden System.

Das ist aber was anderes als die Anforderung an das Projekt. Es gibt eine recht einfache Möglichkeit, das zu unterscheiden. Und zwar, wenn ich Anforderungen habe, die jetzt während des Projektes unglaublich wichtig sind, dann aber, wenn das Projekt abgeschlossen ist, historisch, dann sind es Projektanforderungen. Wenn ich Anforderungen habe, die auch nach Abschluss des Projektes wichtig bleiben, dass sie erhalten oder erfüllt werden, dann sind es in der Regel Lasten an ein technisches System. Konkretes Beispiel im Projekt, Entwicklungsbudget, Termine, Meilensteine, all diese ganzen Sachen, das sind Projektanforderungen. Das ist extrem wichtig, wenn das läuft, ist das Projekt abgeschlossen, interessiert das keinen mehr. Was anderes sind die technischen Anforderungen an das System.

Projekte, die ich vor fünf oder zehn Jahren begleitet habe, die Projektanforderungen sind heute völlig egal. Aber diese Systeme fahren ja noch draußen im Auto rum. Das heißt, die Anforderungen an das System sind immer noch unglaublich wichtig. Und das allein schon auseinanderzuhalten hilft viel. Also Lastenheft, ein technisches Lastenheft beschreibt die Anforderungen an das Produkt, an das System. Die Anforderungen an ein Projekt dokumentiere ich aber in ein Projekthandbuch oder wie auch immer das Kind dann heißt in dem Unternehmen. Das ist ein bisschen unterschiedlich je nach Unternehmen. aber in irgendeiner Form einem Auftrag, das ist im Grunde dann das Auftraggeber-Auftrag-Nehmer-Spiel mit dem Projekt, wo klar gesagt, das ist das Entwicklungsbudget, das sind die Meilensteine, das sind die Ziele.

Und das allein schon mal auseinanderzuhalten, das Lastenheft und Projektauftrag und die Anforderungen an das System und die Anforderungen an das Projekt sind einfach ganz unterschiedliche Dinge und das wird häufig zusammengeschmissen.

Götz Müller: Ja, also das kenne ich absolut auch so. auch in der Telekommunikationstechnik hat man dieses Szenario, wo unter Umständen ja der Nutzer noch ein Stückchen weiter weg ist, wenn ich an reine Übertragungstechnik denke. In dem Augenblick, wo ich zum Handy greife und da eine Nummer wähle oder eine E-Mail versende, denke ich ja nicht darüber nach, wie denn meine gesprochene Sprache oder mein Text auf die andere Seite kommt. Da habe ich diesen Nutzereffekt und das, was er wünscht, schon diesen Aspekt habe ich da gar nicht. Ja, das finde ich sehr spannend. Eigentlich ist es gar nicht schwierig, diesen Unterschied sich klar zu machen. Ich habe mal gelernt, das Lastenheft stellt halt die Frage nach dem Was und das Pflichtenheft, so das ist die Antwort der Entwicklung, beantwortet es Wie.

Maik Pfingsten:
Genau, jetzt kommen wir zu dem nächsten Aspekt. Wenn wir über Anforderungen, technische Anforderungen an ein System sprechen, gibt es verschiedene Ebenen, in denen das Ganze unterwegs ist. Das Erste, was wir haben, ist das Lastenheft. Also die Lasten an das System. Das ist im Grunde das Wünsch dir was des Kunden, wenn ich einen direkten Kunden habe oder das Wünsch dir was aus Marketing und Produktmanagement meines eigenen Unternehmens, wenn diese Abteilung, diese Gruppe quasi indirekt den Kunden darstellt. Das heißt, auch von dort muss ein Lastenheft in der Regel geliefert werden. Schwierigkeit ist, dass es häufig auf den Ebenen oder in den Bereichen oft entweder die methodische oder fachliche Kompetenz fehlt, so etwas zu erstellen, geschweige denn von Zeit und Lust dazu.

Aber dort kommt es eigentlich her, dort wird das Wünschte was beschrieben, was eigentlich hinter das Entwicklungsprojekt als System entwickeln soll. Jetzt ist es die Aufgabe des Entwicklungsprojektes, darauf eine Antwort zu finden. Das bedeutet, jetzt sind wir auf der nächsten Ebene und sagen, okay, die Sachen, die in dem Lastenheft stehen, das können wir eins zu eins übernehmen, das ist okay, da gehen wir mit. Bei den Sachen, das muss detailliert werden und diese Sachen lehnen wir ab. Also ein Pflichtenheft als Antwort auf ein Lastenheft ist durchaus ein wesentliches Element, um nochmal Klarheit reinzubringen und Dinge weiter zu detaillieren. Das ist im internen Verhältnis bei Unternehmen, die halt über Marketing und Produktmanagement ihren Kunden abbilden, eine ganz komplette interne Geschichte. Wirklich relevant wird es auch rechtlich, wenn es halt zwei Firmen sind. Sprich ein KMU sagt, ich möchte gerne X entwickelt haben und ein Ingenieurdienstleister, Spezialist, Lieferant sagt, ich kann es entwickeln und fertigen. Dann ist Lastenheft und Pflichtenheft auch ein Teil der Vertragsvereinbarung zwischen den beiden Unternehmen. Das heißt, was für allen Unternehmen immer ganz bewusst klar ist, dass die kaufmännische Seite auch rechtlich komplett abgesichert wird. Was viele aber irgendwie so hinten rüberkippen lassen, ist, dass vielleicht auch diese technische Anforderungsseite zumindest mal mit berücksichtigt werden sollte.

Ich hatte jetzt letztens so einen Fall, wo es darum ging, dass wir innerhalb von zwei Wochen ein Lastenheft erstellt haben. Für ein Maschinenbauunternehmen mittelständisches, die eben für 5 Millionen Euro eine neue Robotikanlage kaufen wollten. Und dann ist der Projektleiter dort halt komplett auf die Barrikaden gegangen, hat gesagt, das können wir nicht ausschreiben. Wir haben nur zehn Zeilen in Excel. Da kann uns dieser Automatisierungszulieferer alles Mögliche liefern und vor allem hinterher auch noch alles Mögliche nicht liefern, was wir vielleicht uns gewünscht haben. Und da haben wir wirklich dafür gesorgt, dass von zwei Wochen einfach ein technisches Lastenheft da war, damit dieser Einkäufer losspazieren konnte, mal bei verschiedenen Automatisierungstechnik-Lieferanten, anfragen konnte, wir hätten gerne 5 Millionen Euro in unsere Fertigung investiert und zwar für diese, Robotikverkettungsanlage und das sind unsere Wünsche, unsere Anforderungen, unsere Vorstellung, was da am Ende stehen soll. Das Schöne ist dann auch aus Sicht des Zulieferers hat er jetzt eine Möglichkeit dazu auch Stellung zu nehmen, also man muss jetzt noch nicht zwingend sofort ein komplettes Pflicht schreiben, aber zumindest mal eine Antwort darauf geben zu sagen, okay, das können wir, das können wir nicht und das würden wir anders machen. Und so ist es in diesem Verhältnis zwischen den Unternehmen auch ein Bestandteil der technischen Diskussion auf den technischen Ebenen miteinander. Nicht nur die Kaufleute und die Rechtsanwälte haben sich zu einigen bei solchen Geschichten, sondern eigentlich ist unsere Zunft muss eigentlich auch mit eingebunden sein.

Götz Müller: Gut, jetzt sind auch, denke ich mal, also auch in meiner Erfahrung vor allen Dingen, das Thema Lasten und Pflichten, das ist nicht immer der Grund. Das kann ein Grund sein, ist aber nicht unbedingt immer der Grund, warum eben Produktentstehungsprojekte, Prozesse da schief laufen. Was ist denn deine Erfahrung, was so besonders beliebt schief geht?

Maik Pfingsten: Also im Grunde ein wesentlicher Schlüssel sind Lasten, oder überhaupt die Anforderungen, ich meine jetzt völlig egal auf welcher Ebene, überhaupt sich mal klarzumachen, was sind die Anforderungen an das zu entwickelnde Produkt. Aber das ist nicht die einzige Baustelle, die einzige Ursache. Oft bei internationalen Projekten wird das Thema Kommunikation und interkulturelle Zusammenarbeit völlig unterschätzt. Also gerade internationale Projekte, Unternehmen, die internationale Entwicklungsprojekte das allererste Mal machen, unterschätzen völlig, dass wir in Deutschland eine andere Kultur pflegen, miteinander zu diskutieren, zu ringen und zu einem Ergebnis zu kommen, als es vielleicht in einem arabischen oder in einem asiatischen Raum üblich wäre.

Und dementsprechend, allein das schon mal sich bewusst zu machen, da steht viel Kommunikation hinter. Also als Systemingenieur und gerade noch, wenn ich als Systemingenieur in einer Troubleshooter-Rolle auch Projektleitungsaufgaben mit übernehme, ist der größte Teil meines Jobs, 80% und mehr, eigentlich Kommunikation. Und ein Kollege hat mal so schön gesagt, wir sind eigentlich Information Broker. Wir transportieren Informationen von A nach B mit dem Ziel, möglichst ein gleiches Verständnis herzustellen. Nicht nur über die Anforderungen, sondern auch über die Umsetzung hinter dem Projekt. Das ist eine Riesenbaustelle. Das muss jetzt nicht nur bei internationalen Projekten. Das passiert auch gerne mal bei europäischen oder mehrheitlich hauptsächlich in Deutschland laufenden Projekten. Aber je größer die Internationalität wird und wenn wir auch über Europa rausgehen, ist das meistens etwas, was völlig unterschätzt wird.

Götz Müller: Ja, so eine Erfahrung habe ich auch gemacht. Bei mir geht die Erfahrung noch ein Stückchen, ich will nicht sagen weiter oder eben auch ein Aspekt. Da habe ich einerseits Entwicklung und da habe ich andererseits Produktmanagement. Schon die zwei sprechen manchmal unterschiedliche Sprachen. Und dann habe ich innerhalb der Entwicklung, jetzt im Telekommunikationstechnikbereich ganz wichtig, viel Software. Dann natürlich aber auch klassische Hardware, wo einfach nur unter Umständen auch nur Blech gebogen wird. Ich rede jetzt nicht mehr von bestückten Leiterkarten. Und dann gibt es so ein Ding zwischendrin, ASICs, die eigentlich mit Softwaremitteln heutzutage erstellt werden, andererseits aber sehr oft von Hardwareentwicklern gemacht werden und schon die sprechen unterschiedliche Sprachen. Und spannenderweise, ich habe dann die Erfahrung gemacht, beispielsweise mit englischen Kollegen, englische Softwareentwickler, deutsche Softwareentwickler sind sich viel ähnlicher wie ein deutscher Softwareentwickler und ein deutscher Hardwareentwickler. Kennst du solche Erfahrungen?

Maik Pfingsten: Ja, absolut. Also ich kenne das als Mechatroniker. Einer unserer Professoren hat mal so flapsig gesagt, sie werden hinterher feststellen, sie haben jedes Buch nur zum Drittel gelesen. Also Maschinenbau ein Drittel, Elektronik ein Drittel, Software Engineering ein Drittel. Aber das hat dazu geführt, dass einfach auf Systemebene die Fähigkeit ist, da ist mit diesen verschiedenen Fraktionen Disziplinen quasi zu kommunizieren. Weil es gibt ein ganz simples Beispiel und zwar der Begriff Komponente. Wenn ich mit einem Softwareingenieur rede und sage, was ist denn die Komponente, dann hat der ein ganz anderes Bild im Kopf, als wenn ich mit einem Elektronik-Hardware-Ingenieur rede und frage, was ist denn die Komponente. Und wenn ich einen Konstrukteur frage und sage, was ist denn die Komponente, hat der wieder ein ganz anderes Bild. Es ist beides mal, in allen drei Fällen, der gleiche Begriff. Ja, absolut. Und das ist so, ja.

Götz Müller: Ja, zum Teil hast du schon angedeutet, was man dagegen tun kann, gegen das, was schiefläuft. Reden, reden, reden. Mein Standardspruch an der Stelle, wenn es jetzt um Prozesse optimieren geht, sage ich auch immer wieder, hey, ihr könnt nicht zu viel reden. Ihr könnt nicht zu viel reden. Klar kostet das Zeit und ich habe immer wieder dann auf der Kundenseite die Entscheider, die Geschäftsführer, die sagen, ah, jetzt muss es aber vorangehen und sind halt ungeduldig. Aber die Erfahrung habe ich selber auch gemacht, wenn irgendwas schief geht und du bist ehrlich zu allen Beteiligten, dann wirst du zum Schluss immer diese anderthalb Kilograue Masse finden, die irgendwo zwischen zwei Ohren sitzt. Egal, ob es ganz nackte, auch zwischenmenschliche Themen gibt oder wenn es nur darum geht, hier nochmal vielleicht einen halben Tag darüber nachzudenken, Stichwort FMEA, was kann passieren, was sind die Folgen, wie kann ich es erkennen, wie kann ich es vermeiden. Und da eben auch wichtig, Kommunikation mit den Menschen. Und eben, wenn ich also in meinem persönlichen Weltbild, ich weiß nicht wie dir es geht, als Ingenieur, in meinem Ingenieursweltbild gibt es diesen Begriff technisches Versagen nicht.

Egal, was ich mir angucke, natürlich manchmal muss man ein, zwei Schritte weitergehen. Ich nehme immer da dieses traurige Beispiel, ich glaube 2009 war es, der Airbus, der Air France Airbus, der da über den Südatlantik verschwunden ist, ins Meer gestürzt ist, Kann durchaus sein, dass man eben diese Möglichkeiten, man spekuliert ja glaube ich immer noch, war es der Staudruckmesser, der Geschwindigkeitsmesser, die da nicht richtig funktioniert haben. Vielleicht hat man an der falschen Stelle eine Runde zu früh in der FMA aufgehört und diese Entscheidung letzten Endes trifft ein Mensch.

Maik Pfingsten: Also es ist immer ein Spagat zwischen, ich sag mal auf der einen Seite Kommunikation, Verständnis bilden, verstehen oder wie es so schön heißt, nicht verstehen ist die Regel. Also wenn wir miteinander reden, allein durch die ganzen Kommunikationsprozesse, die ablaufen, wenn ich anfange zu reden und mir ein Gegenüber zuhört und da gibt es so viel Verluste auf der Strecke, dass die Wahrscheinlichkeit hoch ist, dass Nicht-Verstehen die Regel ist, das kannst du dann mit entsprechend, wenn du die Methoden und so weiter kennst, aktive Kommunikation einfangen. Aber nichtsdestotrotz, ich bin bei dir. Gerade das ist eine Herausforderung, dafür brauchst du Zeit. Auf der anderen Seite ist aber auch irgendwann wichtig, den Punkt zu finden, zu sagen, so, und jetzt muss ich umswitchen ins Handeln und ein Ergebnis mal produzieren, um dann, wenn ich diesen Flock irgendwo in die Erde gesteckt habe, Erkenntnisgewinn zu haben, um darauf basierend wieder weitere Klärungen herbeizufügen. Ich glaube, dieses Spiel… Funktioniert nur zusammen. Ich darf aber keins von beiden irgendwie hinten raus abwürgen.

Götz Müller: Ja, und ich muss ein Stück weit, wenn es um neue Dinge geht, wenn es um Veränderungen geht, muss ich auch bereit sein, Fehler zu machen. Denn letzten Endes lerne ich nur aus Fehlern. Wenn ich von vornherein, wenn ich im Labortisch stehe, meinetwegen Chemiker, Wissenschaftler, so das klassische Bild des Wissenschaftlers, und ich stelle mir vor, ich mache jetzt da irgendeinen Versuch, was es auch immer im Detail sein mag und ich kenne das Ergebnis schon genau, dann schaffe ich kein neues Wissen. Dann entsteht da kein Fortschritt. Nur durch den Schritt ins Unbekannte mit der dazugehörenden, was du vorhin gesagt hast, mit der dazugehörenden Fehlerkultur auch, dann eben, wenn mal ein Fehler gemacht wird, in der Veränderung, in der Verbesserung, nicht gleich Kopf runter, sondern eben sagen, ja, daraus haben wir jetzt was gelernt.

Maik Pfingsten: Genau. Also das ist auch immer das, was ich sage, wenn es um das Thema Lastenhefte geht. Viele scheuen sich ja überhaupt, Lastenhefte anzupacken. Oft gibt es da so unterschwellige Ängste nach dem Motto, dann ist das einmal in Stein gegossen und dann kann ich es nie wieder verändern. Oder wenn ich es unterschreibe, werde ich dafür haftbar gemacht und so weiter. Das sind so alle möglichen Ängste, wabern da so im Unterbewusstsein häufig mit. Der Punkt ist der, und das sage ich auch ganz offen, Lastenhefte sind einfach nur eine Dokumentation nach aktuellem Stand und bestem Wissen und Gewissen.

Es gibt nie ein fertiges Lastenheft im Sinne der kompletten Vollständigkeit, kann es gar nicht geben, weil die Welt dreht sich weiter. Das heißt, ein wichtiger Teil, und im Grunde gilt das für alle Formen oder Ebenen und Artefakte der Spezifikation, nicht nur für die Lastenhefte, ist, ich kann einfach nur versuchen, es in einen Rahmen zu fassen und mal zu dokumentieren, um eben darauf basierend nächste neuere Erkenntnisse zu gewinnen und dann wiederum das zu aktualisieren. Das gilt für ein Lastnift genauso wie für eine konkrete Implementierung. Wenn ich merke, okay, ich habe da jetzt einen neuen AD-Treiber implementiert und der tut es aber nicht, okay, Fehler gemacht, müssen gucken, dass wir an der Stelle mit dieser Erkenntnis neue Lösungen finden, aber dementsprechend auch, und da sind Prozesse, das ist ein ganz wichtiger Spagat oder Punkt auch wieder zum Thema Prozesse, dass das dann auch als Wissen im Unternehmen wiederum verbleibt und nicht, weil irgendwie der Mitarbeiter nach zwei Jahren kündigt, verschwindet die komplette Verständnis, dass eine gewisse Art der AD-Wandler, jetzt mal konkret ein Beispiel aus der Hardware, schlicht und einfach nicht funktioniert in diesem System, sondern solche Projektprozesse, Produktentstehungsprozesse und aber auch Projektentwicklungs- oder Projektmanagementprozesse sind ja quasi dafür da, um solches Wissen eben zurück ins Unternehmen fließen zu lassen und eben zum Beispiel über Checklisten sicherzustellen, hast du das nicht verwendet, hast du das nicht verwendet, hast du da drauf geachtet, hast du da drauf geachtet.

Götz Müller: Ja, und dann ein Stück weit eben auch über die nackte Lebenszeit des Projektes. Ich habe was abgeliefert und dann aber noch nicht gleich Klappe zu und ab in den Schrank, sondern dann nochmal sich als Teil des Prozesses, des Entstehungsprozesses nochmal hinsetzen, zu reflektieren, post mortem, was auch immer da die Begriffe sind, zu reflektieren, was habe ich denn jetzt gelernt daraus über das reine Produzieren, des Projektergebnisses hinaus.

Maik Pfingsten:
Und an dieser Stelle halte ich auch die Rolle des Entwicklungsqualitäters für unglaublich entscheidend. Das ist genau die Instanz, die in der Lage ist, zum einen mit mir, das ist das, was ich als Troubleshooter immer hatte, wenn ich in so ein Projekt reingesprungen bin. Das erste ist, ich habe mir angeguckt, was sind die standarddefinierten Prozesse bei dem im Projektmanagement und im Produktentwicklungsprozess. Und habe dann mir den Entwicklungsqualitäter geholt und habe gesagt, so, mein Freund, jetzt setzen wir uns beiden mal hier in diese kleine Kämmerlein und ringen so lange, bis wir beide eine Hand drauflegen können und sagen können, okay, so kriegen wir in den nächsten sechs Monaten hier das Problem vom Tisch und das Projekt zum Erfolg. Das heißt, dieses Ringen ist wichtig und aber auch im Nachgang kann dieser Entwicklungsqualität in seiner Rolle eben hingehen und dieses Wissen wieder einsammeln. Weil weder der Projektleiter noch die Fachingenieure, Fachspezialisten noch die Linienführungskräfte sind diejenigen, die dafür die Ausbildung haben, beziehungsweise die Zeit und meistens auch nicht die Lust. Dementsprechend ist so ein Entwicklungsqualität wieder derjenige, der das einsammeln kann und mit seinen Kollegen aus den anderen Fraktionen, also Fertigungsqualität, keine Ahnung woher, dann im Gesamtprozess wieder hineinbringt und sagt, okay, wir dokumentieren mal, was sind neue Erkenntnisse für die zukünftigen Projekte.

Götz Müller: Ja, und das ist dann, denke ich mal, auch der Mehrwert der Qualitätssicherung, auch wenn es jetzt in meinem Umfeld Qualitätssicherung ja eigentlich zu den Verschwendungen gehört, weil ich könnte es ja gleich richtig machen, da bräuchte ich es gar nicht. Aber wo dann da eben auch im Entwicklungsbereich Qualität, Qualitätssicherung dazu beiträgt, was zu lernen und nicht so das natürliche Feindbild sein muss, sondern eine unterstützende Rolle hat.

Maik Pfingsten: Ja, ich vergleiche das immer mit Sportmannschaften. Also da hat jeder, also wenn ich Champions League spielen will, und die meisten von uns in ihrem Bereich haben das schon als Anspruch, irgendwo in der Top-Liga zu spielen in ihrer Nische, also auch als Hidden Champion, dann gibt es in so einem Unternehmen, in so einem Projekt, in so einem Bereich halt ganz verschiedene Fachspezialisten wie beispielsweise beim Fußball und es ist völlig klar ich kann den Stürmer nicht beauftragen gleichzeitig auch noch ein zweiter Roller, da ist er nicht spezialisiert drauf, er wird das irgendwie hinkriegen aber richtig gut macht er das vermutlich nicht, Und das gleiche habe ich im Unternehmen auch. Ein Software-Ingenieur dazu zu verdonnern, dass er jetzt morgen Gesamtprojektleiter wird, wird wahrscheinlich nach hinten losgehen. Wird sogar auch keiner auf die Idee kommen. Aber genauso kann ich ihn auch nicht dazu verdonnern, dass er qualitätssichernde Methoden, Maßnahmen perfekt umsetzt. Sprich zum Beispiel Dokumentation von Prozessen. Das ist etwas, wo es andere Spezialisten gibt und das sind eben Qualitätsingenieure. Und dementsprechend sind die unglaublich wichtige Sparing-Partner für mich immer. Also ich war die allererste Person, die ich mir in so ein Troubleshooting-Projekt herangezogen habe, ist der für mein Projekt verantwortliche Qualitäter.

Götz Müller: Okay, spannend. So, zum Abschluss möchte ich jetzt noch einen anderen Punkt aufgreifen, nämlich dein Thema Lifestyle Entrepreneur und Prozesse, die dort für Freiberufler, für Solopreneure wichtig sind. Was sind für dich die wichtigen Prozesse für diesen Personenkreis?

Maik Pfingsten: Also im Grunde das Wichtigste ist der Prozess, um den Nutzen für den Kunden zu stiften. Das gilt im Grunde genauso für mich als Solopreneur, als Freiberufler, der eine hochspezialisierte Dienstleistung anbietet, wie auch für ein Entwicklungsprojekt. Nur habe ich natürlich einen ganz anderen Rahmen, in dem ich unterwegs bin. Aber was ich mache, da kommt vielleicht auch der Systemingenieur bei mir sehr stark raus, Ich habe eine ganz klare Dokumentation, wie bei mir eine Dienstleistung abläuft. Also beispielsweise diese Geschichte, in zwei Wochen ein Lastenheft zu erstellen, hat eine ganz klare Prozessbeschreibung, wo klar ist, was ist der erste Schritt, was ist der zweite Schritt, was ist der dritte Schritt, was sind die Meilensteine, was sind die Spielregeln, was wird es nicht geben, was sind die Templates, was sind die Checklisten. Das hilft mir als Freiberufler, auch im Sinne des Kunden gut zu sein. Dann kann ich ihm nämlich sagen, okay, ich mache für dich das Lastenheft und zwar läuft es genau so.

Und wenn, also es gibt Kunden, die dann damit Schwierigkeiten haben, aber dann ist es okay, dann passt es nicht. Aber ich habe im Gegenteil häufig auch die Situation, dass Kunden glücklich sind, weil gerade in diesem Bereich, wo sie ein Problem haben, eine Lösung suchen. Und wenn ich für dieses Problem eine wirklich 100% passende Lösung habe und diese Lösung bringt halt klare Spielregeln mit sich, führt das dazu, dass auf der anderen Seite oft auch Unsicherheit genommen wird. Weil es ist klar, da kommt der Experte, der weiß, wie man Lastenhefte innerhalb von zwei Wochen erstellt und der sagt, okay, es funktioniert nur auf diesem Weg, da müssen wir uns alle dran halten. Und dann habe ich eher den Effekt, dass diese klare Darstellung des Prozesses, wie ich meine freiberufliche Leistung produziere.

Auch entsprechend akzeptiert, viel stärker auch akzeptiert wird, als wenn ich so allgemein war. Aber man könnte vielleicht eventuell mal einen Workshop machen und dann vielleicht mal irgendwie anfangen. Und was halt auch für mich wichtig ist oder was mir immer schon wichtig ist, ich kann mich auch kontinuierlich verbessern. Weil wenn ich diesen Prozess einmal habe und er auch einen hohen Nutzen stiftet und der Kunde ihn auch sehr gut gebrauchen kann und ein Problem löst, dann kann ich auch gucken, was kann ich immer weiter verbessern. Also beispielsweise bei mir war es bisher so, Also Lastenhefte habe ich früher vor Ort, also als Systemingenieur sind Lastenhefte Teil meiner Arbeitsergebnisse, deswegen Lastenhefte zu erstellen ist für mich Handwerk. Früher war das so, als Troubleshooter musste ich auch mit anpacken oder habe ein Team von Requirements-Ingenieuren gesteuert, die eben das Lastenheft erstellt haben.

Aber das war eben vor Ort. Dann kam der Punkt, wo ich über meine ganzen Geschichten eben mein Geschäft halt mehr und mehr über das Internet virtualisiert habe. Das heißt, viele Tätigkeiten bei der Erstellung des Lastenheftes laufen bei mir im Büro und gar nicht mehr vor Ort beim Kunden, sondern nur noch der Kick-Off-Workshop und der Review-Freigabe-Workshop am Anfang und am Ende. Und auch das ist jetzt zum Beispiel dadurch, dass ich es kontinuierlich verbessern kann, weil es eben so standardisierter Prozess ist, wo ich jetzt an dem Schritt bin und sage, und demnächst bei den neuen Kunden wird es auch über Web-Sessions gehen, weil es auch einen hohen Nutzen wiederum stiftet, bevor die anfangen jetzt, oder wir alle müssen zum Ort X reisen, damit wir uns da für den Tag mal zusammenschließen. Die sitzen sowieso verteilt, ich sitze meistens auch sowieso ganz woanders wie der Kunde. Und so können wir uns über das Web treffen, diesen Kick-Off-Workshop machen, die Anforderungsaufnahme visuelle, also mit dem System-Fundprint visualisieren die Anforderungen und auch die Review-Session kann man mittlerweile darüber machen. Und sie sind es auch größtenteils gewohnt, die Kunden, weil über Web-Sessions wird auch häufig miteinander gearbeitet. So, und das ist eben der nächste Schritt. Wenn ich mir Gedanken mache über die Prozesse in meinem Solopreneur-Business, in meinem freiberuflichen Business, kann ich unglaublich viel bewegen für den Kunden, was einen Nutzen angeht, den ich stiften kann. Und natürlich hinten raus, wenn ich immer besser werde, werde ich irgendwann Meister in diesem einen Bereich und werde mit Sicherheit sehr erfolgreich.

Götz Müller: Und wenn die Kunden ganz schlau sind an der Stelle, müssen sie ja mal das Bewusstsein haben, sie können diesen Teil ja offensichtlich nicht, dann sprechen sie keinen Unterstützung. Und wenn sie ganz schlau sind, dann stellen sie noch einen extra hin, der jetzt gar nicht inhaltlich mitdiskutiert, sondern nur beobachtet, was du eigentlich machst, damit sie hinterher gelernt haben, wie funktioniert es denn wirklich.

Maik Pfingsten: Nö, da habe ich wenig. Ich habe sogar den Effekt, dass ich es komplett ausführlichst in meinem Podcast erkläre, wie ich vorgehe. Aber es zu sehen oder zu hören bedeutet noch lange nicht, dass ich Meister bin in diesem Bereich. Richtig. So, und dementsprechend, ja, es gibt Leute, die das versuchen nachzumachen, auch andere freiberufliche Ingenieure, die meine Sachen, die ich da im Zukunftsarchitekten erzähle, versuchen nachzumachen. Habe ich auch gar kein Problem, ich bin nicht gut, ja, wird diese Idee weitertransportiert. Aber es gibt so aus dem Profisport so eine schöne 10.000-Stunden-Regel. Wenn ich etwas 10.000 Mal gemacht habe, dann bin ich in der Regel Profi, bin ich Meister meines Faches. Und auch an der Stelle ist es schwer, den Meister.

Also ich werde immer nur Zweiter sein, wenn ich den Meister abgucke, sondern es macht viel mehr Sinn, sich selbst in seinem Bereich, in seinem Schwerpunkt zu einem Meister, in diesem Sinne der japanischen Kämpfer, ist das ja, diese entsprechende Reife, den Grad erreichen zu werden, anstatt dass ich jetzt einfach nur immer versuche, ihn zu kopieren. Und ich löse ja auch ein konkretes Problem. Es gibt andere Kunden, aber da ist es ein anderes Angebot, wo die zum Beispiel sagen, okay, wir haben verstanden, dass wir einfach furchtbar schlecht sind und dass Lastenhefte unglaublich wichtig sind und es macht wenig Sinn, aus Kapazitätsgründen jetzt dauernd den Mic einzuspannen. Da macht es viel mehr Sinn, auf einer viel höheren Ebene den Mic dazu zu holen und über Monate, teilweise Jahre, als Mentor verschiedenste Projekte begleiten zu lassen, sodass irgendwann diese Projektleiter selber laufen können und selber wissen, wie sie ein Lastenheft erstellen. Die werden nie so schnell sein, vor allem am Anfang wie ich, und mit Sicherheit nie die methodische, fachliche Kompetenz haben am Anfang. Aber sie sind zumindest mal so weit auf dem Pferd, dass sie für zukünftige Projekte alleine können. Und wenn sie das dann weiterentwickeln, zumindest in einer professionellen Ebene bringen können, das ist dann auch die Hoffnung. In einem Unternehmen, das funktioniert sehr, sehr gut. Aber das ist eine ganz andere Schiene.

Götz Müller: Okay, zum Abschluss, dein Schlusswort, was gibst du unseren Zuhörern mit, was können sie tun, um besser zu werden, besser werden in ihren Produktentstehungsprozessen, um ihre Entwicklungsprojekte besser durchzuführen, besser abzuschließen, aber auch die Solopreneure, die Freiberufler?

Maik Pfingsten: Also was ich mitgebe als Botschaft ist, Prozesse sind wichtig und sie zu visualisieren und zu dokumentieren ist unglaublich wichtig. Das ist völlig egal, ob du als Solopreneur alleine unterwegs bist mit deiner hohen Spezialisierung oder eben als mittelständischer Technologie-KMU unterwegs bist mit deinem hochspezialisierten Produkt. Und Prozesse sind unglaublich wichtig und vor allem, was auch wichtig ist, sich immer bei jedem Projekt mit diesen Prozessen auseinanderzusetzen. Also den größten Fehler ist, dieses konservierte Wissen an die Seite zu schieben und wieder irgendeine eigene Locke zu drehen. Diese Projekte sind meistens die, wo ich dann hinterher zu Besuch kam. Und das wird teuer. Also einen Troubleshooter einzukaufen wird zeitlich und finanziell teuer. Und ich bin nicht die teuerste Komponente, weil das Problem zu lösen kostet hinterher einfach schlicht Geld, sondern da kommt ganz viel zusammen und dementsprechend, also macht euch die Mühe, geht hin, dokumentiert eure Prozesse und reflektiert sie auch, wenn ihr entsprechend unterwegs seid.

Götz Müller: Und jetzt setze ich die eigene Vertriebsmütze kurz auf, holt euch jemand, der Erfahrung damit hat, wie man Prozesse dokumentiert.

Maik Pfingsten: Genau. Und das ist ganz, ganz wichtig. Und da bin ich zum Beispiel nicht der Richtige. Ich bin ein Systemingenieur, der spezialisiert auf Lastenhefte, aber jemand wie du, der eben genau in der Situation oder genau dieses Handwerk, die professionelle Expertenfähigkeit mitbringt, Meister ist in diesem Fach, genau diese Leute sind die Richtigen, die da entsprechend anzusprechen sind. Deswegen bin ich völlig bei dir. Spezialisten dazuholen macht auch viel mehr Sinn, als zu versuchen, über Jahre hinaus das irgendwie selber mit Versuchen scheitern zu lernen.

Götz Müller: Genau, prima. Wunderbares Stich, wunderbares Abschlusswort. Maik, ich danke dir für deine Zeit, jetzt eine Dreiviertelstunde.

Maik Pfingsten: Sehr gerne.

Götz Müller: War ein sehr interessantes Gespräch und ich denke aktuell drüber nach über dein Barcamp, dass du im September machst, 24. glaube ich, intensiv drüber nach und werde alles versuchen, mir da diesen Tag freizuhalten. Ich kann mir vorstellen, dass das eine spannende Erfahrung nochmal wird.

Maik Pfingsten: Also ich freue mich schon sehr drauf. Also das wird mit Sicherheit super. Wir haben bis jetzt schon 10 Anmeldungen und es ist ja noch lange Zeit, also ich habe ja im Grunde drei verschiedene Preisstaffeln, aber ich mache Ende August die Tür zu. Dann weiß ich, wie viele Leute da sind. Ich gehe also ganz schwer davon aus, dass wir noch 10 oder 15 weitere dabei haben werden. Und ich kenne es vom Systemcamp. Das ist eine super Größe für ein Barcamp. Das ist so familiär und so eine tolle Vernetzung und Austausch. Das wird cool. Also ich freue mich schon richtig drauf.

Götz Müller: Also vielen Dank und bis demnächst wieder.

Maik Pfingsten: Danke dir auch. Bis demnächst.

Götz Müller: Das war das spannende Interview mit Maik Pfingsten. In den Notizen zur Episode finden Sie verschiedene Links zu weiterführenden Seiten, zu seiner Website, zu seinen Podcasts.

Wenn Ihnen diese Episode gefallen hat, freue ich mich über Ihre Bewertung bei Apple Podcasts. Sie geben damit auch anderen Lean-Interessierten die Chance, den Podcast zu entdecken.

Ich bin Götz Müller und das war Kaizen to go. Vielen Dank fürs Zuhören und Ihr Interesse. Ich wünsche Ihnen eine gute Zeit bis zur nächsten Episode. Und denken Sie immer daran, bei allem was Sie tun oder lassen, das Leben ist viel zu kurz, um es mit Verschwendung zu verbringen.

KI-generierte Zusammenfassung

In dieser Episode spricht Götz Müller mit Maik Pfingsten über das Spannungsfeld zwischen Projekten und Prozessen sowie über Erfolgsfaktoren in Entwicklungsprojekten und im Solopreneur-Business.

Zu Beginn stellt Götz Müller seinen Gesprächspartner vor und würdigt, dass Maik Pfingsten ihn selbst zum Podcasten inspiriert hat. Maik Pfingsten berichtet von seinem Werdegang als Diplom-Ingenieur für Mechatronik, seiner Tätigkeit als Software- und Systemingenieur in der Automobilindustrie und seiner späteren Selbstständigkeit. Über viele Jahre hinweg hat er als Troubleshooter internationale und komplexe Entwicklungsprojekte stabilisiert und zum Erfolg geführt.

Im Zentrum des Gesprächs steht die Frage nach der Dualität von Projekt und Prozess. Für Maik Pfingsten ist ein Prozess kondensiertes Lösungswissen eines Unternehmens. Er bündelt Erfahrungen, Methoden, Checklisten und Vorgehensweisen, die über Jahre entstanden sind, um zuverlässig gute Ergebnisse zu erzielen. Projekte hingegen haben einen klaren Anfang und ein klares Ende. Die Herausforderung besteht darin, den Standardprozess bewusst auf das jeweilige Projekt anzupassen. Dieses sogenannte Tailoring werde jedoch häufig vernachlässigt. Entweder werde der Prozess aus Zeitdruck ignoriert oder unreflektiert vollständig angewendet. Beides führe zu Problemen.

Ein weiterer zentraler Punkt ist die Frage nach dem tatsächlichen Nutzen eines Produkts. Maik Pfingsten betont, dass Entwicklungsprojekte nicht nur interne Auftraggeber wie Produktmanagement oder Fertigung berücksichtigen dürfen, sondern vor allem den späteren Anwender. Anhand von Beispielen aus der Automobilindustrie, etwa Einparkhilfen, zeigt er, wie wichtig es ist, den Kernnutzen aus Sicht des Endnutzers zu verstehen. Ein technisch hochentwickeltes System kann überfordern, wenn es nicht zum Nutzer passt. Der Nutzen entscheidet letztlich darüber, ob ein Produkt erfolgreich ist.

Götz Müller greift die Unterscheidung zwischen Lastenheft und Pflichtenheft auf. Maik Pfingsten erläutert klar: Das Lastenheft beschreibt die technischen Anforderungen an das zu entwickelnde System, während Projektanforderungen wie Budget, Termine oder Meilensteine separat dokumentiert werden müssen. Anforderungen, die nach Projektabschluss weiterhin relevant sind, gehören ins Lastenheft. Anforderungen, die nur während des Projekts Bedeutung haben, sind Projektanforderungen. Diese Differenzierung werde häufig vermischt, was zu Missverständnissen und Konflikten führe.

Besonders kritisch wird es, wenn zwischen verschiedenen Unternehmen gearbeitet wird. Dann sind Lasten- und Pflichtenheft nicht nur technische Dokumente, sondern auch Teil der vertraglichen Grundlage. Maik Pfingsten schildert ein Beispiel aus dem Maschinenbau, bei dem erst durch ein klar formuliertes Lastenheft eine belastbare Ausschreibung für eine millionenschwere Investition möglich wurde.

Neben unklaren Anforderungen identifiziert Maik Pfingsten Kommunikation als häufige Fehlerquelle. Insbesondere in internationalen Projekten werde die Bedeutung interkultureller Unterschiede unterschätzt. Doch auch innerhalb eines Landes sprechen unterschiedliche Disziplinen oft verschiedene „Sprachen“. Software-, Hardware- und Konstruktionsteams verbinden mit denselben Begriffen unterschiedliche Vorstellungen. Hier sei intensive Kommunikation erforderlich. Maik Pfingsten beschreibt die Rolle von Systemingenieuren als Informationsvermittler, die für ein gemeinsames Verständnis sorgen.

Götz Müller ergänzt, dass Reden zwar Zeit koste, aber unverzichtbar sei. Viele Probleme ließen sich auf Missverständnisse oder unzureichende Abstimmung zurückführen. Gleichzeitig müsse der richtige Zeitpunkt gefunden werden, vom Diskutieren ins Handeln zu kommen. Erkenntnis entstehe häufig erst durch konkrete Umsetzung und auch durch Fehler. Eine konstruktive Fehlerkultur sei daher essenziell.

Im Zusammenhang mit Lastenheften weist Maik Pfingsten auf verbreitete Ängste hin. Viele fürchten, Anforderungen würden in Stein gemeißelt. Tatsächlich seien Lastenhefte Momentaufnahmen nach bestem Wissen. Sie müssten weiterentwickelt werden. Entscheidend sei, dass gewonnene Erkenntnisse in die Organisation zurückfließen und nicht mit einzelnen Mitarbeitern verloren gehen. Hier sieht Maik Pfingsten eine wichtige Rolle bei Entwicklungsqualitätsingenieuren. Sie sammeln Erfahrungen aus Projekten und integrieren sie in die Unternehmensprozesse.

Zum Abschluss wechselt das Gespräch auf das Thema Prozesse im eigenen Business. Maik Pfingsten erläutert, dass auch als Solopreneur klare, dokumentierte Prozesse entscheidend sind. Er beschreibt sein strukturiertes Vorgehen bei der Erstellung von Lastenheften innerhalb von zwei Wochen. Diese Klarheit gebe Kunden Sicherheit und ermögliche kontinuierliche Verbesserung. Durch Standardisierung könne er seine Leistung weiterentwickeln, etwa durch virtuelle Workshops.

Seine zentrale Botschaft lautet: Prozesse sind unverzichtbar, unabhängig von Unternehmensgröße oder Rolle. Wer das vorhandene Prozesswissen ignoriert, riskiert teure Fehler. Bewusste Dokumentation, Reflexion und Anpassung von Prozessen erhöhen die Erfolgswahrscheinlichkeit erheblich. Götz Müller unterstreicht abschließend, wie wertvoll es ist, sich bei Bedarf erfahrene Spezialisten an die Seite zu holen.

Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

Hinweis: Ich behalte mir vor, Kommentare zu löschen, die beleidigend sind oder nicht zum Thema gehören.