ISO 21502 beschreibt, welche Praktiken ein Projekt braucht, damit es steuerbar bleibt und den beabsichtigten Nutzen liefert. Der Leitfaden benennt Rollen, Entscheidungspunkte und Managementpraktiken — vom Geschäftsbegründungsnachweis über die Steuerung von Umfang, Terminen und Kosten bis zur Übergabe in den Betrieb.
Vorgeschrieben wird dabei keine Methode. ISO 21502 legt kein Phasenmodell fest, verlangt keine bestimmten Dokumente und trifft keine Entscheidung zwischen plangetriebenem und agilem Vorgehen. Der Leitfaden beschreibt, was geregelt sein muss, und überlässt der Organisation, wie sie es regelt. Das macht ihn als gemeinsamen Bezugsrahmen für ein gemischtes Projektportfolio brauchbar — und als Rezeptbuch unbrauchbar.
Die Zuordnung innerhalb der Normenreihe hat sich 2020 verschoben und wird bis heute verwechselt. Bis dahin war ISO 21500 der Leitfaden zum Projektmanagement. Seither trägt ISO 21502 diese Rolle, und ISO 21500 beschreibt den übergreifenden Rahmen für Projekt-, Programm- und Portfoliomanagement mit Kontext und Begriffen. Wer eine Vertragsklausel oder eine interne Richtlinie noch auf „ISO 21500, Leitfaden Projektmanagement“ stützt, verweist auf einen überholten Stand.
Ein Zertifikat gibt es nicht, und das ist der zweite verbreitete Irrtum. Der Leitfaden enthält Empfehlungen, keine Anforderungen — es fehlt die Grundlage, gegen die eine Zertifizierungsstelle prüfen könnte. Was stattdessen möglich ist, steht weiter unten.
Die Kernelemente des Leitfadens
Der Text gliedert sich in vier inhaltliche Blöcke: Grundkonzepte des Projektmanagements, Voraussetzungen in der Organisation, übergreifende Praktiken über den Projektverlauf und die einzelnen Managementpraktiken innerhalb eines Projekts. Die folgende Übersicht fasst die Praktiken zusammen, die im Betrieb den Unterschied machen.
| Element | Was der Leitfaden erwartet | Typische Lücke |
|---|---|---|
| Geschäftsbegründung | Begründeter Nutzen, der über den Projektverlauf überprüft und bei Bedarf revidiert wird | Einmal zur Freigabe erstellt, danach nie wieder angesehen |
| Sponsor und Projektleitung | Getrennte Rollen: Nutzenverantwortung und Lieferverantwortung | Ein Lenkungsausschuss ohne benannte Einzelverantwortung |
| Nutzenmanagement | Nutzen benennen, messen und nach dem Projekt nachverfolgen | Nutzen wird im Antrag beziffert und nie überprüft |
| Umfangssteuerung | Festgelegter Umfang mit definiertem Änderungsverfahren | Änderungen werden zugesagt, ohne Termin und Kosten anzupassen |
| Ressourcen | Verfügbarkeit zugesagter Personen, Kompetenz, Teamentwicklung | Personen sind in mehreren Projekten zu je achtzig Prozent verplant |
| Termin- und Kostensteuerung | Fortschreibung mit Prognose statt reiner Rückschau | Ampelbericht ohne Restaufwandsschätzung |
| Risiken und Chancen | Laufende Behandlung, nicht nur Erfassung zum Projektstart | Risikoliste aus der Startphase, keine Aktualisierung |
| Themen und Eskalation | Klare Verfahren für offene Punkte und Entscheidungsbedarf | Entscheidungen bleiben in Statusrunden liegen |
| Qualität | Vereinbarte Abnahmekriterien und Prüfungen im Verlauf | Abnahme am Ende, Kriterien werden dann erst diskutiert |
| Beschaffung | Vergabe, Vertragsgestaltung und Steuerung der Lieferanten | Lieferantensteuerung fällt zwischen Einkauf und Projektleitung |
| Stakeholder und Kommunikation | Ermittlung, Analyse und aktive Einbindung der Beteiligten | Verteilerliste statt Analyse von Einfluss und Erwartung |
| Organisatorische Veränderung | Vorbereitung der Betroffenen auf die neue Arbeitsweise | Das Projekt liefert ein System, das niemand nutzen will |
| Lessons Learned | Erfahrungen sammeln, auswerten und für Folgeprojekte verfügbar machen | Abschlussworkshop, dessen Ergebnis in einem Ordner endet |
| Berichtswesen und Information | Adressatengerechte Berichte, gelenkte Projektdokumentation | Jede Projektleitung berichtet in eigenem Format |
Zwei Elemente stechen heraus, weil sie in deutschen Projektorganisationen regelmäßig fehlen.
Der Sponsor. ISO 21502 trennt die Nutzenverantwortung von der Lieferverantwortung. Der Sponsor steht für den Geschäftsnutzen ein und entscheidet, ob das Projekt fortgeführt wird; die Projektleitung verantwortet, dass geliefert wird, was vereinbart ist. In der Praxis existiert oft nur ein Lenkungsausschuss, in dem sich diese Verantwortung auf mehrere Personen verteilt und damit verschwindet. Die Folge ist, dass niemand ein Projekt beendet, dessen Geschäftsgrundlage entfallen ist.
Die Nutzenrealisierung. Der Nutzen entsteht fast immer nach dem Projektende — wenn die Anlage produziert, wenn das System genutzt wird, wenn der Prozess läuft. Der Leitfaden verlangt deshalb, den Nutzen über das Projektende hinaus zu verfolgen und die Verantwortung dafür zu übergeben. Wo das fehlt, endet die Betrachtung mit der Abnahme, und die Frage, ob sich das Projekt gelohnt hat, wird nie beantwortet.
Für wen sich der Leitfaden lohnt und wann nicht
Der stärkste Anlass ist Uneinheitlichkeit. In Organisationen, in denen jede Projektleitung ihr eigenes Vorgehen mitbringt, sind Projekte untereinander nicht vergleichbar: unterschiedliche Statusformate, unterschiedliche Begriffe für dieselben Sachverhalte, unterschiedliche Entscheidungspunkte. ISO 21502 liefert die Gliederung, an der sich eine gemeinsame Projektmanagementrichtlinie ausrichten lässt, ohne eine bestimmte Methode zu erzwingen.
Der zweite Anlass ist ein gemischtes Portfolio. Wenn Anlagenprojekte plangetrieben und Softwareprojekte agil laufen, braucht die Leitung trotzdem eine gemeinsame Sicht. Weil der Leitfaden Praktiken statt Phasen beschreibt, funktioniert er als Klammer über beide Welten.
Der dritte Anlass ist ein Qualitätsmanagementsystem, das die Projektabwicklung nicht abbildet. In ISO 9001 fällt Projektarbeit unter die Planung und Steuerung der Leistungserbringung und — bei kundenspezifischen Lösungen — unter die Entwicklung. Wer diese Kapitel mit einer an ISO 21502 orientierten Richtlinie füllt, bekommt einen prüffähigen Prozess statt einer Sammlung von Vorlagen.
Gegen eine vollständige Umsetzung sprechen zwei Konstellationen. Wer bereits mit einem etablierten Methodenrahmen arbeitet und darin geschult ist, gewinnt durch einen Wechsel nichts — der Leitfaden ist dann als Prüfliste für Lücken sinnvoll, nicht als Ersatz. Und in kleinen Projektorganisationen mit wenigen, überschaubaren Vorhaben erzeugt eine vollständige Ausgestaltung mehr Verwaltung als Steuerung. Der Beitrag dazu, wie lange die Einführung eines Managementsystems wirklich dauert, gilt hier sinngemäß: Der Aufwand entsteht nicht beim Schreiben, sondern beim Ändern der Gewohnheiten.
Was sich statt eines Zertifikats nachweisen lässt
Weil ISO 21502 ein Leitfaden ist, gibt es weder eine Zertifizierung der Organisation noch ein akkreditiertes Personenzertifikat, das sich auf diesen Text bezieht. Angebote, die eine „ISO-21502-Zertifizierung“ in Aussicht stellen, beziehen sich auf Schulungen mit Teilnahmenachweis oder auf Prüfungen eines Anbieters ohne Akkreditierungsgrundlage.
Drei Wege führen trotzdem zu einem belastbaren Nachweis.
- Über ISO 9001. Nehmen Sie die Projektabwicklung in den Geltungsbereich des Qualitätsmanagementsystems auf und beschreiben Sie den Projektprozess an ISO 21502 orientiert. Der Auditor prüft dann Planung, Steuerung, Änderungsverfahren, Abnahme und Übergabe. Das Ergebnis ist ein akkreditiertes Zertifikat, das den Projektprozess einschließt; der Ablauf einer Zertifizierung ist der übliche.
- Über interne Audits. Legen Sie die eigene Projektmanagementrichtlinie als Auditkriterium fest und prüfen Sie laufende Projekte dagegen. Das deckt Abweichungen früh auf und liefert eine Nachweisspur. Wie sich ein solches Programm risikobasiert aufsetzen lässt, beschreibt der Beitrag zur risikobasierten Auditprogrammplanung; die Methodik dafür liefert ISO 19011.
- Über Personenqualifikation. Zertifikate der Projektmanagementverbände und methodengebundene Nachweise belegen die Kompetenz der Beteiligten. Sie sagen nichts über die Organisation aus, werden in Ausschreibungen aber häufig abgefragt und sind der einzige verbreitete Personennachweis in diesem Feld.
Woran Projekte scheitern
Die Geschäftsbegründung wird nicht fortgeschrieben. Sie diente der Freigabe und wurde danach nicht mehr angefasst. Wenn sich Marktlage, Kundenbedarf oder Technologie ändern, fehlt der Anlass, das Projekt zu überprüfen. Abbruchkriterien wurden nie festgelegt, deshalb wird nie abgebrochen.
Ressourcen sind zugesagt, aber nicht verfügbar. Die Projektplanung geht von Personen aus, die parallel im Linienbetrieb gebunden sind. Der Terminplan ist damit von Anfang an unrealistisch, ohne dass es jemand ausspricht.
Die Stakeholder-Analyse ist eine Verteilerliste. Erfasst wird, wer informiert werden soll. Nicht erfasst wird, wer das Projekt verhindern kann und warum er es wollen könnte. Wie diese Analyse tragfähig wird, beschreibt der Beitrag zum Ermitteln interessierter Parteien.
Risiken werden erfasst statt behandelt. Die Risikoliste entstand im Startworkshop und wurde seither nicht aktualisiert. Maßnahmen sind ohne Termin und ohne Verantwortlichen eingetragen. Die Methodik aus ISO 31000 hilft hier mehr als jedes Formular, weil sie Bewertung und Behandlung trennt.
Änderungen laufen ohne Verfahren. Zusagen entstehen im Gespräch mit dem Auftraggeber und finden nie den Weg in Termin- und Kostenplanung. Am Ende ist das Projekt überzogen, und niemand kann rekonstruieren, wodurch.
Lessons Learned bleiben im Projekt. Der Abschlussworkshop findet statt, die Ergebnisse liegen im Projektordner. Das Folgeprojekt beginnt und macht dieselben Fehler. Nutzbar wird die Erfahrung erst, wenn sie in Richtlinien, Vorlagen oder Prüflisten einfließt — dorthin, wo sie ohne Suche gefunden wird.
Der Nutzen wird nie gemessen. Nach der Abnahme löst sich das Projektteam auf. Ob die zugesagte Einsparung, die versprochene Durchlaufzeit oder die erwartete Kapazität tatsächlich eintreten, prüft niemand. Damit fehlt jede Grundlage, künftige Anträge realistisch zu bewerten.
Abgrenzung zu anderen Rahmenwerken
| Rahmenwerk | Charakter | Ergebnis für die Organisation |
|---|---|---|
| ISO 21502 | Leitfaden zum Projektmanagement, methodenneutral | Kein Zertifikat, dient als Bezugsrahmen für eigene Richtlinien |
| ISO 21500 | Kontext und Begriffe für Projekt-, Programm- und Portfoliomanagement | Kein Zertifikat, ordnet die Reihe ein |
| ISO 21503 und ISO 21504 | Programm- und Portfoliomanagement | Leitfäden, kein Zertifikat |
| ISO 10006 | Qualitätsmanagement in Projekten | Leitfaden, ergänzt die QM-Sicht auf Projektarbeit |
| PMBOK Guide | Wissenssammlung eines Verbands, Grundlage für Personenzertifikate | Personenzertifikat, keine Organisationszertifizierung |
| PRINCE2 | Methodenrahmen mit Prozessen, Rollen und Produkten | Personenzertifikat, methodisch festgelegt |
| IPMA-Kompetenzmodell | Kompetenzbasierte Bewertung von Projektbeteiligten | Gestufte Personenzertifikate |
| ISO 9001 | Qualitätsmanagementsystem | Akkreditiertes Zertifikat, kann die Projektabwicklung einschließen |
Die praktische Konsequenz: ISO 21502 konkurriert nicht mit PMBOK oder PRINCE2, sondern liegt auf einer anderen Ebene. Die Verbandswerke liefern Methoden und qualifizieren Personen, der Leitfaden liefert die Struktur, gegen die sich eine Organisation prüfen kann. Wer beides nutzt, richtet die interne Richtlinie an ISO 21502 aus und schult die Projektleitungen nach dem Modell, das im eigenen Markt erwartet wird. Für Projekte, deren Ergebnis von vornherein ungewiss ist, greift dieser Rahmen allerdings zu kurz — dort ist der Umgang mit Ungewissheit selbst der Gegenstand, wie ihn ISO 56002 für Innovationsvorhaben beschreibt.