Schlagworte: Anforderungen, Projekte, Bedeutung, klar definierter, Systemabgrenzung, regelmäßige Kommunikation, Stakeholder, Qualität, Qualitätsmanagement

In dieser Folge sprechen wir über die Bedeutung von Anforderungen in Projekten. Wir betonen die Wichtigkeit klar definierter Anforderungen, klare Systemabgrenzung und regelmäßige Kommunikation mit Stakeholdern. Qualität und Qualitätsmanagement sind ebenfalls entscheidend. 

Transcript

Fabian:
[0:01] Moin Fabian! Sali, Melvin! 

Mel:
[0:02] Management by Projects, Ausgabe Nummer 28, nein nicht 28, 18. Das ist einfach zu warm. 

Unregelmäßige Aufnahmen aufgrund von Sommermonaten

[0:09] Im Moment. Ihr merkt es auch, wir haben es in letzter Zeit nicht geschafft, so regelmäßig aufzunehmen, wie wir das wollten. 
Wir hatten zwar in der letzten Folge schon Besserungen gelobt, aber müssen dann noch ein bisschen weiter an uns arbeiten. Wir werden das probieren, auch über die heißen Sommermonate hier regelmäßig Kontext zu produzieren. 
Seht uns das nach, dass wir da in letzter Zeit etwas geschludert haben. 
Thema für heute, was wir uns überlegt haben, aus so ein bisschen aktuellem Anlass bei uns ist das Thema Anforderungen. 

[0:39] Ihr kennt das sicherlich alle Anforderungen im Großen und Kleinen. 
Wenn wir über Projekte sprechen, dann ist es natürlich die erste Ebene. 
Erstmal die Frage, was wäre eigentlich mein Stakeholder von mir? 
Aber dann natürlich auch nachher, je nachdem, was das für eine Art von Projekt ist, die Frage, was ist eigentlich mein Entwicklungsgegenstand? 
Wie beschreibe ich den? Was sind die Themen, die ich nachher da irgendwie herstellen soll, die ich beschaffen soll? 
Und es ist deshalb aktueller Anlass. Wir hatten bei uns im Projekt in den letzten Wochen immer wieder Diskussionen auch über die Frage Wie formuliert man gute Anforderungen? 
Wie kriege ich eigentlich sichergestellt, dass das, was ich da beschreibe, was mein Projektziel nachher tun kann, eigentlich in sich schlüssig ist und keine Widersprüche hat? 
Und da dachten wir, das lohnt sich hier in der Runde auch mal diese Diskussion weiterzuführen und da das eine oder andere Lessons learned von unserer Seite mit euch zu teilen. 

[1:35] Die erste Frage, um das Gespräch locker zu eröffnen. 

Diskussion über Anforderungen ohne Vision führen

[1:40] Fabian, du als Fan von Anforderungsschreiben ohne eine Vision zu haben, wie gehen wir das Thema an? 

Fabian:
[1:48] Ja, also mir gefällt das Thema extrem. 
Ich meine, wenn man nur über Requirements Engineering oder Anforderungen als Definition spricht, dann, ich weiss nicht, wir haben es glaube ich noch nicht gesagt, was für Projekte wir gerade machen, aber man merkt dann ja, man ist eher in einem Ingenieur-Kontext unterwegs, oder? 
Aber ich würde da gleich mal zu Beginn die Brücke machen und sagen, das machen wir ja fast bei jedem Thema, oder? 
Das ist das Wichtigste und das ist übergreifend und überhaupt und das ist hier auch der Fall, wenn man eben das interpretiert als die Kernfrage. 

Unterschiedliche Herangehensweise bei neuen Projekten und bestehenden Systemen

[2:36] Im Agilen spricht man dann von Product Ownership und die Kernfrage ist, wenn man mit Projekten zu tun hat, geht es ja meistens darum, etwas Neues zu machen, etwas zu verändern und deshalb braucht es das Projekt, die Anforderungen nicht klar zu beginnen, sei das ich mache ein Marketingprojekt, wo ich ein neues Produkt mache, dann muss ich da alle Anforderungen in dem Sinne herausfinden, das ist dann vielleicht ein bisschen ein anderer Hergang, wie wenn ich schon an einem anderen Punkt stehe und ein konkretes System erstellen will. 
Man kann aber auch sagen, ich habe das auch in einem kulturellen Projekt, in einem HAAR-Projekt ist es genauso. 
Es ist immer die Schlüsselfrage, wohin muss ich dann wirklich? 

Die Bedeutung einer Vision in unserer Arbeit

[3:29] Und ich erlebe, du hast es vorhin erwähnt, ohne Vision. Ich habe wirklich etwas, was ich seit Jahren mache und auch. 

Vom Großen ins Kleine denken für effektives Handeln

