Planung vs Plan-Fiction: Warum dein PSP entscheidend ist

 Der Unterschied zwischen einem erfolgreichen Projekt und einem Fiasko liegt oft nicht im Team oder Budget, sondern in der Qualität der Planung. Statt "Plan-Fiction" aus Terminen, Tätigkeiten und vager Hoffnung brauchen wir einen strukturierten Projektstrukturplan (PSP), der uns Richtung gibt.

In dieser technischen, aber praxisnahen Episode tauchen wir tief in die Kunst des PSP ein. Du erfährst, warum "Timeline nur Tempo ist, PSP aber Richtung" und wie du vermeidest, dass dein Projekt schnell in die falsche Richtung rast. Wir klären die Grundprinzipien des PSP – von der 100%-Regel bis zum MACE-Prinzip für überschneidungsfreie, vollständige Planung.

Besonders wertvoll sind die konkreten Anleitungen zur Gestaltung von Arbeitspaketen. Mit sechs einfachen Elementen (Ergebnis, Abgrenzung, Akzeptanz, Annahmen, Risiken und Verantwortung) schaffst du Klarheit statt nur "schöne Gespräche". Wir identifizieren typische Planungsfehler und ihre Lösungen – etwa die "Goldilocks-Größe" für Arbeitspakete oder den richtigen Umgang mit Unklarheiten.

Auch für agile Teams ist der PSP wertvoll. Statt ihn als altmodisch abzutun, zeige ich dir, wie du ihn als Scope-Landkarte nutzt und elegant mit Product Backlogs verbindest. So verstehen Stakeholder die Richtung, während Teams das Tempo steuern – ohne Übersetzungsfehler.

Zum Abschluss gibt's eine praktische 10-Tage-Mini-Challenge, mit der du deinen PSP sofort verbessern kannst. Projektmanagement verbindet Methode mit Menschen – und der PSP bildet dafür das unverzichtbare Rückgrat. 

Mini-Glossar

• PSP – Projektstrukturplan: Hierarchie der Ergebnisse/Lieferobjekte eines Projekts.
• AP – Arbeitspaket: Kleinste plan- und steuerbare Einheit im PSP, mit Ergebnis, Akzeptanz und Owner.
• WBS – Work Breakdown Structure / WBS-Dictionary: Englische Begriffe für PSP bzw. die AP-Steckbriefe.
• MECE – Mutually Exclusive, Collectively Exhaustive: Überschneidungsfrei & vollständig – keine Doppelungen, keine Lücken.
• PBI – Product Backlog Item: Element im agilen Product Backlog (Scrum/Kanban).
• DoD – Definition of Done: Teamweit gültige Fertig-Definition für Backlog-Items.
• Scope Creep: Schleichende Umfangserweiterung ohne formale Steuerung.
• Change Request: Formeller Änderungsantrag, oft Symptom für PSP-Lücken.

Bist du interessiert an mehr Informationen zu erfolgreicher Projektarbeit? Hier findest Du mehr: https://www.einfachprojekte.de

Im Blog findest Du regelmäßig neue Beiträge, kompakt und auf den Punkt: 

https://www.1000freund.net/blog

Deine persönliche Projektleitungskompetenz ist das A und O. Teste Deine doch einfach mal hier:

https://www.1000freund.net/einfachprojekte/kompetenztest-projektleitung

Und wenn Du Fragen hast oder gerne mit mir ins Gespräch kommen magst, dann buche Dir jetzt einen Termin: https://calendly.com/1000freund/30min

Abonniere den Podcast. Lass gerne eine Bewertung da. Und sein einfach wieder mit dabei, wenn es bald wieder heißt: Einfach Projekte 

Transcript

 Speaker 1: 0:00

Hey, Hand aufs Herz, Wie oft planst du eigentlich ein Gefühl und nennst es dann Plan? Wenn die Planung nur aus Terminen, Tätigkeit und Hoffnung besteht, ist das kein Plan. Das ist Plan-Fiction. Heute räumen wir auf, denn ohne PSP, den Projekt-Struktur-Plan, bleibt Planung Zufall. Mit PSP wird sie steuerbar. Und ein kleiner Hinweis vorweg Das ist zur Abwechslung eine etwas technische Episode. Ich mache das absichtlich audiotauglich für dich. Du brauchst kein Bild und kannst trotzdem direkt was damit anfangen.

