# NUPP Sammlung von nahezu universellen Projektprinzipien [image] Dies ist eine herunterladbare Version des Online-Handbuchs (https://omimo.org/de/modules/nupp/), erstellt am 2026‑07‑02. Auf der Website finden Sie neuere Versionen. NUPP stammt von OMIMO (https://omimo.org/de/), einer Familie offener, minimalistischer Module. This manual can be used and distributed freely under the Creative Commons Attribution 4.0 International license. OMIMO wird von der Europäischen Union kofinanziert. Die geäußerten Ansichten und Meinungen sind jedoch ausschließlich die von OMIMO und spiegeln nicht notwendigerweise die der Europäischen Union oder von EPOS VZW wider. Weder die Europäische Union noch die Bewilligungsbehörde können dafür verantwortlich gemacht werden. Übersetzt von Michael Taube ## Einführung NUPP ist eine Sammlung von nahezu universellen Projektprinzipien, die wir in allen Projekten befolgen sollten, unabhängig von den Methoden und Ansätzen, die wir verwenden, um unseren Erfolg zu maximieren. Jede verfügbare Methoden und Ressource für die Durchführung von Projekten stützt sich auf einige dieser NUPs (nahezu universelle Grundsätze). Die folgenden Punkte müssen jedoch beachtet werden: - In der Regel werden nicht alle NUPs berücksichtigt. Allerdings wäre es für Praktiker hilfreich, alle NUPs zu berücksichtigen, anstatt nur eine Teilmenge. - Die zugrundeliegenden Prinzipien werden in den Ressourcen und Methoden meist nicht deutlich genug gemacht. Vielen Praktiker sind so sehr mit Details beschäftigt, dass sie die Prinzipien vergessen und dann Dinge tun, die nicht mit ihnen vereinbar sind. Der NUPP ist mit allen wichtigen Methoden, Systemen, Ressourcen und Frameworks wie PRINCE2^(®), PMBOK^(®) Guide, P3.express, PM², DSDM^(®), XP und Scrum kompatibel. Es kann jedoch vorkommen, dass es mit bestimmten Interpretationen dieser Systeme nicht kompatibel ist. Hier versucht NUPP, die Praktiker zu ermutigen, ihre Interpretationen zu überdenken. NUPP ist eine Sammlung folgender NUPs: - NUP1 — Ziehe Ergebnisse und Wahrheit der Zugehörigkeit zu Methoden vor - NUP2 — Erhalte und optimiere Energie und Ressourcen - NUP3 — Sei immer proaktiv - NUP4 — Denke daran, dass eine Kette nur so stark ist wie ihr schwächstes Glied - NUP5 — Tue nichts ohne einen klaren Zweck - NUP6 — Verwende wiederholbare Elemente ## NUP1 Ziehe Ergebnisse und Wahrheit der Zugehörigkeit zu Methoden vor [image] Wir alle haben eine natürliche Tendenz, zu Gruppen zu gehören, eine Tendenz, die oft über ihre Grundform hinausgeht; starke Zugehörigkeiten schafft, aber auch Probleme verursacht. Durch Zugehörigkeiten verlieren wir viel mehr, als wir gewinnen. Wir können professionellere und effektivere Experten werden, wenn wir unsere Identität und unsere Vorlieben nicht auf bestimmte Gruppen beschränken. ### Beispiel: Agile vs. Wasserfall Eine Gruppe von sehr enthusiastischen Menschen, die mutig genug waren, adaptive Entwicklungsansätze in der IT-Entwicklung auszuprobieren, als es noch üblich war, prädiktive Ansätze zu verwenden, schloss sich zusammen und nannte ihren Ansatz “Agile”. Dies war eine großartige Initiative, um die Auswahl der Projektmanagementmethode nicht auf das zu beschränken, was bisher “normal” erschien. Es gibt immer noch viele begeisterte und ergebnisorientierte Menschen in der Agile-Gemeinschaft, aber leider gibt es in dieser Gemeinschaft auch einige, die Agile zu einem Kult machen und alle Außenstehenden als Feinde betrachten. Dies verursacht auf verschiedene Weise Probleme, einschließlich der folgenden: - Es lässt dich nicht von jemandem außerhalb der Gruppe lernen. - Es hält Außenstehende davon ab, von dir zu lernen. - Es macht die Zugehörigkeit zur Gruppe wichtiger als den eigentlichen Zweck, was wiederum viele ihrer Mitglieder daran hindert, die wahre Bedeutung von Agilität zu lernen. Dieses Problem lässt sich erheblich verringern - wenn nicht gar beseitigen - wenn man - einerseits Agile (Agilität) nur als Etikett für einen Entwicklungsansatz verwendet und nicht als eine Gemeinschaft mit Mitgliedern und wenn - andererseits Menschen, die sich selbst als Schöpfer, Problemlöser und Führungspersönlichkeiten betrachten, Agile (Agilität) nur als eine der Möglichkeiten sehen, die ihnen zur Verfügung stehen und nicht als ihre Identität. Für echte Profis gibt es keinen Agile-Wasserfall-Krieg. ### Beispiel: PRINCE2^(®) vs. PMBOK^(®) Guide Es gibt viele Fachleute in der Gemeinschaft, die sich entweder mit PRINCE2^(®) oder dem PMBOK^(®) Guide identifizieren (in der Regel aufgrund ihres geografischen Standorts) und mit dem jeweils anderen nicht vertraut sind. Wir alle können bestimmte Ressourcen bevorzugen, aber nicht als unsere Identität und was noch wichtiger ist, wir müssen uns mit allem vertraut machen, um unsere Perspektive und unsere Auswahlmöglichkeiten zu erweitern. Ein echter Fachmann/ Fachfrau ist offen für alle Ideen: er/ sie sucht nach ihnen, lernt sie kennen und nutzt sie je nach Bedarf und ohne Zugehörigkeit. ### Beispiel: Kontinuierliches Lernen Zugehörigkeiten befriedigen die Person aufgrund des Gefühls der Zugehörigkeit, das sie erzeugen, aber sie drängen sie nicht zum Lernen und manchmal entmutigen sie sie sogar vom Lernen - aus Angst, sie zu verlieren. Wenn man ein freier Mensch ist, ein/ eine Expert:in ohne Zugehörigkeit, muss man die Lücke mit kontinuierlichem Lernen füllen. Das, woran wir heute glauben, ist nicht die Wahrheit. Es ist lediglich unser bisher bestes Verständnis, das im Laufe der Zeit noch verbessert werden muss. Es ist etwas falsch, wenn die eigenen Vorstellungen genau die gleichen sind wie vor ein paar Jahren. Das gilt sogar für NUPP: wenn dun nach ein paar Jahren zurückkommst und genau das Gleiche sieht, solltest du misstrauisch werden. ### Beispiel: Offenheit Wenn Du jemandem widersprichst, achte darauf, dass sich deine Einwände gegen die Idee und nicht gegen die Person richten. Das hilft, viele Spannungen zu vermeiden. Ähnlich verhält es sich, wenn jemand Einwände gegen dich hat: Versuche, dies nicht als einen Vorwurf gegen dich zu interpretieren, sondern als eine Diskussion über deine Ideen und bleibe offen dafür. Höre nicht zu, um zu antworten, sondern um zu verstehen. Arbeite mit der anderen Person zusammen, um die Idee zu verbessern. In diesem Fall solltest du der Person helfen, sich auf die Idee und nicht auf dich zu konzentrieren, bevor du fortfährst, und versuche dies während des gesamten Gesprächs beizubehalten. ## NUP2 Erhalte und optimiere Energie und Ressourcen [image] Ressourcen sind begrenzt. Die dem Projekt zur Verfügung stehenden Ressourcen sind begrenzt, ebenso wie die geistige Energie, die Du hast, um gute Entscheidungen zu treffen. Du solltest diese Ressourcen für dich selbst und für das Projekt schonen und optimieren und anderen Teammitgliedern dabei helfen, dasselbe zu tun. ### Beispiel: Die 80/20-Regel Ein großer Teil des möglichen Nutzens des Projektmanagements kann mit einem kleinen Teil des Aufwands erzielt werden. In den meisten Fällen ist es sehr teuer und nicht zu rechtfertigen, 100 % des möglichen Nutzens anzustreben. Du musst diese Regel bei allem, was du tust, berücksichtigen und andere dazu ermutigen, dies ebenfalls zu tun. ### Beispiel: Entscheidungsmüdigkeit Wir verwenden eine einzige Quelle geistiger Energie, um alle Arten von Entscheidungen zu treffen und auch um Willenskraft auszudrücken. Wenn du einen großen Teil dieser Quelle für unnötige oder unwichtige Entscheidungen verbrauchst, hast du weniger Energie für die wichtigen Entscheidungen, was zu schlechten Ergebnissen führen kann. Dies ist einer der Gründe, warum du Mikromanagement vermeiden solltest (das “Steuern nach dem Ausnahmeprinzip” von PRINCE2^(®)). Konflikte, bei denen es um Ideen geht, können hilfreich sein, aber solche, bei denen es um Menschen geht, sind in der Regel schädlich für das Projekt und eine der Folgen ist, dass sie die geistige Energie der Teammitglieder erschöpfen. Wenn du einen solchen Konflikt bemerkst, solltest du dein Bestes geben, um die Ursache zu finden und den Konflikt zu lösen. ### Beispiel: Kümmere dich um dich selbst! Die Entscheidungen, die du triffst und die Willenskraft, die du an den Tag legst, verbrauchen deine geistige Energiequelle. Andererseits wird diese Quelle mit Energie gefüllt, wenn du schläfst und richtig isst. Deshalb solltest du gut auf dich acht geben: sorge für ausreichend Schlaf und Ruhe und esse gut. Wenn du schädliche Gewohnheiten oder Schlafprobleme hast, musst du damit nicht allein fertig werden: es gibt viele Spezialisten, die dir helfen können, diese Probleme zu lösen. Auch körperliche Betätigung kann bei der Energiegewinnung helfen, auch wenn die Studien dazu noch nicht schlüssig sind. Versuche, deine Teammitglieder zu ermutigen, das Gleiche zu tun. Sorge zunächst dafür, dass sie in einem angemessenen Tempo und ohne zu viele Überstunden arbeiten. Wenn du die Möglichkeit dazu hast, biete während der Arbeitszeit energiereiche, gesunde Lebensmittel, Snacks und Getränke an. ### Beispiel: Work-Life-Balance Viele von uns lieben ihren Beruf, aber das ist nicht alles, was wir im Leben brauchen. Genauso wie du deine Arbeit optimierst, solltest du auch dein Privatleben planen und gestalten. Ziel ist ein glückliches und zufriedenes Leben. Wenn du glücklicher bist, bist du auch bei der Arbeit erfolgreicher. Wenn du es kannst, versuche deine Teammitglieder zu ermutigen, das Gleiche zu tun. ### Beispiel: Motivation Motivation ist ein komplexes Konzept. Es gibt einige interessante und nützliche Quellen zu diesem Thema, aber auch viele eher unwissenschaftliche. Gleichwohl solltest du dich mit diesem Konzept vertraut machen und es kontinuierlich anwenden, denn es erhöht die geistige Energie des Teams und die Möglichkeit, bessere Projektergebnisse zu erzielen. Motivation kann so einfach sein: ein freundliches Lächeln oder ein einfaches “Dankeschön”, um Mitarbeitern zu zeigen, dass du ihre gute Arbeit anerkannt hat. Du musst jedoch vorsichtig sein, denn viele der üblichen Formen der Motivation, wie kleine Geldprämien, haben einen negativen Effekt. ### Beispiel: Zusammenarbeit und Teamwork Menschen, die zusammenarbeiten, haben manchmal die Möglichkeit, bessere Ergebnisse zu erzielen, aber vor allem sind Menschen sozial und genießen es, Teil einer Gruppe zu sein. Wenn es dir gelingt, die negativen Aspekte der Teamarbeit zu beseitigen und ein angenehmes Umfeld zu schaffen, werden die Teammitglieder zufriedener mit dem Projekt sein. Du solltest jedoch vorsichtig sein, denn die Menschen sind unterschiedlich und manche brauchen mehr entspannte, konzentrierte und einsame Zeit als andere. Es ist meist ein Balanceakt. ### Beispiel: Ein-Team-Kultur Verschiedene Interessengruppen neigen dazu, Untergruppen zu bilden oder zu berücksichtigen und Spannungen mit anderen Gruppen zu verursachen, z. B. zwischen Personen, die sich auf die geschäftlichen Aspekte des Projekts konzentrieren und Personen, die das Produkt entwickeln. Diese Spannungen kosten beide Seiten viel Energie. Das ist einer der Gründe, warum wir versuchen sollten, eine Ein-Team-Kultur aufzubauen, in der alle gemeinsam auf das gleiche Ziel hinarbeiten. ### Beispiel: Die Weisheit der Massen Wenn eine große Anzahl von Menschen mit unterschiedlichen Interessen zusammenkommt und in einem moderierten Umfeld arbeitet, können hervorragende Ergebnisse, Ideen und Lösungen erzielt werden, die sogar besser sein können als die von einzelnen Experten. Wenn du die Möglichkeit hast, kannst du die Weisheit der Massen regelmäßig nutzen. Bitte Teammitglieder, dir bei der Lösung schwieriger Probleme im Projekt zu helfen. Abgesehen von der Möglichkeit, gute Ergebnisse zu erzielen, erfahren die Teammitglieder dadurch auch, dass ihre Meinung geschätzt wird und dass sie eine wichtige Rolle im Projekt spielen, was wiederum ihre Energie steigert. (Aktivität E02 von P3.express ist ein Beispiel für die Nutzung der Weisheit der Massen in Projekten.) ### Beispiel: Chef-Projektmoderator Wenn Du ein Projektmanager bist, haben die meisten Dinge, die du tust, einen Moderationscharakter (oder sollten ihn zumindest haben). Andererseits stellst du vielleicht fest, dass die Teammitglieder in der Vergangenheit schlechte Erfahrungen mit Projektmanagern gemacht haben und dass sich diese Erfahrungen auf ihre Beziehung zu dir auswirken: Ein Teil der Energie wird darauf verwendet, dein Verhalten auf potenzielle Bedrohungen zu analysieren, anstatt dir zu vertrauen. In diesem Fall könntest du deinen Titel von Projektmanager in Chief Project Facilitator ändern. Schließlich ist das deine eigentliche Aufgabe im Projekt. ## NUP3 Sei immer proaktiv [image] Es gibt eine natürliche Tendenz in uns, reaktiv zu sein. Das kann uns helfen, unsere Energie zu sparen, wenn wir uns mit unwichtigen Dingen beschäftigen, oder es kann uns bessere Ergebnisse bringen, wenn wir uns mit etwas beschäftigen, indem wir völlig inkompetent sind. Diese Situationen unterscheiden sich von unseren Projekten. In Projekten können wir bessere Ergebnisse erzielen, wenn wir proaktiv sind. ### Beispiel: Planung Wenn du zu einem neuen Ort fahren willst und du bist spät dran, kannst du sofort losfahren, um “Zeit zu sparen” und dich um mögliche Probleme kümmern, wenn sie auftreten. Der proaktive Ansatz besteht hingegen darin, sich am Anfang etwas Zeit zu nehmen und das Navigationssystem so einzustellen, dass es dir die schnellste Route auf der Grundlage des Verkehrs und möglicher Unfälle und Staus anzeigt und dann loszufahren. D. h. Zeit zu investieren, bevor man etwas tut, um später Probleme zu vermeiden und so letztendlich Zeit zu sparen. Im Gegensatz zu dem, was manche Leute über agile Projekte denken, ist Planung immer notwendig. Es geht nur um die Art und das Niveau der Details in den Plänen. Planen vor Ausführen ist ein proaktiver Ansatz. Denke an das geflügelte Wort: Geben Sie mir sechs Stunden, um einen Baum zu fällen, und ich werde die ersten vier Stunden damit verbringen, die Axt zu schärfen (Autor unbekannt). Bei einem vorausschauenden Projekt verbringst du vielleicht 4 Stunden damit, deine Axt zu schärfen, weil du sicher bist, dass du einen Baum fällen wirst. Bei einem agilen Projekt weißt du nicht, ob du den Baum fällen, abgebrochene Äste einsammeln, Torf ernten, Kohle abbauen oder etwas anderes tun wirst. Dennoch brauchst du eine allgemeine Vorbereitung für alle Aufgaben (du musst u.a. wissen, wo der nächste Baumarkt ist) und eine spezifische Vorbereitung, wenn du dich auf eine bestimmte Lösung konzentrieren willst: Das ist Planung. ### Beispiel: Planung der Planung Die Planung der Art und Weise, wie wir das Projekt durchführen werden, ist ein proaktiver Ansatz. Diese Proaktivität kann sogar noch erweitert werden, indem man die Art und Weise plant, wie man die Ausführung plant. Das ist das Managementplan-Konzept des PMBOK^(®) Guide, die Managementstrategien von PRINCE2^(®) und die Ansätze von DSDM^(®)  ### Beispiel: Kontinuierliche Planung Die Realität entspricht selten dem, was wir geplant haben und das ist auch gut so - aber wir müssen unsere Pläne kontinuierlich anpassen, um sicherzustellen, dass sie realistisch und praktikabel bleiben. Wir sollten dies tun, sobald eine Anpassung erforderlich ist und nicht, wenn wir auf Probleme stoßen. Das ist ein proaktiver Ansatz. ### Beispiel: Risikomanagement Das gesamte Konzept des Risikomanagements basiert auf Proaktivität: Wenn wir mit ungewissen Ereignissen konfrontiert werden, warten wir nicht ab, was passiert und reagieren dann darauf, sondern wir denken über Möglichkeiten und Auswirkungen nach, erwägen Reaktionen und unternehmen wahrscheinlich etwas, bevor es passiert. Beachte, dass es sich bei unseren Projekten um ernste Angelegenheiten handelt, bei denen es manchmal um das Leben von Menschen geht! ### Beispiel: Definierte Rollen und Verantwortlichkeiten Du kannst die Mitglieder deines Projektteams ohne klare Rollen und Zuständigkeiten arbeiten lassen. Früher oder später wird sich eine Form von Rollen und Zuständigkeiten herausbilden, aber das ist zu teuer und funktioniert vielleicht nicht sehr gut. Der proaktive Ansatz besteht darin, sie frühzeitig zu definieren und bei Bedarf anzupassen. Das erleichtert allen Beteiligten die Arbeit und das Team kann sich darauf konzentrieren, etwas zu produzieren, anstatt zu entscheiden, wer was macht. Die Anzahl und Vielfalt der Rollen hängen von der Art und Größe des Projekts ab. Es kann eine einfache Definition wie in Scrum sein, eine moderate wie in P3.express oder eine umfassende wie in DSDM^(®) und PRINCE2^(®). Vergiss jedoch nicht, dass sich die Rollenbeschreibungen in diesen Methoden nur auf Managementaktivitäten beziehen und dass du immer auch Rollenbeschreibungen für technische Aspekte hinzufügen musst. ### Beispiel: Verfügbare Optionen Solltest du das Projekt vorzeitig beenden oder fortsetzen? Es gibt selten nur zwei Möglichkeiten, auch wenn die Frage dies suggeriert. Du musst proaktiv vorgehen und alle Möglichkeiten in Betracht ziehen, bevor du eine Entscheidung triffst. Vielleicht kannst du das Projekt neu planen, vielleicht kannst du es pausieren lassen, bis etwas anderes klar wird oder vielleicht kannst du den Projektansatz ändern (z. B. Outsourcing) usw. ### Beispiel: Kritisches Denken Wir alle haben viele Vorurteile, die uns einerseits helfen, zu überleben und uns andererseits dazu verleiten, schlechte Entscheidungen zu treffen. Wenn es darum geht, wichtige Entscheidungen für ein Projekt zu treffen, ist es am besten, eine Weile innezuhalten und alle Vorurteile zu berücksichtigen, die unsere Entscheidung beeinflussen können, bevor sie Probleme verursachen. Als Referenz kannst du die Liste von kognitiven Verzerrungen in Wikipedia verwenden. Es gibt sogar Entscheidungsfindungsrahmen, die du nutzen kannst, um bessere Entscheidungen zu treffen. Anfangs mag es ablenkend und sogar lästig sein, sie zu verwenden, aber schon bald gewöhnt man sich daran und kann ohne große bewusste Anstrengung Vorteile daraus ziehen. ### Beispiel: Transparenz Wir mögen es nicht, wenn wir in einem Projekt Zeitverzug oder andere Probleme haben, aber das bedeutet nicht, dass wir sie verbergen sollten. Sie sollten transparent sein und die Beteiligten darüber informieren, denn einige von ihnen können dir vielleicht helfen und außerdem werden sie früher oder später von den Problemen und ihren Folgen erfahren und einige von ihnen werden vielleicht frühzeitige Maßnahmen von ihrer Seite verlangen (z. B. die negativen Folgen zu akzeptieren). ### Beispiel: Effektiv kommunizieren Es mag viele Fälle geben, in denen du Berichte an die Projektbeteiligten schickst, diese dir aber kein Feedback geben. Vielleicht glaubst du, dass alles in Ordnung ist, nur weil es keine negativen Rückmeldungen gibt - obwohl das nicht der Fall ist. Du musst proaktiv vorgehen und prüfen, ob der Bericht wirklich verwendet wurde und ob er seinen Zweck erfüllt hat, und die Rückmeldungen nutzen, um deine Kommunikationsmethode anzupassen. Andernfalls kann dieses verborgene Problem später ernsthafte Probleme verursachen, die schwerer zu beheben sind. ### Beispiel: Verantwortung übernehmen Es ist leicht, anderen die Schuld für schlechte Ergebnisse zu geben. Du möchtest vielleicht, dass deine Organisation dir die volle Autorität gibt, alles im Projekt zu ändern und es perfekt zu machen. Doch sie tun es nicht und als Folge davon, scheitert das Projekt. Dies ist kein proaktiver Ansatz. Ein proaktiver Ansatz besteht darin, die Verantwortung zu übernehmen und alles zu tun, was im Rahmen der Möglichkeiten möglich ist. Du kannst nicht erwarten, dass die Organisation dir uneingeschränkt vertraut und dir alles gibt, in der Hoffnung, gute Ergebnisse zu erzielen (vor allem, wenn sie schon so viele gescheiterte Projekte gesehen hat). Was du tun musst, ist, eine kleine Verbesserung innerhalb der gesetzten Grenzen vorzunehmen; nutze diese, um ein wenig Vertrauen, ein paar mehr Ressourcen und ein wenig mehr Toleranz für Einschränkungen zu gewinnen, und dies dann für eine etwas größere Verbesserung zu nutzen und so weiterzumachen, bis du das optimale Ziel erreichst. ## NUP4 Denke daran, dass eine Kette nur so stark ist wie ihr schwächstes Glied [image] Wir müssen eine ganzheitliche Perspektive des Projekts einnehmen, da es verschiedene Bereiche in Projekten gibt, die die gesamte Aufmerksamkeit aller Beteiligter benötigt. Es reicht nicht aus, einem - scheinbar - wichtigen Bereich (z. B. Zeit) Aufmerksamkeit zu schenken, denn alle Bereiche interagieren miteinander und funktionieren nur dann richtig, wenn sie alle angemessen berücksichtigt werden. ### Beispiel: Es geht um die Frist! Nehmen wir an, du baust etwas für die Olympischen Spiele. Eine Frist muss auf jeden Fall eingehalten werden, sodass das Zeitmanagement bedeutungsvoll ist. Aber ist das richtig? Was ist, wenn die Qualität so gering ist, dass nach einiger Zeit eine Wiederholung der Arbeit erforderlich wird? Das würde sich auf die Zeit auswirken. Es geht also um Zeit und Qualität. Du hast vielleicht einen schicken Garten, der in der ursprünglichen Definition des Projekts aufgeführt ist, aber du weißt, dass du, wenn die Zeit nicht ausreicht, ihn einfach mit Gras bedecken kannst, solange du diese Möglichkeit rechtzeitig in Betracht ziehst und dich darauf vorbereiten kannst. Daher ist auch das Bereichsmanagement wichtig. Jetzt stehen die Bereiche Umfang, Zeit und Qualität im Mittelpunkt unserer Aufmerksamkeit. Kennst du das berühmte Beispiel, in dem Präsident Kennedy, einen Hausmeister bei der NASA, trifft und ihn fragt, was er macht, und er antwortet: “Ich helfe dabei, einen Menschen auf den Mond zu bringen”? Hilft es nicht, den Termin einzuhalten, wenn man diese Art von Leuten im Projekt hat? Im weiteren Verlauf stellst du fest, dass jeder einzelne Bereich des Projekts zum Zeitmanagement beiträgt und du kannst die Frist nur dann mit einem akzeptablen Maß an Sicherheit einhalten, wenn du alle Bereiche berücksichtigst. ### Beispiel: Rosinenpickerei Wenn Menschen mit einer Vielzahl von Methoden konfrontiert werden, fangen sie manchmal an, die Rosinen herauszupicken und mischen alles, was ihnen aus verschiedenen Systemen interessant erscheint. Das funktioniert in der Regel nicht, denn die Elemente funktionieren nicht isoliert und müssen miteinander kompatibel sein. Alle Ergänzungen oder Änderungen an einem System sollten aus einer ganzheitlichen Sicht erfolgen. Daher sehen wir manchmal widersprüchliche Elemente in verschiedenen Methoden: Etwas funktioniert gut in einem System und sein Gegenteil funktioniert gut in einem anderen System. Dieses Element ist für sich genommen weder richtig noch falsch. Am sichersten ist es, eine Methode für das Projekt auszuwählen, sie anzupassen und dann vorsichtig neue Elemente hinzuzufügen, indem man die Konsistenz des gesamten Systems berücksichtigt. ### Beispiel: Der Antiprozess-Ansatz Eines der besten Dinge, die die agilen Methoden getan haben, ist, die Aufmerksamkeit auf menschliche Aspekte zu lenken. Im Agilen Manifest wird den Menschen und den Interaktionen ein höherer Stellenwert eingeräumt als den Prozessen und Werkzeugen, auch wenn dieser Vergleich vielleicht nicht ganz fair ist. Fast alle Methoden sagen, dass menschliche Aspekte wichtig sind. Der wirkliche Unterschied zu den agilen Methoden besteht darin, dass menschliche Aspekte ein fester Bestandteil ihrer Prozesse sind und nicht einfach nur ein Vorschlag. Es geht also nicht um einen Wettbewerb zwischen menschlichen Aspekten und Prozessen, sondern vielmehr um die Art und Weise, wie menschliche Aspekte im System gesehen werden. Zweifellos versuchen manche Leute, die menschlichen Aspekte durch ausgefeiltere Prozesse zu ersetzen, aber das ist nur eine missbräuliche Anwendung. Es gibt auch das Gegenteil: die Leute, die versuchen, Prozesse durch menschliche Aspekte zu ersetzen, was auch nicht gut funktioniert. ### Beispiel: Das sind alle Bereiche, die du brauchst Wenn du über Bereiche deines Projekts nachdenkst, solltest du darauf achten, dass du keinen übersiehst. Aber welche sind das? Wenn du in den grundlegenden Quellen nachsiehst, wirst du unterschiedliche Antworten erhalten, von denen jedoch keine die ganze Wahrheit ist. PRINCE2^(®)-Themen sind Domänen, aber das sind nur die Domänen, die in der Methodik eine Schlüsselrolle spielen. Die anderen Bereiche sind nur angedeutet. Der PMBOK^(®) Guide ist keine Methodik und lässt sich mit den zehn Wissensgebieten aber viel genauer formulieren. Dabei handelt es sich jedoch um Interpretationen aller Bereiche, die auf der Perspektive des PMBOK^(®) Guide auf das Projekt beruhen und nicht auf einer neutralen Perspektive (nicht, dass es unbedingt eine neutrale Perspektive gäbe). Zum Beispiel wird den menschlichen Aspekten im PMBOK^(®) Guide nicht viel Aufmerksamkeit geschenkt. Eine gute Quelle für Informationen über die Bereiche ist die Individual Competence Baseline, Version 4.0. Allerdings geht es hier nicht um die Bereiche, sondern um die Kompetenzen, die in einem Projekt erforderlich sind. Es besteht keine Eins-zu-eins-Beziehung zu den Domänen, aber es ist sehr hilfreich, um sie zu identifizieren. Im NUPP gibt es keine Liste von Domänen, vor allem, weil es sich um ein Metasystem handelt, und auch, weil die Kategorisierung der Domänen von der Art des Projekts und seiner Umgebung abhängt; z. B. kann ein routinemäßiges Bauprojekt eine andere Perspektive erfordern als ein kreatives Forschungsprojekt. ## NUP5 Tue nichts ohne einen klaren Zweck [image] Du solltest nichts tun, wenn es nicht einen klaren Zweck hat. Stell dir zwei parallele Welten vor, in denen alles gleich ist, außer der Sache, die du zu tun gedenkst: Wie unterschiedlich wären diese Welten? Ist der Unterschied die Mühe wert? Wenn du kein klares Ziel vor Augen hast und etwas nur tust, weil alle anderen es auch tun oder weil alle sagen, dass es wichtig ist, es zu tun, dann - hat es in deinem Fall vielleicht keinen wirklichen Nutzen und deshalb hast du nichts davon, oder - es kann in deinem Fall trotzdem einen potenziellen Nutzen haben, aber weil du den Zweck nicht im Auge hast, wird deine Art, es zu tun, nicht dazu beitragen, den Nutzen zu realisieren. ### Beispiel: Portfolios und Programme Wenn du an der Auswahl und Initiierung von Projekten beteiligt bist, solltest du darauf achten, dich auf den Nutzen und die zu lösenden Probleme zu konzentrieren und nicht auf das Produkt, mit dem diese Dinge realisiert werden sollen. Ein klassisches Beispiel ist der Hersteller von Aufzügen, bei dem es immer wieder Beschwerden über die Geschwindigkeit seiner Aufzüge gab, sodass er mehrere Projekte zur Erhöhung der Geschwindigkeit durchführte - jedoch ohne Erfolg. Das ging so lange, bis man beschloss, sich auf das Problem (die Langeweile oder das Unbehagen der Menschen) zu konzentrieren, anstatt auf die “natürliche” Lösung (schnellere Aufzüge). Das Ergebnis war, dass man die Aufzüge mit Spiegeln ausstattete, was das Problem einfach und kostengünstig löste. Denke daran, dass es beim Projektmanagement hauptsächlich darum geht, die Dinge richtigzumachen, während es beim Portfoliomanagement darum geht, die richtigen Dinge zu tun. Es spielt keine Rolle, wie gut du deine Projekte durchführst. Sie werden nicht gut laufen, wenn du die falschen Projekte durchführst. Es geht primär darum, ein Ziel zu haben. ### Beispiel: Projekt als Ganzes Die Flexibilität des Produkts ist von Projekt zu Projekt unterschiedlich. Bei einigen IT-Entwicklungsprojekten ist das Produkt völlig flexibel und seine endgültige Form hängt von den Rückmeldungen ab, die durch die Inkremente des Produkts während des Projekts erzeugt werden (was einen adaptiven, agilen Ansatz erfordert). In der Praxis handelt es sich um eine Kombination aus Portfolio-, Programm- und Projektebene, bei der dem Gesamtziel höchste Aufmerksamkeit gewidmet werden muss. Es ist eine gute Idee, den Zweck zu dokumentieren und zugänglich zu machen. Das ist einer der Zwecke der “Produktvision”, wie sie in einigen Scrum-Projekten verwendet wird. Die Beachtung des Geschäftswerts in agilen Projekten ist eine Möglichkeit, die Ausrichtung auf den Zweck sicherzustellen.  Bei anderen Projekttypen, bei denen das Produkt relativ feststeht und es andere Mechanismen gibt, um sicherzustellen, dass das ermittelte Produkt den Zweck erfüllt, können die Mitglieder des Projektteams einen großen Teil ihres Fokus vom Zweck auf das Produkt verlagern (daher das Prinzip “Fokus auf Produkte” in PRINCE2^(®)). Allerdings ist ein Mindestmaß an Aufmerksamkeit für den Zweck immer noch erforderlich, um sicherzustellen, dass das, was gebaut wird, den Zweck erfüllt. Die Messung der Zweckerfüllung kann durch den Vergleich des prognostizierten Nutzens mit dem erwarteten Nutzen erfolgen (daher das Prinzip der “Fortgesetzten geschäftlichen Rechtfertigung” und das Thema “Business Case” in PRINCE2^(®)). Wenn ein Projekt für einen externen Kunden durchgeführt wird, hat der Kunde seinen eigenen Zweck für das Projekt, und dein Unternehmen hat einen anderen Zweck. Um wirklich erfolgreich zu sein, solltest du beide verstehen und umsetzen. ### Beispiel: Projektüberwachung Die Konzentration auf den eigentlichen Zweck ist notwendig, aber für viele der täglichen Anwendungen ist er möglicherweise zu abstrakt. Deshalb ist eine Hierarchie von Zielen erforderlich, um sie operationabel zu machen. Zunächst werden die Rechtfertigung und der Nutzen des Projekts auf der Grundlage des Hauptzwecks definiert, und dann werden explizite und implizite Ziele für Projektvariablen (z. B. Zeit, Kosten und Qualität) festgelegt, um die Rechtfertigung zu erfüllen, die wiederum den Hauptzweck erfüllt. Dies sind Ziele auf niedrigerer Ebene, die für viele unserer täglichen Aufgaben nützlich sind. Wenn es um die Überwachung geht, wird die Überwachung des Projekts auf der untersten Ebene der Variablen durchgeführt, da es häufig nicht möglich ist, den Hauptzweck selbst zu verfolgen. In diesem Fall solltest du dir dennoch die Ziele vor Augen halten: Was ist der Zweck der Überwachung? Eine normale und akzeptable Antwort besteht darin, festzustellen, ob wir auf dem richtigen Weg sind und wenn nicht, eine bestimmte Reaktion auszulösen, die uns wieder auf den richtigen Weg bringt, oder die Ziele anzupassen und zu sehen, ob sie den endgültigen Zweck noch erfüllen kann. Unsere Messungen sollten daher in der Lage sein, bei diesem einfachen Zweck zu helfen, und die geeignesten Messungen sind Prognosen für die Variablen bei der Fertigstellung; z. B. wann werden wir das Projekt abschließen können? Wie viel Geld brauchen wir, um das Projekt abzuschließen? Alle anderen Messungen, wie die bisherigen Plan- und Ist-Werte, sind nur Zwischenwerte, die du für die Berechnung der Prognosen benötigst und nicht die endgültigen Werte, die du für Managementzwecke verwendest. ### Beispiel: Dokumente Unabhängig davon, welchen Entwicklungsansatz du im Projekt verwendest, ist eine Planung immer notwendig. Die wichtige Frage dabei ist der Detaillierungsgrad jedes Plans. Wenn der Plan nicht detailliert genug ist, kann er nicht genug beitragen und die Durchführung des Projekts wird eher auf Ad-hoc-Entscheidungen als auf integrierten, ganzheitlichen Entscheidungen beruhen. Andererseits versuchen viele Leute, vorsichtig zu sein und fügen ihrem Plan zu viele Details hinzu, wodurch er schwer zu erstellen und zu pflegen ist und zu starr für die Unwägbarkeiten des Projekts. Infolgedessen wird der Plan unrealistisch und unbrauchbar. Der beste Weg, um über den Detaillierungsgrad zu entscheiden, besteht darin, einen Zweck für jedes Element des Plans im Fokus zu haben. Wenn du z. B. die Aufnahme von Ressourcen in den Plan in Betracht ziehst, sollte dies einem Zweck dienen: Wie wirst du die Ressourcen verwenden? Wie wird es dem Projekt helfen? Wie hoch ist der Aufwand und ist es das wert? Manchmal geht es um die Entscheidung, ob du ein bestimmtes Element in deinen Plänen haben und manchmal um die Art und Weise, wie du etwas planen oder vorbereiten willst. Egal ob es sich um einen Business Case, eine Projektcharta oder einen Bericht handelt: Du solltest dich immer fragen, warum du dieses Dokument erstellst und wie es dem Projekt helfen kann. Die Suche nach einer Vorlage ist das Gegenteil davon, etwas auf der Grundlage eines Zwecks zu tun. ### Beispiel: Statusbericht Bei vielen Projekten ist es üblich, dass die Statusberichte sehr lang sind. Auf der Grundlage dieses NUP sollten wir uns fragen, was der Zweck des Berichts ist und wie wir diesen Zweck erreichen können - und zwar unabhängig davon, was die meisten anderen Leute tun. Dies kann in vielen Fällen dazu führen, dass wir sehr einfache einseitige Berichte erstellen, die von den Beteiligten wirklich gelesen und verstanden werden, anstatt lange Berichte. Das ist die Aufmerksamkeit für den Zweck, den wir wollen. Wenn du jedoch einseitige Berichte erstellst, könnten einige Leute dagegen Einspruch erheben und denken, dass du kein “richtiges” Überwachungssystem eingerichtet hast. In der Praxis bedeutet dies, dass du einen zweiten Zweck verfolgst (neben dem ersten, nämlich den Stakeholdern zu helfen, den Projektstatus zu verstehen) und um diesen zu erfüllen, kannst du einfach eine zweite Art von Bericht erstellen, der sehr lang ist. Allerdings darfst du diesen nicht mit dem ersten Bericht vermischen, da diese beiden Zwecke nicht identisch sind. ### Beispiel: Business Case und Projektcharta Die Erstellung von Dokumenten wie einem Business Case und eine Projektcharta ist für die meisten Menschen eine langweilige, fruchtlose und bürokratische Notwendigkeit, obwohl diese Dokumente alle einen gültigen Zweck haben, der für die meisten Projekte gilt. Wenn du versuchst, eine Vorlage zu finden und diese ausfüllst, ist die Arbeit umsonst. Stattdessen könntest du den wirklichen Zweck dieser Dokumente prüfen und herausfinden, ob und wie sie für dein Projekt hilfreich sein können, und dann das Dokument so erstellen, wie du es möchtest. Das alles nur um diesen Zweck zu erfüllen: Es ist das richtige und ein wichtiges Dokument. Während du darüber nachdenkst, wie du die Dokumente so vorbereiten kannst, dass sie ihren Zweck erfüllen, denkst du vielleicht nicht an jedes Szenario und übersiehst etwas. Um das zu vermeiden, kannst du in Ressourcen wie PRINCE2^(®), PMBOK^(®) Guide, P3.express und DSDM^(®) nachsehen, was dort vorgeschlagen wird und diese Vorschläge dann anhand der Zwecke bewerten. ### Beispiel: Nach dem Projekt Das Projekt hat zwar einen bestimmten Zweck, und wir können diesen Zweck während des gesamten Projekts berücksichtigen, aber die Verwirklichung wird hauptsächlich auf der Grundlage der während des Projekts gemachten Prognosen bewertet. Nach Abschluss des Projekts sollten wir dies jedoch nicht vergessen. Es ist wichtig, die Verwirklichung der Ziele nach Abschluss des Projekts zu überprüfen, damit - wir sehen können, wie die Hauptziele erreicht werden, und daraus für zukünftige Projekte lernen können, und - manchmal werden die Ziele nur erreicht, wenn wir nach Abschluss des Projekts zusätzliche Aufgaben durchführen. Um die Notwendigkeit dieser zusätzlichen Aufgaben zu verstehen, ist eine Überwachung erforderlich. Die Überwachung nach Abschluss des Projekts ist ein notwendiger Schritt, um zielorientiert zu arbeiten. Sie liegt hauptsächlich in der Verantwortung von Programm- und Portfoliomanagementsystemen. Da die meisten Unternehmen nicht über solche Managementebenen verfügen, wird dieser Schritt meist vernachlässigt. Daher fügen Methoden wie P3.express und DSDM^(®) diesen Schritt ihren Projektmanagement-Methoden hinzu. ### Beispiel: Vereinfachung Die Welt ist komplex und chaotisch, aber unsere Modelle sind abstrakte Annäherungen, die Teile der Welt widerspiegeln und daher können sie einfach sein. Andererseits funktionieren einfache Systeme in der Regel besser, weil wir uns auf die Hauptidee konzentrieren können. Viele von uns versuchen, bessere Ergebnisse zu erzielen, indem sie ihre Systeme komplexer machen. Die Hoffnung dahinter ist, dass sie der Komplexität der Welt entsprechen werden, auch wenn dies in der Praxis die Arbeit mit dem System erschwert und uns in der Regel daran hindert, den Zweck zu erfüllen. ### Beispiel: Maßschneidern Eine Software für das Streaming von Musik hat andere Voraussetzungen wie eine, die für die Ausrüstung eines Krankenhauses oder eines Flugzeugs verwendet wird (wo das Leben von Menschen davon abhängt) oder als eine Software, die in einem Satelliten eingesetzt wird (wo sie viele Jahre lang ohne Absturz funktionieren soll) und sie alle unterscheiden sich vom Bau einer Sommervilla, einer Feuerwache und einer Prozessanlage. Wenn du den Zweck im Auge hast, wirst du besser verstehen, wie du die Systeme und Artefakte für verschiedene Projekte anpassen kannst. ## NUP6 Verwende wiederholbare Elemente [image] Ein Ad-hoc-Ansatz für ein Projekt bindet zu viel Energie und Ressourcen und birgt immer die Gefahr, dass einige der notwendigen Elemente fehlen. Der beste Weg zur Vereinfachung dessen, was getan werden muss, ist die Verwendung wiederholbarer Elemente, und zwar vorzugsweise in wiederholbaren Zyklen. ### Beispiel: Qualitätschecklisten Eine Checkliste ist ein einfaches Beispiel für ein potenziell wiederholbares Element, das viele Menschen in ihrem persönlichen und beruflichen Leben verwenden. Nimm z. B. die Qualitätskriterien für ein Produkt: - Zunächst kannst du eine Checkliste mit allen Kriterien erstellen, was eine Form der Planung ist. - NUP6 empfiehlt, zu versuchen, sie zu verallgemeinern: Gibt es in dem Projekt andere ähnliche Leistungen? In diesem Fall solltest du eine allgemeine Qualitätscheckliste für diese Kategorie von Lieferobjekten erstellen und sie für alle verwenden. Wenn es einige Abweichungen gibt, behalte die allgemeine Liste bei und füge ein paar zusätzliche Punkte für die einzelnen Teilleistungen hinzu. Jetzt hast du eine wiederholbare Checkliste. - Wenn du erst einmal allgemeine Checklisten für verschiedene Arten von Lieferobjekten erstellt hast, wirst du vielleicht Elemente finden, die sich wiederholen, was auf eine virtuelle übergeordnete Kategorie für sie hindeutet. In diesem Fall kannst du, anstatt die Elemente für alle diese allgemeinen Checklisten zu wiederholen, diese extrahieren und in eine übergeordnete Checkliste aufnehmen. Am Ende wirst du wahrscheinlich eine einzige allgemeine Checkliste für das gesamte Projekt haben. Die “Definition of Done” von Scrum ist ein Beispiel für die Verwendung von Checklisten auf Projektebene für die Qualität sowie anderer Kriterien. Auf diese Weise gehört jedes Ergebnis zu einer Hierarchie von Kategorien und sollte die Punkte erfüllen, die in den Checklisten aller übergeordneten Kategorien erscheinen. Auf diese Weise wird ein Punkt in der übergeordneten Checkliste für alle darunter liegenden Liefergegenstände wiederholbar, was Zeit und Energie bei der Planung und Ausführung spart. Noch wichtiger ist, dass du diese Vorgehensweise, wenn du sie einmal für ein Projekt durchgeführt hast, in Zukunft für alle ähnlichen Projekte anwenden kannst, was eine wiederholbare Form der Planung für mehrere Projekte darstellt. ### Beispiel: Prozesse und Arbeitsabläufe Einige Leistungen oder damit verbundene Ziele erfordern bestimmte Schritte, die standardisiert und wiederholbar werden können. Wenn die Leistungen insbesondere einzeln entworfen und genehmigt werden müssen, kannst du einen einfachen Arbeitsablauf erstellen, der alle Schritte, die beteiligten Personen und die ungefähre Dauer deutlich macht und so viele Schwierigkeiten vermeidet. Achte jedoch darauf, die Arbeitsabläufe und Prozesse nicht zu kompliziert oder zu dokumentationsintensiv zu gestalten, da sich dies negativ auswirkt. Alle Projektbeteiligten sollten die Arbeitsabläufe und Prozesse als etwas sehen, das ihre Arbeit unterstützt und ihnen vieles erleichtert und nicht als bürokratischer Akt, der ihre eigentliche Arbeit behindert. Agile Projekte haben in ihrem iterativen Entwicklungsansatz wiederholbare Elemente, bei denen bestimmte Entwicklungsaktivitäten für jede Funktion wiederholt werden, z. B. die tägliche Routine in XP (eXtreme Programming): Paare bilden, ein Objekt auswählen, es auf einem Whiteboard entwerfen, die Testskripte und den Code erstellen, den Code integrieren usw. Neben den wiederholbaren Arbeitsabläufen, die für technische Aktivitäten verwendet werden können, gibt es auch wiederholbare Elemente für die Projektmanagementaktivitäten. Die Prozesse im PMBOK^(®) Guide, PRINCE2^(®) und DSDM^(®), die Aktivitäten in P3.express und die Ereignisse in Scrum sind Beispiele für dieses Konzept. ### Beispiel: Zyklen Wiederholbare Elemente für die Verwaltung des Projekts sind hilfreich. Dies kann noch einfacher gemacht werden, indem man sie in wiederholbare Zyklen einteilt. Diese Zyklen vereinfachen die täglichen Aktivitäten, der an der Verwaltung und Leitung des Projekts beteiligten Personen, erheblich. Beispiele für dieses Konzept sind - zyklen von Prozessgruppen im PMBOK^(®) Guide, wenn sie in einem Projekt mit mehreren Phasen verwendet werden, - phasen in PRINCE2^(®), - tägliche, wöchentliche und monatliche Zyklen in P3.express, - iterationen und timeboxes in DSDM^(®) und - sprints in Scrum.  Kürzere Zyklen sind leichter zu verstehen und zu verwenden als längere: z.B. die Sprints in Scrum im Gegensatz zu den Phasen nach dem PMBOK^(®) Guide. Zu kurze Zyklen reichen jedoch möglicherweise nicht aus, um bestimmte Projekttypen zu unterstützen. Die Lösung kann die Verwendung mehrerer Zyklen sein, wie die Verwendung von kurzen Timebox-Zyklen in DSDM^(®) zusammen mit längeren Iterationszyklen oder die Verwendung von täglichen, wöchentlichen und monatlichen Zyklen in P3.express. ### Beispiel: Methoden Die Verwendung einer Methodik oder eines Frameworks für die Durchführung eines Projekts ist eine weitere Verwendung von wiederholbaren Elementen. Dabei kann es sich um ein bestehendes System wie PRINCE2^(®), P3.express, DSDM^(®) oder Scrum handeln oder um ein System, das du selbst angepasst oder entwickelt hast. In der Regel ist es jedoch besser, mit einer der vorhandenen Methoden zu beginnen und sie an die eigenen Bedürfnisse anzupassen, als sie von Grund auf neu zu entwickeln. Jedes wiederholbare Element ist abstrakt und muss an die reale Welt angepasst werden. Es gibt jedoch eine Bandbreite von Abstraktion und Anpassungsbedarf: Kleine, relativ konkrete Qualitätschecklisten stehen an einem Ende der Bandbreite mit dem geringsten Abstraktionsgrad und Anpassungsbedarf, während Methoden am anderen Ende stehen, mit dem höchsten Anpassungsbedarf. Du solltest immer darauf achten, dass eine Anpassung erforderlich ist, da sonst das wiederholbare Element nicht richtig auf deine Bedürfnisse abgestimmt werden kann.