[3:40] Es gibt verschiedene Benennungen von dieser Problemstellung, aber ich bin ein großer Anhänger davon, immer vom Großen ins Kleine zu denken, weil ich der Überzeugung bin oder die Erfahrung habe, dass so die menschliche Psychologie funktioniert. 
Es ist extrem schwierig, aus dem Kleinen ins Große zu denken. Was ist das Gesamtziel? 
Wohin wollen wir wirklich? hilft sie in der Regel immer dann auch in den Details dann die richtigen Dinge zu tun. 
Und das ist für mich auch so bei der Anforderungsdiskussion für ein Industriesystem. 
Genauso natürlich, wenn ich eine Marketingfrage habe oder irgendeine andere Frage, wenn ich nicht genug über die Gesamtausrichtung nachgedacht habe, kann es schwieriger werden. 
Ja, das sind so meine, sagen wir mal, überfliegenden Gedanken zu dem. 
Für mich ist das auch im Kern, zum Beispiel bei der Geschäftsmodellentwicklung, also so wirklich im unternehmerischen, das ist Problem-Solution-Fit, oder? 
Also, da musst du sagen, löse ich wirklich ein Problem? Das ist die erste Fragestellung, oder? 
Und wenn ich sage, hey, ich habe schon eine Lösung XY, jetzt suche ich mir noch irgendein Problem, das ich lösen kann, vielleicht mit dieser Lösung ist meistens ein bisschen ein steiniger Weg. Auch da ist es so ein bisschen wiedererkennbar. 

[5:08] Hast du da auch so viel Resonanz mit dem, oder wie bist du da geprägt? 

Mel:
[5:13] Ja, was ich einfach immer wieder beobachtet habe, und ich meine, wir ranten hier ja immer so ein bisschen gegen agiles Projektmanagement, aber was so wirklich das ist, was ich sagen würde, das habe ich wirklich vom agilen Vorgehen gelernt, ist, es lässt sich nicht beliebig viele Prozessschritte parallelisieren. 
Und es gibt einfach Prozessschritte, die musst du sequentiell abarbeiten. 
Gerade beim Thema Requirements Engineering, beim Thema Anforderungsmanagement, finde ich, merkt man das einfach sehr, sehr gut, weil wahrscheinlich hat jeder, der schon mal ein Projekt gemacht hat, die Erfahrung gemacht. 
Man fängt viel zu früh an, technische Dinge zu spezifizieren und mit technisch meine ich jetzt quasi nicht irgendwie Bit und Byte und Hardware Software, sondern quasi Lösungen konkreterer Natur zu beschreiben und hat aber den kompletten Überbau nicht. 
Und es gibt halt eher einfach deshalb diese Anforderungspyramide, die aus drei Ebenen besteht und ganz oben steht die Vision, dann kommen Geschäftsanforderungen, also wirklich Business Requirements und erst dann kommen die Lösungsanforderungen. 
Und ich glaube, man muss sich da wirklich bewusst bleiben und auch selbst immer wieder hart reflektieren, bin ich mit der übergeordneten Ebene bereits fertig? 
Also kenne ich meine Vision tatsächlich schon so? Habe ich die ausreichend verstanden? 
Habe ich dann verstanden, welche Businessanforderungen in dem Kontext erfüllt werden müssen, bevor ich anfangen kann, in technische Lösungsdesigns anzusteigen. 

Herausforderungen bei Lösungsdesign ohne Verständnis der Business-Anforderungen

[6:36] Und ich meine, du kennst das sicherlich auch, gerade wenn man so im ingenieurlastigen Umfeld unterwegs ist, dann hat man natürlich sehr schnell auch ein Zielbild einfach im Kopf, wo man sagt, so und so würde ich das machen, weil ich bin ja immer der Oberingenieur und das weiß sowieso keiner so gut wie ich. 
Und was sollen wir hier quasi noch groß analysieren und Konzept schreiben und so weiter. 
Und in meiner Erfahrung rächt sich das immer, zu früh ins wirklich Lösungsdesign einzusteigen, ohne verstanden zu haben, was ist jetzt wirklich das… 

[7:07] Also mir gefällt dieser Begriff, was sind die Business-Anforderungen aus der Vision heraus? 
Weil natürlich kann ich irgendwie sagen, ich möchte ein neues Produkt erstellen, um jetzt wieder ein technisches Beispiel zu machen, oder nehmen wir vielleicht mal was nicht technisches. 
Irgendwie, keine Ahnung, ich will, ich mache ein Projekt, was irgendwie die Vision hat, dass wir innerhalb von zwei Monaten jede verkannte Stelle besetzen können. Also das ist reines Business-Projekt jetzt. 
Und dann ist halt tatsächlich die Frage so, was sind denn jetzt eigentlich die Business-Anforderungen daraus? 
Und dann kommt vielleicht sowas wie, ja, okay, wir wollen das zwar, aber trotzdem darf uns jeder Rekrutierungsprozess nicht mehr kosten als den Betrag X. 
Oder wir wollen trotzdem sicherstellen, dass wir jetzt nicht einfach nur stumpf den Erstbesten einstellen, sondern irgendwie dennoch müssen die Mindestqualifikationen, die ein Bewerber hat, so und so hoch sein. 
Oder wir sagen, keine Ahnung, vielleicht weil wir diese KPI jetzt ausrufen und dieses Projekt machen, weil wir ein Fluktuationsproblem haben, dann möchte ich die Leute nicht einfach nur einstellen und nach zwei Wochen sind sie wieder weg. 

Bedeutung der konkreten Needs des Businesses für erfolgreiche Umsetzung