Speaker 2: 0:50

Wenn du magst, leg dir einen Stift bereit.

Speaker 1: 0:53

Herzlich willkommen bei Einfachprojekte. Mein Name ist Jörg Tausendfreund, und du kannst hier für deine Projektarbeit Strategien, ansätze und Tipps bekommen, vor allem immer im Klartext gesprochen und für dich, damit du direkt was damit anfangen kannst.

Speaker 2: 1:13

Sei einfach dabei.

Speaker 1: 1:22

Schön, dass du wieder mit dabei bist hier bei Einfach Projekte und einer etwas anderen Folge, mal ein kleines bisschen technischer, mal ein bisschen mehr nitty gritty. Einfachprojektarbeit, und warum dann ausgerechnet der PSP? Der PSP oder auch, wie du ja weißt, projektstrukturplan beantwortet nicht die Frage, wann machen wir das, sondern was liefern wir vollständig und ohne Doppelung. Und das ist das, was wichtig ist. Wenn du nämlich nicht weißt, um was es geht, wie willst du jemals vernünftig festlegen, wann das passieren soll? Er ist die Landkarte deiner Ergebnisse. Erst danach kommen Termine, ressourcen und Risiken.

Speaker 1: 2:14

Ohne PSP passiert Folgendes Du planst Tätigkeiten, verwechselst Aktivität mit Fortschritt und wunderst dich, warum der Meilenstein wackelt. Deswegen ist der Leitsatz des Tages sozusagen Timeline ist Tempo, psp ist Richtung. Tempo ohne Richtung führt schnell in den Abgrund, und da sollen Projekte natürlich auf gar keinen Fall landen. Ich glaube, da sind wir uns einig. Vielleicht sollten wir damit beginnen, was der PSP, also der Projektstrukturplan und ab jetzt sage ich nur noch PSP ist und was er nicht ist. Er ist im Prinzip vom Ergebnis her eine Hierarchie von oben nach unten, von Projektziel zu Teilergebnissen, zu Arbeitspaketen. Diese Teilergebnisse werden auch manchmal Teilprojekte genannt. Das kommt so ein kleines bisschen darauf an, wie auch die Nomenklatur bei dir und in deinen Projekten vorgesehen ist. Was sie nicht ist, ist eine To-Do-Liste, weil Tätigkeiten kommen später. Es gibt zwei Grundprinzipien, die wir beim PSP beachten sollten.

Speaker 1: 3:54

Das ist einmal die 100%-Regel, das heißt, die Summe aller Kinder umfasst 100% des Elternelements. Was meint das, nichts fehlt und nichts ist doppelt. Das ist ganz wichtig. Du brauchst also, damit das obere Element, das Elternelement sozusagen, also immer das, was oben drüber liegt, abgeschlossen werden kann. Muss alles das erfüllt sein, oder muss alles das da sein, was es eben einfach dazu braucht? Es darf nichts fehlen, und es darf auch nichts doppelt sein.

Speaker 1: 4:32

Dann gibt es noch das MACE als Grundprinzip, und das bedeutet Mutually Exclusive, collectively Ex, collectively exhaustive, das heißt überschneidungsfrei und vollständig, also keine grauen Zonen und keine Lücken. Was bedeutet, wir müssen, wenn wir es richtig machen wollen, und wir müssen, wenn wir es richtig machen wollen einfach gut schauen, dass wir nicht aufgrund von irgendwelchen Lachsplanen oder sonst irgendwas zu Unvollständigkeiten kommen, und die geplanten Elemente sollen sich nicht gegenseitig überschneiden. Warum ist das wichtig? Naja, jede Lücke, die wir heute einbauen, wird morgen zum Change Request, weil da eben eine Unklarheit drin liegt, und jede Überschneidung wird morgen zum Konflikt, weil wir aus ganz unterschiedlichen Gründen eben dann konkurrierende Perspektiven haben.

Speaker 1: 5:53

Was jetzt ganz wichtig ist, ist zu realisieren, dass es im PSP oder in der PSP-Planung zwei dominante Blickrichtungen auf den PSP gibt. Das eine ist die objektorientierte und das andere ist die funktionsorientierte Blickrichtung. Objektorientiert bedeutet was liefern wir? Also stell dir zum Beispiel eine Vitrine vor, in der fertige Dinge stehen Produkt, verpackung, onboarding, guide, training Das sind die fertigen Dinge, die sind in der Vitrine, die sind greifbar.

Speaker 1: 7:00

Vitrine, die sind greifbar. Vorteil ist, dass wir einen Ergebnisfokus haben, und die Stakeholder verstehen sofort, um was es geht. Du weißt, stakeholder abholen immer elementar, wenn die Lieferobjekte klar sind oder du den Scope sauber halten willst, also wenn du die Zielsetzung sauber halten willst, dass man sehr, sehr leicht Querschnittsthemen vergessen kann, wie zum Beispiel Sicherheit oder dagende Migration. Das Gegenmittel ist, dass du Querschnitte sozusagen als eigene Zweige planst. Also das ist so, dieses objektorientierte. Denk dran die Vitrine mit den fertigen Dingen. Das geht natürlich auch wieder auf jeder Ebene.

Speaker 1: 7:48

Die zweite Variante, die wir im PSP ansetzen können, habe ich schon gesagt, das ist die Funktionsorientierte. Das ist also, was tun wir Stelle hier vielleicht eher eine Werkstatt vor Konzeption, entwicklung, test, rollout. Vorteil passt gut zu internen Teams und Abteilungen, ermöglicht eine einfache Ressourcenzuordnung. Einsatz ganz häufig, wenn die Vorgehenslogik dominiert, zum Beispiel im Engineering, dann macht es Sinn. Das Risiko ist, du vermisst schnell Phasen mit Ergebnissen, und dann wird eben Fortschritt unsichtbar oder ungreifbar.

Speaker 1: 8:46

Das Gegenmittel, jedes Funktionselement muss ein greifbares Ergebnis am Ende haben. Testkonzept, testbericht, abnahmeprotokoll. Wichtig oder vielleicht hast du dich das auch gefragt gibt es da auch Mischgeschichten, mischformen? Ja, mischformen sind auch okay, aber eben mit Ansage. Das heißt, du darfst mischen, aber pro Ast bleibst du konsistent. Das heißt, ein Zweig objektorientiert, der nächste funktionsorientiert, aber nie innerhalb eines Zweiges hin und her springen, aber nie innerhalb eines Zweiges hin und her springen. So bleibt das MACE-Prinzip gewahrt. Vielleicht macht es sogar tatsächlich Sinn, dass du den Teil, wenn du da tiefer einsteigen möchtest, dir nochmal zu Gemüte führst.

Speaker 1: 9:57

Wichtig, um das jetzt erstmal festzuhalten wir entscheiden zwischen objektorientiert was liefern wir, also denk an das fertige Produkt und funktionsorientiert, was tun wir? eher die Perspektive, also was passiert in der Werkstatt, aber eben tatsächlich mit einem greifbaren Ergebnis am Schluss. Und Mischung ist okay, so. Jetzt kommt sozusagen der nächste Schritt, und das wäre das Arbeitspaket. Ein Arbeitspaket ist, wenn du so willst, immer auf die gleiche Art und Weise beschreibbar, und zwar also jetzt hier sozusagen audiotauglich mit den folgenden sechs Sätzen oder sechs Gedanken.

Speaker 1: 11:00

Ergebnis das heißt, dieses Arbeitspaket liefert, und dann kommt da also Punkt, punkt, liefert, punkt, punkt, punkt. Und dann kommt da irgendwie ein konkretes Ding oder ein Artefakt Abgrenzung ist auch ganz wichtig Drinnen sind Punkt, punkt, punkt und nicht drin sind, punkt, punkt, punkt. Da sind wir hier wieder beim Thema Überschneidungen mit anderen Dingen vermeiden. Das heißt, auf der einen Seite nochmal Ergebnis, auf der anderen Seite Abgrenzung des einen Arbeitspakets gegenüber aller anderen Arbeitspakete.

Speaker 1: 11:29