[8:08] Und das ist glaube ich wirklich wichtig, sich nochmal die Frage zu stellen, so okay, Vision schön und gut, ist schon schwer genug, die überhaupt mal über einen Zoo von Stakeholdern glatt zu ziehen, aber dann im nächsten Schritt zu, und was will ich denn dann eigentlich damit? 
Was sind jetzt konkret die Needs des Businesses und irgendwie, dass ich dann, ob ich jetzt einen Headhunter in dem Beispiel anstelle, ob ich Active Sourcing mache, Passive Sourcing, irgendwie ein cooles Image-Video oder eine Personalkampagne, das ist völlig zweitrangig, solange ich quasi nicht weiß, was ist denn jetzt eigentlich das, was das Geschäft wirklich braucht, um funktionieren zu können. 
Und gerade diese Zwischenebenen, also Visionen sieht man noch relativ häufig. 
Das gibt es ja auch so mit Geschäftsstrategie und daraus abgeleitet. 
Haben wir auch eine Folge gemacht zu dem Thema strategischer Fit von Projekten. 
Das ist, glaube ich, mittlerweile relativ gut verstanden. Aber dass es noch diese Zwischenebene der Geschäftsanforderungen gibt und dass das in meiner Beobachtung auch ein Thema ist, wo sich das Management gerne drum drückt, das wird da, glaube ich, oft vergessen. 

Fabian:
[9:11] Ja, ich glaube, es ist tatsächlich genau, wie du sagst, auch etwas, was schwierig ist oder, Oder eben etwas, was oft zwischen Stuhl und Bank, im wahrsten Sinne des Wortes, verloren geht, weil es um Übersetzungsleistung geht. 
Und ich habe auch schon mal ein bisschen bösartig gesagt, Requirements Engineering, das ist da, wo die Ingenieure Deutsch lernen. 
Es geht eben um Sprache, und Sprache ist nicht eindeutig. Also, sie ist per Definition im Fluss. 
Ich meine, Bücher, die vor 1’000 Jahren geschrieben wurden, werden heute auf jeden Fall nicht verstanden. 
Und du kannst solche Bewegungen schon in der kürzesten Zeit haben. 
Du musst dann zuerst fünf Jahre studieren, bevor du das Buch halbwegs verstehst. 
Und ich glaube, diese Übersetzungschallenge hat damit zu tun. 
Schon nur mal im Sprachlichen. 
Das andere ist nachher dann wirklich zu verstehen, was ist das effektive Problem, das gelöst werden muss, um diese Vision zu erreichen. Das ist nicht trivial. 
Und ich glaube deshalb ist es auch etwas, was so schwierige Dinge… 

Der Weg des geringsten Widerstandes in Unternehmen

[10:39] Ich finde, gerade in grossen Unternehmen kannst du schon erleben, dass die Leute per Default eigentlich immer den Weg des geringsten Widerstandes suchen. 
Ich nenne das so, oder? Also, auch rationell, als Individuum, aber wenn du eben dann Visionen wirklich erreichen willst, ist es eigentlich sehr irrationell, weil meine Erfahrung ist, das geht nur, indem du genau diese Aufwände dann Schritt für Schritt durchführst und versuchst, genau zu verstehen, versuchst, zu iterieren und so weiter. 
Und ich Ich glaube, das ist genau das, was wirklich das agile Projektmanagement oder viele Methoden dort drumherum. 
Ich persönlich bin ja vor allem ein Fan von Lean Innovation, so in der Methodenecke, weil Es ist das Iterative und das… 
Ja, es ist schlussendlich auch Trial and Error, es ist keine neue Idee. 
Man hat das in so vielen Management-Prinzipien auch drin, das zyklische Denken. 
Aber ich glaube, das brauchst du eben genau dann, wenn diese Übersetzungsleistung gebraucht wird. Weil du musst immer wieder schauen, habe ich es wirklich richtig verstanden, war es wirklich so gemeint? 
Weil du hast eben mit anderen Systemen, anderen Personen usw. zu tun. 
Und da musst du iterieren und immer wieder prüfen, ob es wirklich stimmt, dass du es korrekt verstanden hast. 

System-Kontext und die Bedeutung von Schnittstellen

Mel:
[12:09] Ja, und da gilt dann natürlich auch oft ceteris paribus nicht. 
Also wenn wir uns das wirklich klassische Requirements Engineering angucken und was da in den Lehrbüchern steht, dann sprechen wir in der Regel immer von dem System, also diesem Ding, was wir jetzt irgendwie beschreiben. 
Und drumherum besteht ein System-Kontext, also mit geltende andere Dinge, so was wie Gesetze, so was wie andere Systeme, die aber nicht Gegenstand unseres Untersuchungsgegenstands sind und dann natürlich auch eine ganze Reihe von zum Beispiel Geschäftswahrheiten, Stakeholder etc. 
Und Dinge, die dann halt vielleicht auch für uns irrelevant sind. 
Aber all diese Themen, die jetzt nicht direkt zu unserem System gehören, die sind ja nicht statisch. 
Also wir versuchen natürlich als Projektleiter all diese Dinge irgendwie unter Kontrolle zu halten oder wenn wir an die Projektmanagementmethode PRINCE2 denken, PRINCE steht ja für Projects in Controlled Environment. 
Also da geht es ja wirklich genau darum, wie schaffe ich es, mein Umfeld so stabil zu halten für die Dauer meines Projektes, dass das geht. 
Und klar, je kleiner meine Innovationszyklen sind oder meine Realisierungszyklen vielmehr, desto einfacher, oder was heißt einfacher, desto besser geht es zumindest. 

[13:22] Einfach weil es sich in kürzerer Zeit weniger verändert als in langem. 
Aber wenn wir jetzt sagen, wir haben ein Projekt, was sagen wir mal größer ist als vier Jahre, also auch länger dauert als eine politische Legislaturperiode, Periode, dann habe ich einfach gute Chancen, dass mir in der Zeit auch irgendwie eine Gesetzesänderung oder eine Regulation um die Ohren fliegt, die dann einfach. 

[13:40] Sehr klare Einflüsse auf mein Projekt nehmen kann und was ich auch in dem Kontext beobachte ist, dass man oft vergisst, dass auch dieses System, also unser Objekt der Begierde, nicht klar umrissen ist, sondern es gibt ja auch da zwischen dem, was noch drum herum im Kontext irgendwie geht, das ist ja ein fließender Übergang, also die sogenannte Systemgrenze jetzt eben zum Kontext, die ist ja nicht schwarz-weiß, sondern dann gibt’s einfach Themen, nehmen wir das Beispiel Schnittstellen, bei dem ich dann mit jedem Einzelnen meiner Umsysteme wirklich verhandeln muss, was machst denn jetzt du und was muss ich machen? 
Und erst wenn ich all diese ganzen Kämpfe gefochten habe, bin ich wirklich in der Lage zu sagen, okay, das ist jetzt das, was meine Spielwiese ist und wofür ich verantwortlich bin und wofür ich nicht verantwortlich bin. 
Und vielleicht auch da, du kommst ja auch aus einem Bereich, wo man viel mit Partnern oder mit Dritten zusammenarbeitet, das ist ein Thema, ich muss zugeben, ich hab’s immer gehasst. 
Also gerade so Schnittstellen-Themen, ich habe ja im Bereich von datengetriebenen Geschäftsmodellen gearbeitet und wenn du dann an den Punkt kommst, wo du einem dritten Daten zur Verfügung stellen musst, also in dem Fall ging es beispielsweise darum, dass wir großen Telekommunikationsanbietern Mobilfunkdaten zur Verfügung gestellt haben, also wie gut ist die Ausleuchtung an bestimmten Stellen und dann fängst du auf einmal an, darüber zu sprechen, okay, in welcher Geschwindigkeit müssen diese Daten geliefert werden und wenn es dann aber nicht der Fall ist und du fängst da anzugucken, haben wir die jetzt nicht früh genug geschickt, oder habt ihr sie nicht schnell genug empfangen? 

[15:09] Oder irgendjemand macht irgendeinen Software-Update und auf einmal funktioniert so eine Schnittstelle nicht mehr und dann fängst du an zu suchen, wer ist denn jetzt daran schuld? 
Und da wirklich die notwendige Energie reinzustecken und zu klären, was ist jetzt mein Tanzbereich und was ist nicht mehr mein Tanzbereich? 
Da habe ich die Erfahrung gemacht, das ist sehr, sehr mühsam, aber es lohnt sich, diese Energie initial aufzubringen, weil es erspart einem hinten raus richtig viel Ärger. 

Fabian:
[15:33] Ja, ich muss da sagen, ich hatte da eine sehr frühe Sensibilisierung, einfach aufgrund meines Studiums. 
Ich habe ja mal Umweltnaturwissenschaften studiert. 
Und Umweltprobleme sind eigentlich fast alle komplex. Also du hast die Umwelt, die ist für sich vielleicht noch physikalisch kausal, aber da gibt es auch so Dinge wie Chaos, Schmetterlingseffekt und solche Spässe. 
Und nachher hast du in der Regel immer eine komplizierte Gemengelage von Interessen, die dazu führen, dass die Umweltprobleme eben entstehen und da hat es ganz am Anfang uns. 

[16:13] Ein Erfahrener oder jemand, der das studiert hat und da einige Erfahrungen schon hinter sich hatte, das war glaube ich sogar am ersten Studientag, hat er gesagt, eure Hauptrolle ist Übersetzer sein, oder? 
Also, eure Rolle ist in diesem komplexen System die verschiedenen Elemente genug gut zu verstehen, dass ihr herausfinden könnt, ja, also dass ihr zwischen den Systemen sozusagen vermitteln könnte. 
Ich funktioniere so, ich glaube an Dinge, bis sie widerlegt sind. 
Und dieses Argument habe ich bisher noch nie als widerlegt gefunden. 
Das geht über Umweltsysteme hinaus. 
Wenn immer du Menschen involviert hast – Menschen sind eigentlich die komplexesten Entitäten oder Phänomene, die es gibt – wird es komplex. 

[17:06] Deshalb habe ich immer immer den Reflex zu sagen, ja, ich muss zuerst ein Grundverständnis zu den wichtigsten Elementen – das können Stakeholder sein, das können technische Systeme sein – aber ich muss ein Grundverständnis haben als Projektleiter, sonst kann ich die Übersetzungsleistung nicht machen. 
Und etwas vom Teuersten und Dümmsten, was es gibt, sind Missverständnisse, oder? Also das ist einfach, wenn du das vermeiden kannst, glaube ich, hast du ziemlich viel gewonnen. 
Und ich meine, es ist die Disziplin, Requirements-Engineering oder eben Marketing ist für mich manchmal auch nichts anderes. 
Das ist einfach das Requirements-Engineering in Richtung Märkte und potenzielle Kunden. 
Die hat dann da ihre Versuche und ihre Methode, dem Herr zu werden. 
Aber die Grundproblematik, die ist, erst mal ist nicht immer diese Übersetzungsleistung machen zu können und und sich da genug, gut bewegen zu können, um die gröbsten Missverständnisse oder das Sand im Getriebe sozusagen zu minimieren. 

Schulung in Requirements Engineering als konstruktiver Beitrag