Dritter Punkt wäre dann Akzeptanz. Fertig ist es, wenn XYZ erreicht ist. Hier bietet es sich an, mit zwei bis vier überprüfbaren Kriterien zu arbeiten. Vorsicht, nicht irgendwie flapsig werden oder irgendwie lazy, also schon das Ganze sehr, sehr ordentlich durchgehen.

Speaker 1: 11:57

Vierter Punkt wären sowas ähnliches wie Annahmen. Also wir gehen davon aus, dass zum Beispiel die Daten vorliegen oder was auch immer. Das wäre das sozusagen. Man könnte auch sagen, was du brauchst, damit das Arbeitspaket funktionieren kann, damit das Arbeitspaket abgewickelt werden kann. Fünftens wären Risiken, die zu betrachten sind. Also zum Beispiel was wäre hier wieder dein Satz?

Speaker 1: 12:30

Knackpunkt könnte sein, zum Beispiel Schnittstellen, unklar oder ähnliches, und als Gegenmaßnahme planen wir XYZ. Und der sechste Punkt Verantwortung. Also Owner ist eine Person und ganz, ganz wichtig, nicht ein Team, eine Person oder, wenn es nach extern geht, eine Organisation, da dann auch wieder eine Person. Also, es sollte immer eine Person als verantwortlich benannt sein, sonst kommen wir irgendwie in diese komischen Geschichten, wo sich am Ende des Tages niemand zuständig fühlt, niemand zuständig fühlt.

Speaker 1: 13:13

Übrigens, wenn diese sechs Sätze also Ergebnis, abgrenzung, akzeptanz, annahmen, risiken und Verantwortung, wenn diese sechs Sätze klar sind, dann hast du 90% deines Work Breakdown Dictionaries, also WBS, schon geschafft, ganz ohne Stress. Folgender Merksatz könnte hier vielleicht helfen Ein Arbeitspaket ohne Ergebnis und Akzeptanz ist ein schönes Gespräch, aber kein Plan. Und das ist, glaube ich, einfach nochmal elementar. Alles, was wir bis jetzt besprochen haben, soll ja dazu dienen, zu Beginn des Projekts beziehungsweise dann in der Planungsphase dir nachher eine Grundlage zu schaffen, damit du später dein Projekt steuern kannst. Also die Frage ist ja auch warum planen wir?

Speaker 1: 14:18

Wir planen, damit wir später steuern können, oder was auch vielleicht das Ganze noch ein bisschen klarer macht wir planen, um feststellen zu können, dass wir nicht im Plan sind, weil es wird natürlich immer Abweichungen geben. Die Natur eines Projektes ist ja, dass wir häufig nicht alles erfassen können. Aber je genauer wir am Anfang nachdenken, desto weniger haben wir eben einfach die Change Requests. Es wird immer Changes geben, gar keine Frage. Und desto weniger Konflikte haben wir es wird immer Konflikte geben, keine Frage. Nur, je besser du in der Planungsphase arbeitest, desto weniger davon wird es geben. Und darum geht es, weil Konflikte und Change Requests halten dich halt einfach nachher nur wieder in der echten Arbeit auf.

Speaker 1: 15:06

Das bedeutet also, dass Fehler passieren. Fehler passieren allen. Und die Frage ist nicht passieren Fehler, sondern die Frage ist eher wie gehe ich mit Fehlern um? Und ich nenne dir jetzt mal ein paar exemplarische Fehler, einfach mal ganz kurz, und dann den Fix, wie du damit umgehen kannst. Und das werden so sechs Punkte sein, wie du damit umgehen kannst. Und also, das werden so sechs Punkte sein. Es gibt natürlich noch viel, viel mehr, aber ich ziehe jetzt einfach mal die raus, die sozusagen die relevantesten sein könnten, und wenn dir was fehlt, schreib mir, und dann schreibe ich dir entweder zurück, oder vielleicht gibt es ja nochmal so eine wunderschöne andere technische Folge Erster Fehler. Das passt im Prinzip auch schon. In unsere Logik ist es eben, phasen und Ergebnisse zu vermischen. Also im Prinzip steht dann Testen neben Verpackung. Also testen wäre die Phase, und das Ergebnis wäre im Prinzip Verpackung.