Mel:
[18:16] Jetzt haben wir viel über Probleme gesprochen und dass alles schwierig ist. 
Kommen wir mal wieder zum, was ist jetzt quasi unser konstruktiver Beitrag dazu. 
Und das Erste, was man glaube ich jetzt auch gerade aus den letzten zwei Wochen bei uns im Projekt mitnehmen kann oder was ich für mich echt mitgenommen habe, ist, wir haben jetzt die Leute bei uns, die tatsächlich eng oder an der Grenze zum Requirements Engineering Arbeiten mal zu einer Schulung geschlepft und haben quasi gesagt, ihr macht jetzt alle mal eine Zertifizierung in dem Thema und das würde ich für mich mitnehmen. 
Das mache ich, glaube ich, jetzt in jedem Projekt so. Also einfach mal so dieses, wir klären jetzt mal die Begrifflichkeiten. 

[18:51] Also so, was ist eigentlich jetzt wirklich eine Anforderung? 
Was ist jetzt wirklich ein System? 
Weil gerade System ist auch so ein Begriff, der wird so inflationär benutzt oder Schnittstelle, dass man tatsächlich, also ich glaube, ich schleife dir da jetzt wirklich über jedem Projekt, was ich mache, die Projektmitarbeitenden da mal hin oder setzt zumindest auch eine gewisse Standardisierung und Zertifizierung da voraus, weil ich doch jetzt auch für mich gelernt habe und ich habe jetzt auch in der Vergangenheit diverse Projekte gemacht mit Ausschreibungscharakter, mit Systemdesign und so weiter. 
Ich habe auch nie eine Schulung besucht, sondern es ist immer so Learning by doing, weil man hat nie Zeit und andere Dinge sind gerade wichtiger und eigentlich ist es als Projektmanager ja auch gar nicht meine Aufgabe, Anforderungen zu schreiben und so weiter, aber wirklich nochmal zu verstehen, was da der Ende-zu-Ende-Prozess ist, was die Werkzeuge da sind, was es da auch für Tools gibt, vielleicht auch Dinge, die man noch nie gesehen hat, also ich habe da auch echt viel Neues gelernt, ein Thema, wo ich echt sagen muss, das hat sich total bewährt und sei es nur um wirklich. 

[19:49] Auf der sprachlichen Ebene, du hast das eben schon mal angedeutet, ein einheitliches Glossar zu benutzen, also wirklich zu sagen, wenn ich Anforderungen sage, dann meine ich xy. 

[19:59] Wenn ich irgendwie, keine Ahnung, Satzschablone sage, dann meine ich dies und das. Wenn ich Kontext sage, dann verstehe ich darunter dies und jenes. 

Einheitliches Glossar zur klaren Kommunikation und Verständnis

[20:07] Ich glaube, das ist ja so der Kern einmal des Requirement Engineering, also wie kann ich Anforderungen so formulieren, dass ein Dritter, ein Lieferant oder ein Dienstleister tatsächlich auch so versteht, wie ich das wollte, aber ich glaube, man muss da wirklich bei sich selbst anfangen im Projekt und sagen, wir müssen uns erst mal auf eine Terminologie einigen, weil sonst spricht die linke Hand über was, was die rechte Hand nicht versteht und da, ja, weiß nicht, du warst ja mit in der Schulung, was war da dein Eindruck, ist das was, wo du es so aussagst, das wird seinem Aufwand auch gerecht, weil klar, jetzt wird der ein oder andere am Telefon sitzen und sagen, ah ja, die Schweizer, die schwimmen ja auch in Geld und Inflation gibt’s bei denen nicht und Budgets sind alle riesig, das ist für die natürlich kein Problem. 
Aber so teuer ist es dann nicht. Und ich glaube tatsächlich, dass es den Aufwand, den du hinten raus in der Abklärung hast, locker wieder reinholt. 

Fabian:
[21:00] Nein, das ist selbstverständlich. Und ich habe immer gute Erfahrungen damit gemacht, wenn Leute eben… 
Also Methoden sind nur so gut, wie du sie eben anwendest. 
Also das ist so ein generelles Thema, das ich immer mal wieder vermisse. 
Oder kannst du irgendein Thema nehmen. 

Bedeutung von Kompetenz in der Arbeitswelt

[21:26] Eigentlich in der Schule wird dauernd gemessen, wie kompetent du eigentlich wirklich bist, oder? 
Und manchmal frage ich mich so ein bisschen im Arbeitsleben, wenn jemand einen Titel hat, wird schon fast angenommen, dass er die Kompetenz hat. 
Und es ist eben relevant, ob du die Kompetenz hast oder nicht. 
Und wenn du sie nicht hast, dann reicht es eben manchmal nicht. 
Und ja, wenn du in eine Situation kommst, wie wir jetzt auch, auch, wo du wirklich darauf angewiesen bist, dass die Grundzüge dieser Disziplin relativ gut verstanden werden und vor allem auch ein ähnliches Verständnis existiert, dann ist es einfach notwendig, das zu tun. 
Wir haben das ja auch vorher gut besprochen, dass das sinnvoll ist und ich habe da selber auch schon sehr gute Erfahrungen damit gemacht, solche Schulungen durchzuführen. 