Speaker 2: 16:23

Was ist hier der Fix.

Speaker 1: 16:25

Die Phasen bekommen einen Ergebnisnamen. Also statt testen Testkonzept oder Testbericht Denkt wieder daran, dass wir eben zum Ende dieser funktionsorientierten Sichtweise, dass wir da eben auch ein Ergebnis stehen haben. Also Testen wird zu Testkonzept, zu Testbericht. Alternativ kann man auch Phasen in eine Roadmap sozusagen eintragen und die Ergebnisse in den PSP. Dann fühlt sich zwar auf der einen Seite so ein bisschen an wie so ein bisschen doppelte Buchführung, aber auf der anderen Seite kann es hochgradig Sinn machen, kommt auch so ein kleines bisschen drauf an, mit was dein Team besser umgehen kann. Der zweite Fehler oder das zweite Fehlerspektrum wäre eben, dass du Arbeitspakete ohne Output bezieh bzw Akzeptanzkriterien hast. Also was wäre so ein klassisches Symptom an der Stelle? Da steht dann Workshop, und das ist dann das Arbeitspaket. Dein Fix ist natürlich, dass aus Workshop zum Beispiel so etwas Ähnliches wird wie Entscheidungsvorlage X, abgestimmt, und dann Akzeptanz wäre dann Vorlage genehmigt von XYZ. Also natürlich kannst du Workshops auch im Projektstrukturplan planen, aber dieser Workshop braucht dann natürlich einen Namen. Also nochmal Workshop, entscheidungsvorlage XY, abgestimmt. Und weil ein Workshop für sich allein uns natürlich auch noch nicht weiterbringt, wäre dann das Nächste, dass die Vorlage eben einfach von wer auch immer sie genehmigen soll, genehmigt ist. Eben einfach von wer auch immer sie genehmigen soll. Genehmigt ist Das Dritte. Das ist auch so ein ganz typisches. Das ist entweder zu grob oder zu fein. Also das Symptom für zu grob wäre eben Arbeitspakete dauern länger als 20 Tage, 20 Arbeitstage, was einfach echt mächtig groß ist für ein Arbeitspaket. Das ist auch total unvernünftig, das dann steuern zu können. Und ein Symptom für zu fein wäre im Prinzip, dass wir 200 Mini-Krümel-Arbeitspakete in unserem Plan haben. Da wirst du nicht fertig mit der Verwaltung der einzelnen Arbeitspakete. Denk dran, du brauchst ja tatsächlich auch immer Output, akzeptanz und alles, worüber wir davor schon gesprochen haben. Also, es geht darum, sozusagen und das ist dann auch schon der Fix so eine Goldilocks-Größe zu finden, also irgendwo zwischen 5 und 15 Arbeitstagen pro Arbeitspaket, und bis zur ersten Planungsschleife dann in dem Moment oder bis zur ersten Planungs-Ruhe-Schleife Danach einfach verfeinern, wenn nötig.

Speaker 1: 19:54

Der vierte Fehler der dürfte eigentlich gar kein Fehler sein für alle, die dieses Handwerk verstehen, aber leider kommt er immer wieder in der Planung vor unklare Verantwortung. Also Symptom wäre dann an der Stelle Team XY macht das ist natürlich vollkommener Quatsch Kann man direkt sagen, was der Fix ist Eine Person als Owner das Team unterstützt, und der Owner liefert. Aber das sind die ganzen klassischen Metriken, die ich dann da gehen kann, wie die VMI-Matrix oder die RACI-Matrix. Also, es geht eben einfach darum, dass in einem Projekt Verantwortungsunklarheiten eben einfach nicht stattfinden dürfen ist jetzt wieder so ein Wort nicht stattfinden sollten.

Speaker 1: 20:41

Fünfter Fehler auch im Prinzip total verwunderlich der PSP wird nicht gepflegt. Das heißt also symptomhaft, der Ist-Zustand weicht vom PSP ab, und keiner traut ihm mehr. Ich mache erst den Fix. Also, der Fix ist natürlich ein PSP-Pflegeritual, das heißt, 15 Minuten vor dem Weekly Steering Committee im Prinzip nur das Struktur-Delta betrachten und neu entstandene Arbeitspakete nachziehen. Was meine ich damit?