[22:14] Und es ist tatsächlich so, manchmal ist es ein bisschen seltsam für die Leute, oder? weil sie schon fast das Gefühl haben, ich muss jetzt da noch mal in die Schule. 
Und ich sage, im beruflichen Kontext geht es eben auch darum, sich all diese Dinge bewusst zu machen. 
Auch wenn du das vielleicht schon zigmal angewendet hast und effektiv vielleicht sogar erfahrener bist als die Person, die dich schult. 
Es ist einfach manchmal gut, das wieder zu reflektieren. 
Wir kommen ja in fast jedem Podcast in letzter Zeit dazu. Du musst immer die Basics parat haben, sowohl in der persönlichen Kompetenz wie auch in der Kompetenz deines Projektes oder der involvierten Personen. 

[22:59] Die Basics müssen irgendwie vorhanden sein, und dann kannst du wirklich gut werden. Das ist Übung, oder? 

Übung und Basics als Erfolgsfaktoren im Beruf

[23:07] Das Älteste, was es gibt, Übung macht den Meister. 
Und manchmal einen Schritt zurück machen und überlegen, wie wäre es dann wirklich gemeint? Was sind eigentlich die Konventionen? Das ist extrem sinnvoll. 
Entsprechend ist das sicher etwas, was über das Thema Anforderungen hinaus man empfehlen kann. 
Also überleg dir, was sind so die Schlüsselfähigkeiten, man nennt sie auch Erfolgsfaktoren, die dieses Projekt braucht. 
Und wenn du Entwicklungsprojekte machst, dann ist es auf jeden Fall Anforderungen schreiben zu können oder definieren zu können zumindest. 

Mel:
[23:48] Ja, und was aus meiner Sicht auch immer so ein bisschen zu kurz kommt, ist das Thema auch Qualitätsmanagement. 
Das ist ja auch so ein ganz furchtbarer Begriff, Qualitätsmanagement, so was wie wir halt eben auch Projektmanagement kann irgendwie alles und jedes sein. 
Qualitätsmanagement hat dann noch den Nachteil, dass es quasi ISO 9001 gibt, die irgendwie sagt, wenn du sieben Dokumente lenken kannst, dann bist du irgendwie der Held. 
Und auch da ist ja wirklich die Frage, was kann ich eigentlich als Projektleitender tun, um dafür zu sorgen, dass mein Projekt qualitativ hochwertig arbeitet. 
Und Qualität bedeutet ja erstmal nur die Übereinstimmung von Eigenschaften mit den Erwartungen. 
Also irgendein Kunde hat irgendeine Erwartung und wenn ich diese Erwartung erfülle, dann habe ich eine hohe Qualität und wenn ich sie halt eben nicht oder nur teilweise erfülle, habe ich eben eine schlechtere Qualität. und. 

Unerwartete Erwartungen in Projekten

[24:37] Meistens ist es ja eben genau so, dass wir in Projekten nicht ausgesprochene Erwartungshaltungen haben. Also auch da wieder der Vergleich mit dem Requirements Engineering, da sind wir glaube ich als Domain relativ ähnlich. 
Auch da, die zentralen Anforderungen wird dir der Kunde ja nicht sagen, sondern er wird halt auch da sagen, hey, das habe ich jetzt irgendwie vorausgesetzt, ich wusste jetzt nicht, dass ich nochmal sagen muss, dass ein Auto vier Reifen haben muss. 
Und da wirklich sich auch zu überlegen, und das war auch einer der Gründe, weshalb ich gesagt habe, ich schleife uns da jetzt alle noch mal hin, ist, wenn jetzt wirklich die interne Revision oder wegen mir auch die externe vorbeikommt und uns tatsächlich fragt, wie stellst du denn eigentlich sicher, dass dein Ergebnis, dass du da irgendwie mit auch viel Geld produzierst, dass du den richtigen Wirkungsgrad hast, also dass das Geld, das du einsetzt, auch wirklich zu hohen Anteilen in den Projekterfolg fließt und eben nicht in unzählige Meeting-Marathons, in denen wir uns über Grundlagen unterhalten müssen, weil wir unterschiedliche Verständnisse haben, Dann ist das, glaube ich, auch nochmal eine echt wertvolle Übung, sich wirklich darüber Gedanken zu machen, wie kann ich sicherstellen, dass diese ganzen nicht ausgesprochenen Erwartungshaltungen, und damit sind wir nämlich eben wieder beim Thema Standards und Basics, dass ich die tatsächlich abholen kann. 
Und das schaffe ich wirklich nur, wenn ich über ein Projektteam verfüge, dass ich dessen bewusst ist, dass ich weiß, dass selbst, wenn ich irgendwie ein Jahr lang jeden Tag mit meinen Stakeholdern Kaffee trinken gehe, sie werden mir nie alles sagen, was sie von mir haben wollen. 

[26:03] Aber da wirklich vorzusorgen und zu sagen, wir haben wirklich das Beste gemacht, was wir irgendwie konnten, ist, glaube ich, auch nochmal so eine Überlegung. 
Also ich habe sie in so Projektmanagement-Lehrbüchern noch nie gesehen und Qualitätsmanagement Das ist ein Thema, was… 
In Projekten auch in Summe noch verbesserungswürdig ist, um es mal so auszudrücken. 

Projektleitung und fehlendes Qualitätsmanagement

Fabian:
[26:23] Ja, du hast halt das Institutionalisierte in der Regel nicht so stark. 
Und du bist halt sehr individuell unterwegs mit Projekten. 
Und ich glaube, das ist da die Schwierigkeit. Und schlussendlich hilft dir natürlich da dann auch eine Schulung nur beschränkt. 
Also, Das ist sicher formell dann das, was dazu führt, dass eine Revision nicht mehr kritisieren kann, aber natürlich ein Erfolgsgarant ist es natürlich per se nicht. 
Ich glaube, dass du gesagt hast, geht schon ein bisschen in eine ähnliche Richtung, wie Was ich gleich sagen werde, ist, dass einerseits das Geniale am Projektleiter sein und andererseits wirklich auch das extreme Herausfordernde. 
Es gibt ja keine Themen, wo du dich einigstens endlich aus der Verantwortung nehmen kannst. 
Also, als ich Corporate Startups geleitet habe, habe ich immer gesagt, ob das Corporate ist oder Extern, egal was für einen Titel ihr mir gebt oder ich mir selber, es fühlt sich an, als wäre ich CEO. 

Mel:
[27:43] Nur bei den Finanzen kann es sich rausziehen. Genau. 

Fabian:
[27:47] Wenn es nicht funktioniert, dann bin ich irgendwie Schuld. auch wenn ich mich vielleicht gar nicht schuld fühle. 
Und ich glaube, das Qualitätsmanagement ist ja dann nur ein Begriff dafür, hast du wirklich alles Relevante gesehen, das zum Erfolg führt oder eben nicht, oder? 
Und diese Herausforderung bleibt und bleibt auch ein bisschen auf dem Projekt leider. 
Da gibt es sicher, ich hoffe es, da gibt es sicher Leute, die sagen, Nein, ich habe einfach einen Auftrag, den führe ich aus und ich tue genau das, was da drinsteht. 
Und das ist meine Verantwortung. Ich glaube, diese Ebene stimmt auch. 
Es gibt wie die zwei Ebenen. Also das eine ist, was hat in der Realität wirklich dazu geführt, dass ein Projekt erfolgreich war oder nicht? Und manchmal hast du auch unlösbare Situationen. 
Aber gleichzeitig gibt es auch die Ebene, dass du es schlussendlich gesehen hast oder nicht gesehen hast. Das ist die Kunst. 

Managementtheorie als Hintergrundwissen

[28:56] Das passt hier vielleicht noch rein, ich habe ja mal Managementtheorie studiert. 
Ich habe zwar eine naturwissenschaftliche Ausbildung, aber zum Schluss habe ich Managementtheorie studiert, dann richtig so eine Management-Theorie, Professur und so weiter und da hat immer alle die Haltung. 
Ja, wenn du als Unternehmen erfolgreich sein willst, das bringt alles gar nichts. 
Ich mache das einfach, weil ich den Titel brauche und ich fand das immer, es fand das einerseits extrem unbefriedigend, weil es wäre ja viel cooler, wenn du es lernen könntest, wenn es den Trick gäbe zur erfolgreichen Unternehmensführung. 

Der Balanceakt zwischen Methode und Erfahrung

[29:36] Und ich glaube, da gibt es auch viel, was du lernen kannst. Es kann alles relevant sein, aber gleichzeitig stimmt es eben doch. 
Ich glaube auch für den Projektleiter. 
Ja, es gilt dann auch im Moment. Hast du im Moment X gesehen und nicht gesehen, und bist du dauernd im Clinch zwischen «Muss ich jetzt noch eine Methode einwenden, einen Aufwand betreiben, um das Richtige zu tun?» Oder «Sehe ich es einfach und tue es?», Das ist ja so, dass das Bild vom, oder ein Bild des CEOs ist, der weiss es einfach, oder jetzt weiss er, jetzt muss ich einfach da links gehen. 
Das ist ja dann mehr wie, das ist ja dann komplexer, wie so er es weiss. 
Aber ich habe das Gefühl, der Balanceakt ist so, wie viel versuche ich methodisch, systematisch, diszipliniert zum richtigen Schluss zu kommen und wie viel mache ich es aus Erfahrung, aus gesundem Menschenverstand und aus einer Portion Glück und Zufall. 
Ich mag beide Wörter nur mässig, aber ich benutze sie trotzdem. 
Ich sehe dieses Thema auch bei diesem Thema Enabling. 
Du kannst so und so weit enablen, aber an einem Punkt ist es dann eben auch von meinem momentan geschickt, dann abhängig. 

Stolpern über nicht vorhandene Basics führt zum Scheitern

Mel:
[31:04] Ja, grundsätzlich ist es schon so, aber wenn du mich fragst, woran scheitern Projekte oder Vorhaben oder you name it, dann ist es in meiner Beobachtung irgendwie in 90% der Fälle stolpern über nicht vorhandene Basics. 
Und beim Thema Requirements Engineering hast du ja zum Beispiel dieses Thema Validierung, also Überprüfung, ob die Anforderungen, die ich da jetzt aufgenommen habe, die ich formuliert habe, aber auch tatsächlich dementsprechend, was der Auftraggeber und die Stakeholder da haben wollen. 
Und ich finde das zum Beispiel einen total charmanten Gedanken, den man sich auch als Projektleiter immer aware sein muss. 
Und so ist es ja mit allem anderen. 
Also irgendwann kommt quasi diese Überprüfung, ob das, was du machst, das ist, was auch bestellt wird. 
Und das ist in meiner Beobachtung immer der Moment, wo sich dann die Spreu vom Weizen trennt. 
Bist du quasi auftragskonform unterwegs oder machst du irgendwas, was irgendwie ganz entfernt in die Richtung gehen könnte, aber nicht der explizite Wunsch dessen ist, wofür du mal beauftragt worden bist? 