Speaker 1: 21:25

Es ist doch ganz klar, der Projektstrukturplan, so wie das Projekt, ist natürlich am Leben, und ein einmal erstellter Projektstrukturplan ist dann nicht abgeschlossen, sondern, es muss jedem eigentlich total klar sein, dass wir, weil wir ja was Neues machen ein Projekt ist ja was Neues dass wir neue Erkenntnisse generieren und dass wir darauf kommen, dass wir möglicherweise neue Arbeitspakete brauchen, die wir einpflegen müssen. Vielleicht brauchen wir auch aufgrund des Erkenntnisgewinns, den wir haben, bestimmte Arbeitspakete brauchen, die wir einpflegen müssen. Vielleicht brauchen wir auch aufgrund des Erkenntnisgewinns, den wir haben, bestimmte Arbeitspakete nicht. Das heißt, es geht immer darum, das Struktur-Delta aufzulösen, also Anpassungen an die Realität und neu entstandene Arbeitspakete dementsprechend in der Planung nachzuziehen, in der Planung nachzuziehen. Und der sechste Punkt ist eben sozusagen, dass Weißstellen nicht ins Risikoregister kommen. Das Symptom wäre hier klassisch der Satz das klären wir später Das ist natürlich auch irgendwie ganz komisch.

Speaker 1: 22:36

Das heißt, jede Weißstelle wird sofort als Risiko gelockt. Kann ja sein, dass wir bestimmte Sachen noch nicht wissen. Also denk wieder dran, Projekt ist ja was Neues, Kann ja sein, dass es. bestimmte weiße Stellen sollten sofort als Risiko identifiziert werden. Also sozusagen Ursache unklar, Auswirkungen X möglich. Wer ist wieder der Owner und was ist unser Prüftermin? dazu Projektplan muss nicht perfekt sein, aber wenn du was identifizierst, was noch unklar ist oder was man noch nicht genau weiß, dann gehört das ins Risikolog, weil genau das ist es. Es ist halt einfach ein Risiko. So jetzt gibt es noch so tolle andere Sachen Viele glauben ja, zum Beispiel, die sich so in agilen oder hybriden Welten bewegen. Da hörst du dann so Sätze wie wir sind agil, wir brauchen keinen PSP. Ich würde jetzt sagen, da bin ich nicht hundertprozentig mit einig, Du brauchst ihn gerade dann, und zwar eben vielleicht eher als Scope-Landkarte für die Stakeholder. Denk dran, die irrige Annahme ist, dass ein PSP fertig ist. Ein PSP darf wachsen, also wie sozusagen die Äste eines Baumes in den Himmel wachsen beziehungsweise die Wurzeln eines Baumes in den Boden, welche Analogie dir da auch immer besser gefällt. Das heißt also, das erste, an was wir da denken, ist Mapping. Also jeder PSP-Ast oberste Ebene wird zum ersten Epic im Produkt Backlog. Die Arbeitspakete darunter werden zu Features oder zu größeren Product Backlog Items, wie auch immer ihr das dann dementsprechend gestaltet. Also, du kannst die agile Vorgehensweise ganz wunderbar mit in deinen PSP mit rein mappen Denk an die Scrooge-Landkarte. Wichtig ist dann eben auch, die Akzeptanzkriterien zu synchronisieren. Also, Arbeitspaketakzeptanz wird zur Definition of Done je Item. Das heißt, wir haben gleiche Worte und gleiche Erwartungen. Die Definition of Done kann ich natürlich auch im klassischen Ansatz ganz wunderbar verwenden, weil vom Prinzip her geht es ja eben darum, dass wir unmissverständlich klar haben, wann etwas fertig ist oder wann es als fertig definiert werden darf. Etwas fertig ist oder wann es als fertig definiert werden darf. Änderungen führen nur über den PSP. Also neue Backlog-Wünsche erst mal fragen, welchem PSP-Ast gehört das. Sonst haben wir hier möglicherweise wieder den guten alten Scope Creep, Kommunikation. Im Steering zeigst du einfach den PSP-Fortschritt, welche Ergebnisse sind fertig? und in der Delivery zeigst du den Backlog-Fortschritt, Also ein bisschen Zielgruppen oder eben Stakeholder orientiert. Zwei Wochen, 15 Minuten PSP zu Backlog-Abgleich. Also stimmt die Landkarte noch mit den Straßen überein, könnte hier so die Perspektive sein, Und damit hast du das ganz wunderbar synchronisiert. Und das ist dann nicht irgendwie irgendwas Altes mit dem PSP, als was Altes mit dabei haben in unseren tollen agilen und hybriden Umgebungen, sondern Dinge, die eben einfach funktionieren, so zu begreifen, dass sie auch im agilen oder im hybriden für dich zur Hilfe werden. Es braucht eben einfach ein Stück weit so eine vernünftige und durchdachte Anpassung. Das Resultat ist nämlich, die Stakeholder sehen die Richtung, also den PSP, und die Teams steuern das Tempo über das Backlog, Und es gibt eben keine Übersetzungs und Verständnisfehler mehr. Und wenn wir da mal so ein bisschen sozusagen auch auf die KPI, also die Key Performance Indikatoren Ebene schauen, dann empfehle ich dir im Prinzip drei Kennzahlen, die du ohne ein Riesensystem pflegen kannst, Also sozusagen Prozentsatz der Arbeitspakete mit Akzeptanzkriterien. Also, das Ziel wäre entweder größer oder gleich 90% ab der ersten Planungsschleife. Das ist schon ziemlich ambitioniert, gebe ich zu, aber es führt eben dazu, dass wir klare Erwartungen haben und weniger dieses Nacharbeiten im weiteren Verlauf. Es sind ja Schulden, die du aufbaust, die du irgendwann mal planerisch wieder abarbeiten musst.