Fabian:
[32:18] Ja, das ist ein extrem guter Punkt und vor allem auch für die Awareness, welche Validierungszyklen habe ich in dem Projekt, wo ich unterwegs bin? 
Also, auf was ich hinaus will, wenn du ein kundenorientiertes Produkt machst, das du morgen testen kannst, hast du morgen eine echte Validierung. 
Wenn du ein Industrieprojekt machst, wo du in fünf Jahren entwickelst, Im sechsten Jahr eine Ersterprobung machst, eine teure, hast du wieder eine andere Herausforderung. 
Ich glaube, das bedingt dann auch ein bisschen die Methodenwahl, wo du dich da bewegst in dieser Spannweite. 
Wie schnell kann ich eigentlich validieren selber? Wie schnell kann ich selber eine Validierung auslösen? 
Was sind, ich nenne sie mal, meine Validierungsmomente, Agenten? 
Ich glaube, über das lohnt es sich, viel nachzudenken. Und manchmal kommen die dann auch aus einer Ecke, wo man es gar nicht erwartet. 

Mel:
[33:22] Ja, und wovor ich einfach auch warnen möchte, ist, ich habe einen Projektleiter-Kollegen, Grüße an der Stelle und große Bewunderung. Der hat es jetzt tatsächlich geschafft. 
Der war anderthalb Jahre nach Projektstart nicht einmal in seinem Lenkungsgremium. 
Und da muss ich sagen, auf der einen Seite Respekt dafür, dass du es hinbekommen hast und dass offensichtlich dein Lenkungsgremium auch nie gefragt hat, auch du mal vorbeikommen kannst und zu deinem Projektstart berichten. 
Auf der anderen Seite, ich halte das für brandgefährlich. Also würde ich persönlich nie machen. 
Ich gebe mindestens im zwei Monatszyklus zu Projektstart deutlich häufiger mindestens eine Infovorlage in meine Steuerungsgremien, um zu sagen, das ist das, wo wir unterwegs sind, einfach um das Schadensausmaß klein zu halten. 
Also das ist für mich auch eine Form von Validierung, einfach hinzugehen, das ist das, was wir verstanden haben, was ihr beauftragt habt. 
So und so gehen wir damit um. Das und das sind die nächsten Schritte. 
Und interveniert bitte jetzt, wenn wir falsch unterwegs sind. 
Und das ist, glaube ich, auch da so eine Sache, der man wirklich bewusst und aware bleiben muss. 
Holt diese Stakeholder permanent ab und validiert mit ihnen, ob das, was ihr an Anforderungen von ihnen umsetzt. In der Regel adressieren sie ja nur die Businessanforderungen beim Projektleitenden. 

Wichtigkeit der regelmäßigen Validierung im Projektmanagement

[34:38] Validiert permanent, ob ihr da noch richtig on track seid und gerade am Anfang des Projekts in der engeren Taktung hinten raus, das wird ja dann nach und nach stabiler, das kann man hinten raus, muss man das dann nicht mehr so eng fahren. 
Aber gerade am Anfang habe ich schon wirklich viele Projekte an die Wand fahren sehen, weil sie das nicht gemacht haben, weil sie zu früh gedacht haben, ja, ich habe schon verstanden, worum es geht und komme dann mit dem fertigen Ergebnis wieder und auf einmal war der Schaden da, das wird dann richtig teuer. 

Fabian:
[35:04] Ich glaube, das ist ein wirklich sehr gutes Schlusswort. 
Ich glaube, praktisch jede moderne Projektmanagement-Methode sagt dir, halt deine Validierungszyklen kurz, man sagt es mit anderen Worten, suche so schnell wie möglich einen Validierungsmoment. 
Ich glaube tatsächlich, das ist eine der Künste im Projektmanagement. 

Mel:
[35:29] Catching, da warst du wieder. 

Fabian:
[35:33] Genau, und in dem Sinne würde mich sehr interessieren, ob ihr die Zuhörer das ähnlich sehen und vielleicht gebt ihr uns da Feedback, ob ihr dem folgen konntet. 
Wäre auch spannend, Gegenthesen zu hören und wir würden in diesem Sinne schliessen und hören uns hoffentlich dieses Mal dann in zwei Wochen. 
Also wir saugen unsere Ferien ab, habe ich gerade bekannt gegeben, Merlin. 

Mel:
[36:00] Hast du Ferien in zwei Wochen? Ich nicht. 

Fabian:
[36:04] Okay, dann geht’s ja. 

Verbesserungen und Feedback erwünscht

Mel:
[36:07] Wir probieren das und geloben Besserung. Und genau, an der Stelle nochmal der Hinweis auf unser Forum für euer Feedback Management bei projects.com slash community. 
Lasst uns da gerne die ein oder andere Nachricht. an der Stelle auch noch mal der Hinweis auf unseren Newsletter für diejenigen von euch, die gerne, bevor sie die Folge hören, wissen, worum es geht. 
Einfach auf unserer Webseite registrieren, dann bekommt ihr bei Veröffentlichung der Folge einen Kurzüberblick. 
Vielleicht für den einen oder anderen auch ganz praktisch, auch wenn es unsere Hörerzahlen kannibalisiert, aber ja, Serviceleistung von unserer Seite. 
Ansonsten war’s das. Besten Dank, macht’s gut und bis in zwei Wochen, versprochen. 

Fabian:
[36:48] Schönen Abend. 

Mel:
[36:49] Ciao.