Speaker 1: 28:35

Zweite Kennzahl wäre Change Requests gegen Scope-Lücken. Hier sollte das Ziel einfach immer weiter reduzieren, über die Meilensteine hinweg. Die Wirkung wäre hier der PSP wird dichter, Diskussionen verlagern sich vor die Umsetzung. Also, Perspektive ist hier halt, dass wir weniger Unklarheit haben, Und je weiter wir im Projektverlauf kommen das ist ja so ein ganz typisches Ergebnis desto klarer wird uns natürlich auch, wo es hingeht und was es sein wird.

Speaker 1: 29:15

Jeder Schritt nach vorne bringt mehr Klarheit. Das heißt, wir schaffen es dann eben auch, diese Scope-Lücken, diese weißen Flecken, dementsprechend immer stärker auszugleichen, und reduzieren dann damit die Change Requests. Eine dritte Kennzahl könnte im Prinzip so etwas ähnliches wie eine Commitment zu Dann-Quote pro Meilenstein sein. Das Ziel wäre hier also entweder über oder um die 85% der zugesagten Arbeitspakete sind im Meilenstein oder sind zum Meilenstein, dann Dann entsprechend der jeweiligen Akzeptanzkriterien. Wirkung sind ehrliche Zusagen und weniger Kosmetik Ist auch ganz klar.

Speaker 1: 30:07

Man muss mal schauen, Manche Meilensteine können auch nur genommen werden, wenn tatsächlich 100% erfüllt sind. Aber die Realität vieler Projekte zeigt sich, dass auch wenn noch nicht alles, was zum Heilstein hätte passiert sein sollen, passiert ist, dass es trotzdem im Prinzip weitergehen kann. Und ja, wie gesagt, wenn es dann auch nicht so hart wird, dann gibt es eben weniger Rumgelüge und weniger Kosmetik an der Stelle, Und das reicht im Prinzip ja schon, um gut damit umzugehen. Was ich dir gerne anbieten möchte, wie so häufig, ist einfach mal so ein kurzes Inhalten und mal über drei Fragestellungen nachdenken.

Speaker 1: 30:54

Also erste Fragestellung wäre hier zum Beispiel welches Arbeitspaket in deinem aktuellen Plan hat kein messbares Ergebnis? Oder auch die zweite Frage wo hast du in deinem PSP Phasen und Ergebnisse vermischt und machst Fortschritt damit unsichtbar? Und die dritte Frage wäre welche Weißstelle erhöht heute dein Risiko und gehört eigentlich ins Risikoregister mit Besitzer und Prüftermin? Notiere dir mindestens eine Sache, die du heute schon änderst, Nur eine. Das reicht, um Momentum zu erzeugen. Und was ich dir anbieten möchte, das ist eine ganz kleine PSP Mini-Challenge in 10 Tagen sozusagen, Also ohne Schnick und Schnack.

Speaker 1: 32:02

Du brauchst im Prinzip nur deinen bestehenden Plan, Also sozusagen Tag 1. Oberste Zeile laut aussprechen und in Ergebnisse übersetzen, Also dein Ziel, dein oberstes Ziel laut aussprechen und in Ergebnisse übersetzen, Also dein Ziel, dein oberstes Ziel laut aussprechen und in Ergebnisse übersetzen. Zweiter Tag den ersten Ast objektorientiert sauber ziehen. Was liefern wir? ist hier die Frage. Dritter Tag Querschnittsaspekte als eigene Zweige ergänzen, also zum Beispiel Dinge wie Sicherheit, Migration, Schulung usw. Also Dinge, die vielleicht auch gerade im Moment weiße Flecken wären. Tag 4 wäre problematische Funktionswörter umbenennen, also testen in Testbericht abgenommen. Haben wir gerade vorhin drüber nachgedacht?

Speaker 1: 32:59

Tag 5 wäre für alle Arbeitspakete, die 6 Sätze aussprechen können, Natürlich gerne auch schriftlich niedergelegt, Also Ergebnis, Abgrenzung, Akzeptanz, Annahmen, Risiko und Owner, Annahmen, Risiko und Owner. Tag 6 wäre, deine Weißstellen zu identifizieren und sofort ins Risikoregister zu übernehmen. Tag 7 wäre, eine Akzeptanzkriterienquote zu messen. Wie gesagt, Zielbild wäre so gerne über oder mindestens gleich 90%. Tag 8 wäre, ein Backlog-Mapping zu erstellen. Also deine PSP-Äste werden zu Epics und deine Arbeitspakete werden dann eben zu Features.

Speaker 1: 33:55

Tag 9, der PSP Backlog-Abgleich als 15-Minuten-Ritual für unsere agilen und hybriden Freunde. Und der Tag 10, die Commitment-to-Done-Quote für den nächsten Meilenstein definieren. Ziel gerne über oder gleich 85%, Und das war nicht nur eine 10-Tages-Challenge, sondern das war natürlich auch so ein kleines bisschen die Zusammenfassung unserer Zusammenarbeit heute. Und wenn du magst, dann schreib mir vielleicht deine größten Ahas oder teile sie. Auf jeden Fall ist ein bisschen so eine andere Folge, ein bisschen eine technischere Folge. Aber sagen wir mal ganz ehrlich, wenn wir hier über einfach Projekte sprechen, dann geht es eben tatsächlich auch manchmal wirklich um die Basis, Alles andere, über was wir sonst so sprechen, über Führung, über Zusammenarbeit und und und. Und das braucht natürlich die Leitplanken einer guten Planung, Und wenn du die nicht hast, dann funktioniert sorry, eben auch alles andere nicht.

Speaker 1: 35:29

Projektmanagement ist deswegen so eine unglaublich schöne Art und Weise des Arbeitens, weil es eben beides verbindet. Es verbindet eine Methode, die Vorgehensweise des Projekts oder die Vorgehensweise in der Projektarbeit mit dem Menschen. Das haben wir ansonsten so klar und so greifbar wirklich nur ganz, ganz selten in Organisationen beziehungsweise auch so klar, Und deswegen lade ich dich einfach dazu ein, in beiden Feldern dich immer weiter zu entwickeln. Und für heute sage ich natürlich herzlichen Dank, dass du mit dabei warst, Und wie immer wünsche ich dir bis zum nächsten Mal allseits erfolgreiche Projekte. Vielen Dank, dass du heute mit dabei warst, und schalte einfach das nächste Mal wieder ein, wenn das heißt einfach Projekte.

Speaker 2: 36:31

Bis zum nächsten Mal.