Was ist eine Projektumfeldanalyse? Erklärung, Prozess und Beispiel
Die Projektumfeldanalyse ist eine Methode des Projektmanagements, mit der Sie systematisch alle Personen, Gruppen, Sachverhalte und Rahmenbedingungen erfassen, die ein Projekt beeinflussen oder von ihm beeinflusst werden. Sie unterteilt das Projektumfeld in soziale und sachliche sowie interne und externe Faktoren. So erkennen Sie Chancen und Risiken früh und können Maßnahmen ableiten.
Im deutschsprachigen Projektmanagement hat sich für diese Methode die Abkürzung PUMA etabliert, die für Projekt-Umfeld-Analyse steht. Beide Bezeichnungen meinen dasselbe Vorgehen: eine strukturierte Bestandsaufnahme aller Einflussgrößen, die außerhalb des eigentlichen Projektinhalts liegen. Wer im PUMA-Projektmanagement nach Vorlagen oder Zertifizierungsliteratur sucht, findet die Methode unter beiden Begriffen.
Die Systematik beruht auf zwei Dimensionen, die sich zu einer Vier-Felder-Matrix kombinieren lassen: Die Art der Faktoren unterscheidet zwischen sozial und sachlich, ihre Herkunft zwischen intern und extern. Daraus ergeben sich vier Umfeldkategorien, die jeder Analyse ihren Ordnungsrahmen geben. Der Ablauf selbst umfasst fünf Schritte: Umfeldfaktoren identifizieren, Nahtstellen bestimmen (also die Berührungspunkte zwischen Projekt und Umfeld), Einfluss und Einstellung bewerten, Erwartungen und Befürchtungen erfassen sowie Maßnahmen ableiten. Als Ergebnis entstehen typischerweise eine Umfeldmatrix, eine Kraftfeldanalyse, ein Chancen-Risiken-Portfolio und eine Maßnahmentabelle.
Erstellt wird die Analyse in der Projektinitiierung beziehungsweise in der Definitionsphase, also bevor die Detailplanung beginnt. Abgeschlossen ist sie damit aber nicht. Sie wird über den gesamten Projektverlauf mehrfach aktualisiert, weil sich Akteure, Haltungen und Rahmenbedingungen verändern. Der Umfang richtet sich nach der Projektgröße: Für ein Kleinprojekt genügt eine schlanke Umfeldmatrix, ein Großprojekt braucht zusätzlich Portfolio- und Maßnahmendokumentation. Auch die Projektart verschiebt die Gewichtung. Bau- und Anlagenprojekte stehen und fallen mit dem sachlich-externen Umfeld aus Genehmigungen, Normen und Auflagen. Interne Reorganisationen haben ihren Schwerpunkt dagegen im sozial-internen Umfeld, also bei Betriebsrat, Fachbereichen und Führungsebene.
Zwei Missverständnisse halten sich hartnäckig. Das erste: Projektumfeldanalyse und Stakeholderanalyse seien dasselbe. Tatsächlich deckt die Stakeholderanalyse ausschließlich den sozialen Teil des Umfelds ab, also Personen und Gruppen. Die Projektumfeldanalyse geht darüber hinaus und bezieht sachliche Faktoren wie Gesetze, Technologien, Standorte, Normen und Marktbedingungen mit ein. Die Stakeholderanalyse ist damit eine Teilmenge, keine Alternative. Das zweite Missverständnis: Die PUMA sei ein einmalig zu erstellendes Startdokument. In Wahrheit ist sie ein lebendes Arbeitsdokument mit definierten Aktualisierungszeitpunkten.
Für Sie als Projektmanager oder Projektverantwortlichen ist das mehr als eine methodische Feinheit. Übersehene Umfeldfaktoren zählen zu den häufigsten Ursachen für Termin- und Budgetabweichungen. Besonders in Multiprojektumgebungen, in denen mehrere Vorhaben um dieselben Schlüsselressourcen, Freigaben und Genehmigungswege konkurrieren, entscheidet die Vollständigkeit dieser Analyse darüber, ob Sie steuern oder nur noch nachsteuern.
Kurz gefasst: Die Projektumfeldanalyse macht sichtbar, wer und was ein Projekt beeinflusst, und liefert die Grundlage für Maßnahmen, bevor aus Einflussfaktoren Probleme werden.
Inhaltsverzeichnis
- Was versteht man unter einer Projektumfeldanalyse?
- Welche Ziele verfolgt eine Projektumfeldanalyse?
- Warum ist eine Projektumfeldanalyse für den Projekterfolg unverzichtbar?
- Welche Faktoren gehören in eine Projektumfeldanalyse?
- Wie führt man eine Projektumfeldanalyse durch?
- Welche Ergebnisse liefert eine Projektumfeldanalyse?
- Beispiel für eine Projektumfeldanalyse
- Welche Fehler treten bei der Projektumfeldanalyse häufig auf?
- Wie unterstützt Projektmanagement-Software die Projektumfeldanalyse?
- Fazit zur Definition und Durchführung einer Projektumfeldanalyse
- Häufig gestellte Fragen zur Projektumfeldanalyse
Was versteht man unter einer Projektumfeldanalyse?
Die Projektumfeldanalyse erfasst und bewertet alle Einflussgrößen, die außerhalb des unmittelbaren Projektinhalts liegen. Damit unterscheidet sie sich grundlegend von rein inhaltlichen Planungsmethoden wie dem Projektstrukturplan, der beschreibt, was im Projekt zu leisten ist.
Als Projektumfeld gilt die Gesamtheit aller Faktoren, die auf ein Projekt einwirken, ohne selbst Teil des Projektinhalts zu sein. Ein einzelner solcher Faktor, der sogenannte Umfeldfaktor, kann eine Person, eine Organisationseinheit, eine Vorschrift, ein technisches System oder eine wirtschaftliche Entwicklung sein. Entscheidend ist die Wechselseitigkeit dieser Beziehung: Das Umfeld wirkt auf das Projekt, und das Projekt wirkt auf sein Umfeld zurück. Eine Reorganisation verändert Arbeitsabläufe in Fachbereichen, eine Anlagenerweiterung verändert die Verkehrssituation am Standort. Genau deshalb reicht bloßes Sammeln nicht aus. Die Methode besteht aus drei aufeinander aufbauenden Tätigkeiten: Faktoren erfassen, ihre Wirkung bewerten und daraus Handlungsoptionen ableiten. Die so ermittelten Rahmenbedingungen des Projekts bilden die Grundlage für alle weiteren Planungsentscheidungen.
Systematisch geordnet wird das Projektumfeld über zwei Dimensionen, die sich kreuzen: sozial oder sachlich auf der einen Achse, intern oder extern auf der anderen. Diese Zweiteilung ist kein akademisches Konstrukt, sondern in den gängigen Projektmanagement-Standards verankert. Sowohl die DIN 69901 als auch die Kompetenzelemente von IPMA und GPM führen die Umfeldbetrachtung als festen Bestandteil der Projektdefinition. Am Ende steht keine lose Materialsammlung, sondern eine bewertete Umfeldübersicht, die unmittelbar weiterverwendet wird: als Input für das Risikomanagement im Projekt und als Ausgangspunkt für das Stakeholdermanagement.

Wie unterscheidet sich die Projektumfeldanalyse von der Stakeholderanalyse?
Beide Methoden stehen nicht nebeneinander zur Auswahl, sondern sind ineinander verschachtelt: Die Stakeholderanalyse ist Teil der Projektumfeldanalyse, nicht ihr Synonym. Wer eine Umfeldanalyse im Projektmanagement durchführt, betrachtet die Stakeholder als eine von mehreren Faktorengruppen. Stakeholder sind dabei alle Personen und Gruppen, die ein Interesse am Projektverlauf haben. Die Stakeholderanalyse untersucht ausschließlich diese Personen, Gruppen und Organisationen und ist damit exakt die Analyse des sozialen Projektumfelds. Die Projektumfeldanalyse ergänzt sie um sachliche Faktoren wie Gesetze, Normen, Technologien, Märkte, Standortbedingungen und Infrastruktur.
| Kriterium | Projektumfeldanalyse | Stakeholderanalyse |
|---|---|---|
| Betrachtungsgegenstand | Personen, Gruppen und sachliche Faktoren | Ausschließlich Personen, Gruppen, Organisationen |
| Umfang | Übergeordnete Methode, schließt Stakeholder ein | Teilbereich des sozialen Umfelds |
| Typische Ergebnisdokumente | Umfeldmatrix, Kraftfeldanalyse, Chancen-Risiken-Portfolio, Maßnahmentabelle | Stakeholder-Register, Einfluss-Interesse-Matrix |
| Folgeprozess | Risikomanagement, Klärung der Rahmenbedingungen, Kommunikationsplanung | Stakeholdermanagement und Kommunikationsplanung |
| Zeitpunkt der Erstellung | Projektinitiierung, laufende Aktualisierung | Meist im Anschluss als vertiefender Arbeitsschritt |
In der Praxis wird die Stakeholderanalyse häufig als eigenständiger, vertiefender Arbeitsschritt aus der Projektumfeldanalyse heraus durchgeführt, sobald die sozialen Faktoren identifiziert sind.
Was sind die Kernbereiche der Projektumfeldanalyse?
Die vier Kernbereiche entstehen als Kreuzung zweier Dimensionen: Die Art des Faktors trennt Soziales von Sachlichem, die Herkunft trennt das interne und externe Projektumfeld. Das Ergebnis ist eine Umfeldmatrix, also eine Vier-Felder-Tabelle, in der jeder identifizierte Faktor genau einem Feld zugeordnet wird. Jedes Feld beantwortet dabei eine eigene Leitfrage: Wer beeinflusst von innen? Wer von außen? Was beeinflusst von innen, was von außen?
| intern | extern | |
|---|---|---|
| sozial | Akteure aus der eigenen Organisation, etwa Geschäftsführung, Fachabteilungen und Betriebsrat. | Akteure außerhalb der Organisation, etwa Kunden, Lieferanten, Behörden und Anwohner. |
| sachlich | Nicht-personelle Gegebenheiten im Unternehmen, die das sachliche Projektumfeld nach innen abbilden, etwa IT-Systeme, interne Richtlinien und Budgetvorgaben. | Nicht-personelle Gegebenheiten von außen, etwa Gesetze, Normen, Marktbedingungen und Standort- oder Witterungseinflüsse. |
Vollständig wird die Analyse erst, wenn Sie alle vier Felder aktiv abfragen. Der mit Abstand häufigste Anwendungsfehler besteht darin, sich auf die soziale Zeile zu beschränken, weil Personen und Gruppen im Workshop schneller einfallen als Normen oder Systemabhängigkeiten. Die sachlichen Felder bleiben dann leer, obwohl dort genau die Restriktionen liegen, die sich später nicht verhandeln lassen.
Warum wird die Projektumfeldanalyse auch PUMA genannt?
PUMA ist im deutschsprachigen Projektmanagement das gängige Akronym für Projekt-Umfeld-Analyse und findet sich vor allem in der Zertifizierungsliteratur von IPMA und GPM sowie in Hochschulskripten. Ein methodischer Unterschied zwischen PUMA und Projektumfeldanalyse besteht nicht, es handelt sich um dieselbe Methode unter zwei Bezeichnungen.
Daneben kursieren weitere Bezeichnungen: Umfeldanalyse im Projektmanagement, Projektumfeldbetrachtung oder schlicht Umfeldanalyse. Für die Praxis heißt das vor allem eines: Wenn Sie nach Vorlagen, Prüfungsfragen oder Kapiteln in Projekthandbüchern suchen, prüfen Sie beide Schreibweisen. Die Trefferlisten unterscheiden sich teils deutlich.
Welche Ziele verfolgt eine Projektumfeldanalyse?
Die Ziele einer Projektumfeldanalyse bilden ein klar umrissenes Bündel: Sie soll das Projektumfeld transparent machen, Einflussgrößen bewertbar machen und daraus konkrete Handlungsoptionen ableiten. Übergeordnet geht es darum, Unsicherheit über die Projektumgebung in planbare Information zu überführen. Sechs Teilziele konkretisieren diesen Anspruch:
- Transparenz über Einflussfaktoren schaffen: Alle relevanten Personen, Gruppen und Sachverhalte werden dokumentiert, statt implizit im Kopf der Projektleitung zu bleiben. Damit sind sie auch dann verfügbar, wenn Rollen wechseln.
- Risiken frühzeitig erkennen: Widerstände, fehlende Genehmigungen oder konkurrierende Vorhaben werden sichtbar, bevor sie Termine gefährden.
- Chancen identifizieren: Unterstützende Akteure, verfügbare Ressourcen und günstige Rahmenbedingungen lassen sich gezielt nutzen, statt sie dem Zufall zu überlassen.
- Kommunikation planbar machen: Aus der Bewertung von Einfluss und Einstellung ergibt sich, wer wann und in welcher Intensität informiert oder eingebunden werden muss. Das Stakeholdermanagement erhält damit eine belastbare Grundlage statt Bauchgefühl.
- Akzeptanz für das Projekt sichern: Erwartungen und Befürchtungen werden erfasst und adressiert, bevor sie sich in offenen Widerstand verwandeln.
- Grundlage für Projektplanung und Maßnahmen schaffen: Umfeldfaktoren fließen in Terminplanung, Ressourcenplanung und das Risikomanagement im Projekt ein, konkret in das Risikoregister.

Ein Nebenziel wird selten benannt, ist im Projektalltag aber Gold wert: die Absicherung der Projektleitung. Dokumentierte Umfeldfaktoren machen Annahmen und Entscheidungen nachvollziehbar, auch Monate später und gegenüber Dritten. Die Gewichtung der Ziele verschiebt sich dabei im Projektverlauf. In der Projektinitiierung dominieren Transparenz und Risikoerkennung, weil zunächst überhaupt ein Bild entstehen muss. Im weiteren Verlauf rücken Kommunikation und Akzeptanzsicherung in den Vordergrund, weil sich Haltungen verändern und aus einem anfangs neutralen Fachbereich schnell ein Bremser werden kann.
Warum ist eine Projektumfeldanalyse für den Projekterfolg unverzichtbar?
Der überwiegende Teil von Projektstörungen entsteht nicht aus der fachlichen Aufgabe selbst, sondern aus dem Umfeld. Und genau diese Störquellen bleiben ohne systematische Analyse unsichtbar, bis sie sich von selbst melden – meist zum ungünstigsten Zeitpunkt.
Wer Projekte über Jahre begleitet, kennt die Muster: fehlende Unterstützung im Management, Widerstand aus Fachbereichen oder vom Betriebsrat, regulatorische Auflagen, die erst bei der Prüfung auffallen, Ressourcenkonkurrenz mit Parallelprojekten, ausfallende Lieferanten. All diese Faktoren wirken über die Nahtstellen des Projekts ein, also über die konkreten Berührungspunkte zwischen Projekt und Umfeld. Jede nicht erkannte Nahtstelle ist ein blinder Fleck in der Planung. Charakteristisch ist zudem, dass diese Faktoren außerhalb des direkten Zugriffs der Projektleitung liegen. Beeinflussbar ist nicht der Faktor selbst, sondern nur der Umgang mit ihm.
Wie unterschiedlich solche Faktoren ausfallen, zeigen Erfahrungen aus unseren Kundenprojekten. Bei Uhde High Pressure Technologies führten fehlende Transparenz über Ressourcen und parallele Planungsprozesse bei rund 170 Projekten zu Problemen bei der Liefertermintreue – ein klassischer sachlich-interner Umfeldfaktor, der in keinem einzelnen Projektplan auftaucht. Nachgesteuert wurde, indem die Planungsprozesse vereinheitlicht und in PLANTA zusammengeführt wurden. Bei Losan Pharma wiederum dominieren externe Restriktionen: Arzneimittelzulassungen oder Umbauten von Produktions- und Laborräumen sind an feste Termine, an die GMP-Qualifizierung und an behördliche Abnahmen gebunden. Werden solche Faktoren nicht frühzeitig berücksichtigt, entstehen daraus schnell Termin- oder Budgetabweichungen.
Die zweite Argumentationslinie ist eine Kostenlogik. Der Aufwand für die Behebung wächst mit dem Projektfortschritt überproportional. Eine Genehmigungspflicht, die Sie in der Definitionsphase entdecken, kostet Planungszeit und einen zusätzlichen Vorgang im Terminplan. Dieselbe Erkenntnis während der Realisierung kostet Baustopp oder Produktionsverzug, dazu Vertragsstrafen und Erklärungsbedarf im Lenkungsausschuss. Frühzeitige Erfassung verwandelt Überraschungen in eingeplante Vorgänge, und genau das ist der eigentliche Hebel.
Hinzu kommt die Anschlussfähigkeit an andere Projektmanagement-Prozesse. Die Ergebnisse der Analyse fließen direkt in das Risikomanagement im Projekt, in die Kommunikationsplanung und in die Terminplanung ein. Sie liefern die Datengrundlage für das Risikoregister, also das zentrale Verzeichnis aller identifizierten Projektrisiken mit Bewertung und Verantwortlichkeit, für den Kommunikationsplan und für die Stakeholderstrategie. Fehlt die Umfeldanalyse, beruhen all diese Folgeplanungen auf ungeprüften Annahmen. In Multiprojektumgebungen, in denen mehrere Vorhaben auf dieselben Fachkräfte, Budgets und Freigabeinstanzen zugreifen, potenziert sich dieser Effekt: Was in einem Projekt als Annahme durchgeht, kollidiert im nächsten mit der Realität. Wie groß Ihr Handlungsspielraum ausfällt, hängt dabei unmittelbar vom Zeitpunkt der Analyse ab. Je früher sie vorliegt, desto mehr Optionen stehen Ihnen noch offen.
Wann im Projektverlauf wird die Projektumfeldanalyse erstellt und aktualisiert?
Die Ersterstellung gehört in die Projektinitiierung beziehungsweise Projektdefinition, also vor die Detailplanung und idealerweise parallel zur Klärung des Projektauftrags. Damit ist die Arbeit jedoch nicht getan, denn die Analyse ist ein lebendes Dokument mit definierten Aktualisierungsanlässen. Für Projektleitungen und PMO-Verantwortliche, die mehrere Vorhaben parallel steuern, lohnt es sich, diese Anlässe verbindlich festzuschreiben:
- Meilensteinabschluss: Nach jedem erreichten Meilenstein prüfen Sie, ob neue Akteure hinzugekommen sind oder sich Bewertungen verschoben haben.
- Phasenübergang: Der Wechsel von Planung zu Realisierung verändert regelmäßig, welche Umfeldfaktoren aktiv werden.
- Wechsel in Schlüsselrollen: Ein neuer Auftraggeber oder eine neue Fachbereichsleitung bringt eigene Erwartungen mit und macht eine Neubewertung nötig.
- Änderungen im Projektauftrag: Ein erweiterter Scope bedeutet fast immer zusätzliche Nahtstellen zum Umfeld.
- Veränderte gesetzliche oder Marktbedingungen: Neue Vorschriften, Lieferengpässe oder Wettbewerbsbewegungen verschieben die sachlichen Rahmenbedingungen.
Ergänzend gilt: Auch eine erkennbar veränderte Stimmungslage bei wichtigen Stakeholdern ist ein Aktualisierungsanlass. Als Mindestrhythmus empfiehlt sich die Überprüfung zu jedem Phasenübergang, bei Langläuferprojekten zusätzlich quartalsweise.
Warum die Fortschreibung in der Praxis trotzdem so oft ausbleibt, ist schnell erklärt: Die PUMA wird als einmaliges Startdokument behandelt und liegt danach neben dem eigentlichen Projektprozess. Hat die Aktualisierung weder einen festen Verantwortlichen noch einen Termin oder einen konkreten Prozessschritt, verliert sie im Tagesgeschäft schnell an Priorität. Ein Beispiel aus unserer Kundenpraxis: Bei Dr. Willmar Schwabe lagen Statusberichte vor der Einführung von PLANTA nur sporadisch als PowerPoint-Dateien in Projektablagen. Seit die Projekte zentral in PLANTA abgebildet sind, ist der Projektstatus transparent und wird konsequenter nachverfolgt – laut Schwabe hat sich dadurch auch die Termintreue verbessert.
„Der wirksame Auslöser ist weniger die Aufforderung ‚Dokument bitte aktuell halten‘, sondern die Einbindung in einen verbindlichen Regelprozess, etwa regelmäßige Statusberichte oder termingebundene Quality Gates. Kurz gesagt: Der nachweisbare Hebel ist Prozessintegration statt Dokumentationsdisziplin.“
Wie das konkret aussehen kann, zeigt Losan Pharma: Dort ist ein PM-Leitfaden für vier Projektphasen mit Checklisten und Freigaben in PLANTA abgebildet. Jedes Projekt muss geplant, budgetiert und freigegeben werden, sechs PMOs entlasten die Projektleitungen und achten auf die Einhaltung der Governance. Wer die Umfeldprüfung als Checklistenpunkt in die Phasenfreigabe legt, macht die Fortschreibung zur Pflicht statt zur guten Absicht.
In welcher der 4 Projektphasen findet die Projektumfeldanalyse statt?
Projektphasen strukturieren den Projektverlauf in abgegrenzte Abschnitte mit eigenen Zielen und Ergebnissen. Das klassische Vier-Phasen-Modell unterscheidet Initiierung/Definition, Planung, Realisierung/Steuerung und Abschluss. In jeder dieser Phasen spielt die Umfeldbetrachtung eine andere Rolle.
| Projektphase | Rolle der Projektumfeldanalyse | Typische Aktivität |
|---|---|---|
| 1. Initiierung/Definition | Schwerpunkt: Hier entsteht die Erstversion | Workshop zur Identifikation und Erstbewertung aller Umfeldfaktoren |
| 2. Planung | Ergebnisse werden präzisiert und eingearbeitet | Überführung in Termin-, Ressourcen- und Risikoplanung |
| 3. Realisierung/Steuerung | Laufende Überwachung: Das Projektumfeld zu analysieren, wird zur Routineaufgabe | Aktualisierung bei Veränderungen, Maßnahmenverfolgung |
| 4. Abschluss | Grundlage der Lessons Learned (strukturierte Auswertung der Projekterfahrungen) | Auswertung: Welche Faktoren wurden übersehen, welche Maßnahmen haben gewirkt? |
Der eindeutige Schwerpunkt liegt in Phase 1, weil dort der Handlungsspielraum am größten ist. In hybriden und agilen Vorgehensmodellen bleibt dieses Prinzip erhalten, nur wird die Analyse dort zu Beginn erstellt und anschließend iterativ, etwa zu Release- oder Sprintgrenzen, fortgeschrieben.
Bleibt die berechtigte Frage, ob es die PUMA als eigenständige Methode in agilen Setups überhaupt noch braucht oder ob kontinuierliche Stakeholder-Reviews sie längst ersetzt haben. Unsere Antwort aus der Praxis: Ein reines Stakeholder-Review erfasst genau die externen Rahmenbedingungen nicht, die in regulierten Branchen den Takt vorgeben. Losan Pharma plant seine stark regulierten Pharmaprojekte beispielsweise weiterhin klassisch, weil sie feste Termine und konkrete Ziele haben, etwa eine Arzneimittelzulassung zu einem festen Datum. In agilen und hybriden Projekten werden die Ergebnisse anschließend in Stakeholder-, Risiko- und Review-Prozessen weitergeführt. Siegfried hat beispielsweise die Erfassung von Risiken und Chancen direkt in den Projekten als Anforderung an seine Software definiert.
„Die PUMA muss nicht zwingend als eigenes Dokument weiterleben, ihr methodischer Kern aber schon. Als einmalige Zertifizierungsübung bringt sie wenig, als strukturierter Startpunkt bleibt sie sehr sinnvoll.“
Welche Faktoren gehören in eine Projektumfeldanalyse?
In eine vollständige Analyse gehören Faktoren aus vier Kategorien, die sich aus der Kombination von Art und Herkunft ergeben. Jede Kategorie muss aktiv abgefragt werden, denn das Auslassen der internen oder externen Perspektive erzeugt ebenso systematische Lücken wie das Auslassen der sozialen oder sachlichen Sicht. Die Vier-Felder-Matrix aus dem vorigen Abschnitt dient dabei als Ordnungsrahmen.
- Soziales Projektumfeld: Alle Personen, Gruppen und Organisationen, die das Projekt beeinflussen oder von ihm betroffen sind, von der Geschäftsführung über Fachabteilungen bis zu Kunden, Behörden und Anwohnern.
- Sachliches Projektumfeld: Alle nicht-personellen Rahmenbedingungen wie Gesetze, Normen, Technologien, Infrastruktur, Standortbedingungen und Marktlage.
- Internes Projektumfeld: Alle Einflüsse aus der eigenen Organisation, etwa Unternehmensstrategie, Parallelprojekte, Ressourcenverfügbarkeit, interne Richtlinien und IT-Systeme.
- Externes Projektumfeld: Alle Einflüsse von außerhalb der Organisation, also Gesetzgeber, Kunden, Lieferanten, Wettbewerb, Öffentlichkeit und wirtschaftliche Entwicklungen.
Zwei Hinweise zur Anwendung: Jeder Umfeldfaktor wird nicht nur benannt, sondern zusammen mit seiner Nahtstelle zum Projekt erfasst, sonst bleibt der Eintrag abstrakt. Und die Kategorienzuordnung ist ein Arbeitsmittel, kein Selbstzweck. Grenzfälle wie einen externen Dienstleister, der intern eine Teamrolle übernimmt, ordnen Sie pragmatisch zu, statt lange über die Taxonomie zu diskutieren.

1. Soziales Projektumfeld: Welche Personen und Gruppen beeinflussen das Projekt?
Das soziale Projektumfeld umfasst alle Personen, Gruppen und Institutionen mit Interesse am oder Einfluss auf das Projekt, unabhängig davon, ob sie formal am Projekt beteiligt sind. Es ist die Kategorie mit der höchsten Dynamik, weil sich Einstellungen im Projektverlauf verändern und eine Stakeholderanalyse deshalb nie dauerhaft gültig bleibt. Die Erfassung muss über die formale Projektorganisation hinausgehen und auch informelle Meinungsführer, betroffene Mitarbeiter und Interessenvertretungen einschließen.
- Auftraggeber und Sponsor: Entscheidet über Budget, Ziele und Priorität des Projekts im Portfolio.
- Geschäftsführung und Management: Setzt strategische Leitplanken und signalisiert durch sichtbare Unterstützung die Bedeutung des Vorhabens.
- Projektteam: Trägt die operative Umsetzung und bringt gleichzeitig eigene Erwartungen an Arbeitsbedingungen und Rollenklärung mit.
- Betroffene Fachabteilungen: Liefern Zuarbeit, stellen Ressourcen und sind zugleich von den Ergebnissen betroffen, was sie zu den häufigsten Konfliktpartnern macht.
- Betriebsrat und Personalvertretung: Wirkt bei mitbestimmungspflichtigen Themen wie Leistungsdatenerfassung oder Arbeitsplatzveränderungen verbindlich mit. Bei Hermes Arzneimittel wurde der Betriebsrat beispielsweise frühzeitig zum Thema Zeiterfassung informiert, und der Zugriff auf personenbezogene Daten wurde klar begrenzt.
- Kunden und Endanwender: Bewerten das Ergebnis nach Nutzbarkeit und entscheiden faktisch über die Akzeptanz.
- Lieferanten und Dienstleister: Bringen Leistungen und Termine ein, deren Verzug direkt auf den Projektplan durchschlägt.
- Behörden und Genehmigungsstellen: Setzen Fristen und Auflagen, die nicht verhandelbar sind und lange Vorlaufzeiten erfordern.
- Öffentlichkeit und Anwohner: Werden vor allem bei Bau-, Standort- und Infrastrukturprojekten zum relevanten Faktor.
Regelmäßig übersehen werden IT-Administration, Datenschutzbeauftragte, angrenzende Fachbereiche und die späteren Nutzer des Ergebnisses. Als Prüfraster hat sich eine schlichte Leitfrage bewährt: Wer trifft Entscheidungen, wer liefert Zuarbeit, wer ist von den Ergebnissen betroffen, wer könnte das Projekt blockieren?
2. Sachliches Projektumfeld: Welche technischen und rechtlichen Rahmenbedingungen wirken auf das Projekt?
Das sachliche Projektumfeld umfasst alle nicht-personellen Faktoren, also rechtliche, technische, wirtschaftliche, ökologische und infrastrukturelle Gegebenheiten. Der entscheidende Unterschied zum sozialen Umfeld: Diese Faktoren sind meist nicht verhandelbar. Sie gehen als Restriktion in die Planung ein, also als nicht veränderbare Rahmenbedingung, die den Handlungsspielraum begrenzt. Sortiert nach Herkunftsbereichen ergeben sich sechs Gruppen von Rahmenbedingungen im Projekt:
- Rechtliche Rahmenbedingungen: Gesetze, Verordnungen, Genehmigungspflichten und Datenschutzanforderungen. In der Pharmaindustrie dominieren hier GMP-Vorgaben und Zulassungsverfahren, deren Fristen den gesamten Terminplan bestimmen. Wer etwa Produktions- oder Laborräume umbaut, muss GMP-Qualifizierung und behördliche Abnahme von Anfang an als feste Vorgänge einplanen.
- Technische Rahmenbedingungen: Systemlandschaft, Schnittstellen, Normen und Standards sowie die technische Machbarkeit. Im Maschinenbau sind es häufig Maschinenrichtlinie, CE-Konformität und die Anbindung an bestehende PPS-Systeme.
- Wirtschaftliche Rahmenbedingungen: Budgetrahmen, Marktlage, Wechselkurse und Lieferantenpreise. In der Elektronik schlägt vor allem die Bauteilverfügbarkeit durch, die Lieferzeiten und Produktkosten gleichermaßen verschiebt.
- Infrastrukturelle Rahmenbedingungen: Standorte, Räumlichkeiten, Transportwege und Netzabdeckung. Bei Projekten über mehrere Werke hinweg entscheidet die Anbindung darüber, ob Remote-Zusammenarbeit funktioniert.
- Zeitliche Rahmenbedingungen: Fristen, Wartungsfenster, Betriebsferien und saisonale Einschränkungen. Diese Gruppe wird am häufigsten übersehen, obwohl gesperrte Zeiträume ganze Go-live-Termine kippen können.
- Ökologische Rahmenbedingungen: Umweltauflagen, Nachhaltigkeitsvorgaben und Witterungseinflüsse bei Außenprojekten, etwa bei Anlagenmontagen im Winterhalbjahr.
3. Internes Projektumfeld: Welche Einflüsse kommen aus der eigenen Organisation?
Das interne Projektumfeld umfasst alle Einflüsse innerhalb der eigenen Organisation und enthält sowohl soziale als auch sachliche Faktoren. Es ist der Bereich mit dem größten Gestaltungsspielraum der Projektleitung und zugleich derjenige mit den häufigsten verdeckten Konflikten, weil hier Prioritäten und Budgets verteilt werden.
- Unternehmensstrategie und Portfolioprioritäten: Die strategische Einordnung entscheidet darüber, wie schnell Ihr Projekt Zugriff auf Mittel und Aufmerksamkeit erhält.
- Parallelprojekte und Ressourcenkonkurrenz: Ein Ressourcenkonflikt, also der gleichzeitige Zugriff mehrerer Vorhaben auf dieselbe Kapazität, ist in Multiprojektumgebungen der Umfeldfaktor mit der größten Terminwirkung. Wenn drei Projekte auf dieselbe SAP-Fachkraft zugreifen, entscheidet nicht die Projektplanung, sondern die Portfoliopriorität.
- Interne Richtlinien und Freigabeprozesse: Beschaffungsrichtlinien, Investitionsgrenzen und Gremienzyklen bestimmen, wie lange Entscheidungen brauchen.
- IT-Systemlandschaft und bestehende Tools: Vorhandene Systeme geben Schnittstellen und Datenmodelle vor und begrenzen damit technische Optionen.
- Unternehmenskultur und Veränderungsbereitschaft: Wie stark eine Organisation an Veränderungen gewöhnt ist, beeinflusst den Aufwand für Kommunikation und Schulung erheblich.
- Verfügbare Budgets und Genehmigungswege: Nicht nur die Höhe des Budgets zählt, sondern auch, über wie viele Instanzen eine Freigabe läuft.
Interne Faktoren sind grundsätzlich beeinflussbar, aber häufig politisch aufgeladen. Genau deshalb lohnt es sich, sie schriftlich zu erfassen: Ein dokumentierter Ressourcenkonflikt lässt sich im Lenkungsausschuss adressieren, ein ungenannter bleibt ein Dauerproblem auf Arbeitsebene.
4. Externes Projektumfeld: Welche Einflüsse kommen von außen?
Das externe Projektumfeld umfasst alle Einflüsse außerhalb der eigenen Organisationsgrenzen und enthält ebenfalls soziale und sachliche Faktoren. Wenn Sie das Projektumfeld analysieren, gilt für diesen Bereich eine andere Logik als für das Innenverhältnis: Beobachtung ist hier wichtiger als Einflussnahme, weil die Faktoren kaum steuerbar sind.
- Gesetzgeber und Aufsichtsbehörden: Neue Vorschriften wie eine verschärfte Maschinenverordnung können Anforderungen mitten im Projekt verändern.
- Kunden und externe Auftraggeber: Änderungswünsche oder verschobene Abnahmetermine wirken direkt auf Scope und Meilensteine, etwa bei kundenspezifischen Sondermaschinen.
- Lieferanten und Dienstleister: Ein verzögerter Steuerungsschrank oder ein ausgefallener Implementierungspartner verschiebt komplette Arbeitspaketketten.
- Wettbewerb und Marktentwicklung: Ein früherer Markteintritt eines Wettbewerbers kann den Zeitplan einer Produktentwicklung unter Druck setzen.
- Öffentlichkeit und Medien: Bei Standorterweiterungen oder Personalmaßnahmen entsteht Berichterstattung, die auf die interne Stimmung zurückwirkt.
- Gesamtwirtschaftliche und geopolitische Entwicklungen: Zölle, Energiepreise oder unterbrochene Lieferketten verändern Kalkulationsgrundlagen ohne Vorwarnung.
Für nicht steuerbare Faktoren definieren Sie deshalb keine Beeinflussungsmaßnahmen, sondern Beobachtungsroutinen. Bewährt hat sich die Kombination aus einem benannten Monitoring-Verantwortlichen, einem Frühindikator und einem eingeplanten Zeitpuffer im Terminplan. Ein Frühindikator ist ein beobachtbares Signal, das eine Veränderung im Umfeld ankündigt, etwa eine Bekanntmachung im Bundesanzeiger, ein steigender Lieferzeitindex oder die Tagesordnung eines Aufsichtsgremiums.
Wie führt man eine Projektumfeldanalyse durch?
Eine Projektumfeldanalyse durchzuführen heißt, fünf aufeinander aufbauende Schritte in verbindlicher Reihenfolge abzuarbeiten. Die Reihenfolge ist kein Formalismus: Eine Bewertung ohne vollständige Identifikation erzeugt Lücken, Maßnahmen ohne vorherige Bewertung führen zu Fehlpriorisierung.
- Umfeldfaktoren identifizieren: Alle Personen, Gruppen und sachlichen Rahmenbedingungen systematisch entlang der vier Kategorien sammeln.
- Nahtstellen bestimmen: Für jeden Faktor festhalten, an welcher Stelle er auf das Projekt trifft und welcher Art dieser Berührungspunkt ist.
- Einfluss und Einstellung bewerten: Jeden Faktor nach Einflussstärke und Haltung zum Projekt einordnen.
- Erwartungen und Befürchtungen erfassen: Dokumentieren, was die jeweiligen Akteure vom Projekt erhoffen und was sie befürchten.
- Maßnahmen und Empfehlungen ableiten: Für relevante Faktoren konkrete Maßnahmen mit Verantwortlichen und Terminen festlegen.
Zur Organisation der Durchführung: Die Analyse ist Teamarbeit, nicht Einzelarbeit der Projektleitung. Perspektivenvielfalt ist das wichtigste Qualitätsmerkmal, weil jeder Beteiligte andere Nahtstellen des Projekts kennt. Bewährt hat sich ein Workshop mit dem Kernteam und zwei bis vier ausgewählten Fachvertretern, etwa aus IT, Einkauf oder dem betroffenen Fachbereich. Für die Erstversion planen Sie einen halben bis ganzen Tag ein, bei komplexen Vorhaben mit vielen Beteiligten eher einen ganzen. Als Moderationsmethoden eignen sich Kartenabfrage und Brainstorming entlang der vier Kategorien, weil beide Formate schnell viele Beiträge sichtbar machen. Dokumentiert wird direkt in der Umfeldmatrix, idealerweise während des Workshops und nicht im Nachgang aus Fotoprotokollen.

1. Wie identifiziert man alle relevanten Umfeldfaktoren?
Die Identifikation entscheidet über die Vollständigkeit der gesamten Analyse. Alles, was hier fehlt, taucht in keinem der folgenden Schritte mehr auf. Deshalb erfolgt sie strukturiert entlang der vier Umfeldkategorien und nicht als freies Brainstorming: Die Kategorien wirken als Checkliste gegen blinde Flecken. Bewährt haben sich folgende Leitfragen:
- Sozial/intern: Wer entscheidet über Budget und Priorität? Wer liefert Zuarbeit, und wer ist von den Ergebnissen im Arbeitsalltag betroffen?
- Sozial/extern: Wer außerhalb der Organisation hat ein Interesse am Ergebnis? Wer kann das Projekt durch Fristen, Auflagen oder Lieferverzug blockieren?
- Sachlich/intern: Welche Systeme, Richtlinien und Parallelvorhaben sind berührt? Welche Budget- und Freigabegrenzen gelten?
- Sachlich/extern: Welche Vorschriften, Normen und Standards sind einzuhalten? Welche Fristen und saisonalen Sperrzeiten sind gesetzt?
Methodisch stützen Sie die Sammlung auf mehrere Quellen: die Kartenabfrage im Workshop (Sammlung von Beiträgen auf Moderationskarten, die anschließend geclustert werden), die Auswertung des Projektauftrags, die Sichtung vergleichbarer Vorprojekte und einen Blick in vorhandene Lessons Learned. In diesem Schritt gilt Vollständigkeit vor Bewertung: Es wird gesammelt, noch nicht gewichtet und noch nichts aussortiert. Was am Ende dieses Schritts vorliegt, ist allerdings nur eine Liste von Namen und Begriffen. Wo genau ein Faktor auf das Projekt trifft, steht dort noch nirgends.
2. Wie bestimmt man die Nahtstellen zwischen Projekt und Umfeld?
Die Nahtstelle ist das Bindeglied zwischen abstraktem Umfeldfaktor und konkreter Projektplanung. Sie bezeichnet den Berührungspunkt zwischen einem Faktor und dem Projekt und beschreibt, wo, wann und wodurch dieser Faktor einwirkt. Wichtig ist die Abgrenzung zum verwandten Begriff der Schnittstelle: Als Schnittstelle wird üblicherweise die technische Verbindung zwischen Systemen bezeichnet, als Nahtstelle die organisatorische Verbindung zwischen Projekt und Umfeld. Nahtstellen werden immer wechselseitig erfasst, also in beide Wirkungsrichtungen: Wie wirkt der Faktor auf das Projekt, und wie wirkt das Projekt auf den Faktor?
- Entscheidungsnahtstellen: Punkte, an denen das Projekt eine Freigabe oder Genehmigung benötigt, etwa die Investitionsfreigabe durch den Lenkungsausschuss.
- Informationsnahtstellen: Punkte des Berichtens und Abstimmens, etwa die monatliche Statusmeldung an das Portfoliogremium.
- Ressourcennahtstellen: Punkte, an denen Personal, Budget oder Räume aus dem Umfeld bezogen werden, etwa die Freistellung eines Fachexperten für Testphasen.
- Leistungsnahtstellen: Punkte der Zulieferung oder technischen Anbindung, etwa die Datenübergabe an ein bestehendes CAD-System.
Planungsrelevant wird eine Nahtstelle erst durch die Verknüpfung mit einem Arbeitspaket oder Meilenstein. Notieren Sie deshalb zu jeder Nahtstelle, an welcher Stelle im Projektstrukturplan sie auftritt und mit welchem Vorlauf sie bedient werden muss. Ohne diese Zuordnung bleibt der Eintrag eine Beobachtung ohne Verbindlichkeit.
3. Wie bewertet man Einfluss und Einstellung der Umfeldfaktoren?
Die Bewertung erfolgt entlang zweier Dimensionen. Die Einflussstärke beschreibt, wie stark ein Faktor den Projektverlauf verändern kann, also die Macht über Ressourcen, Freigaben oder Termine. Die Einstellung zum Projekt beschreibt die Haltung des Faktors gegenüber dem Vorhaben, von unterstützend über neutral bis ablehnend. Bewährt hat sich für den Einfluss eine dreistufige Skala (hoch, mittel, gering) oder eine numerische Skala von 1 bis 5, für die Einstellung eine Skala von stark unterstützend bis stark ablehnend, häufig in Plus-Minus-Notation von ++ bis –. Bei sachlichen Faktoren tritt an die Stelle der Einstellung die Einordnung als Restriktion oder als begünstigende Bedingung.
Die Kombination beider Dimensionen ergibt die Kraftfeldanalyse. Sie stellt die Umfeldfaktoren als Kräfte dar, die auf das Projekt wirken, und macht die Kräfteverhältnisse sichtbar: Faktoren mit hohem Einfluss und ablehnender Haltung sind die kritischsten, Faktoren mit hohem Einfluss und unterstützender Haltung die wertvollsten Verbündeten.
| Einfluss / Einstellung | unterstützend | ablehnend |
|---|---|---|
| hoher Einfluss | Aktiv einbinden und als Fürsprecher nutzen. | Höchste Priorität: intensiv einbinden, Bedenken aufnehmen und adressieren. |
| mittlerer Einfluss | Regelmäßig informieren und punktuell beteiligen. | Im Dialog halten, Argumente sammeln, Eskalation vorbereiten. |
| geringer Einfluss | Über Standardkanäle informieren. | Beobachten und Stimmungsentwicklung im Blick behalten. |
Behandeln Sie diese Einstufungen als Einschätzung, nicht als Messung. Sie entstehen aus der Wahrnehmung der Beteiligten und sollten deshalb im Team vorgenommen und im Zeitverlauf überprüft werden, weil sich insbesondere Einstellungen verändern.
Wo die Bewertung in der Praxis regelmäßig schiefgeht, lässt sich recht genau benennen: bei personenbezogenen und politischen Faktoren. Technische und regulatorische Einflüsse lassen sich meist sachlich einordnen. Bei Stakeholdern mit hoher Entscheidungsmacht, konkurrierenden Interessen oder informellem Einfluss sieht das anders aus. Einträge wie „kritisch gegenüber dem Projekt“ oder „blockiert Entscheidungen“ lassen sich im Team kaum offen festhalten, ohne Konflikte auszulösen. Besser ist es, beobachtbares Verhalten und seine Auswirkungen zu dokumentieren, etwa verzögerte Freigaben, widersprüchliche Anforderungen oder fehlende Ressourcen. Sensible Einschätzungen gehören in den geschützten Austausch der Projektleitung, und dafür braucht es klare Zugriffsrechte. Bei Hermes Arzneimittel sind personenbezogene Daten beispielsweise nur für die beiden Systemadministratoren und den PLANTA-Consultant sichtbar.
Die bewerteten Faktoren bilden anschließend die Grundlage für das Chancen-Risiken-Portfolio, in dem sie nach Auswirkung und Eintrittswahrscheinlichkeit priorisiert werden.
4. Wie erfasst man Erwartungen und Befürchtungen?
Erwartungen und Befürchtungen erklären das Warum hinter der bewerteten Einstellung. Ohne sie bleibt die Bewertung eine Zahl ohne Handlungsansatz: Sie wissen, dass ein Fachbereich ablehnend ist, aber nicht, woran das liegt und womit sich daran etwas ändern lässt.
Erhoben werden diese Informationen über strukturierte Einzelgespräche mit Schlüsselakteuren, moderierte Workshops, kurze Befragungen oder die Auswertung von Aussagen aus Gremiensitzungen. Zu erfassen sind sowohl ausgesprochene als auch vermutete Erwartungen. Vermutete kennzeichnen Sie ausdrücklich als Annahme, also als nicht verifizierte Einschätzung, und überprüfen sie bei nächster Gelegenheit im direkten Gespräch. In Organisationsprojekten kehren dabei typische Befürchtungen wieder: Mehrarbeit während der Umstellung, Kompetenzverlust, Arbeitsplatzunsicherheit, Verlust bewährter Arbeitsweisen und zusätzliche Kontrolle durch neue Systeme.
| Umfeldfaktor | Erwartung an das Projekt | Befürchtung | Quelle |
|---|---|---|---|
| Fertigungsleitung | Stabilere Auftragssteuerung, weniger manuelle Nacharbeit | Produktionsstillstand während der Umstellung | Gespräch 12.03. |
| Betriebsrat | Transparente Regelung zur Datennutzung | Leistungskontrolle einzelner Mitarbeiter | Gremiensitzung |
| Vertriebsinnendienst | Schnellerer Zugriff auf Liefertermine | Zusätzlicher Erfassungsaufwand im Tagesgeschäft | Annahme, noch zu verifizieren |
Die so dokumentierten Inhalte sind die direkte Grundlage für Ihre Kommunikationsinhalte und damit für das Stakeholdermanagement: Jede Befürchtung, die Sie kennen, können Sie adressieren, bevor sie sich in Widerstand übersetzt.
5. Wie leitet man Maßnahmen und Empfehlungen ab?
Mit der Maßnahmentabelle, also der Auflistung aller abgeleiteten Handlungen mit Verantwortlichen und Terminen, wird die Analyse in Projektarbeit überführt. Die Priorisierung folgt der Bewertungsmatrix: Faktoren mit hohem Einfluss erhalten früher und intensiver Maßnahmen als solche mit geringem Einfluss. Vier Maßnahmentypen genügen für die Praxis:
- Informieren: Für Faktoren mit geringem Einfluss, die über Standardkanäle wie Statusberichte oder Intranet auf dem Laufenden gehalten werden.
- Einbinden: Für Faktoren mit hohem Einfluss und unterstützender Haltung, die als Fürsprecher und Entscheidungshelfer aktiviert werden.
- Überzeugen und Bedenken adressieren: Für Faktoren mit hohem Einfluss und ablehnender Haltung, bei denen Einzelgespräche, Pilotierungen und Kompromissangebote gefragt sind.
- Beobachten: Für Faktoren mit geringem Einfluss und unklarer Haltung, bei denen ein Monitoring-Verantwortlicher genügt.
| Umfeldfaktor | Bewertung (Einfluss/Einstellung) | Maßnahme | Verantwortlich | Termin |
|---|---|---|---|---|
| Fertigungsleitung | hoch / ablehnend | Einbindung in Testplanung, Pilotbetrieb einer Linie vereinbaren | Projektleitung | KW 18 |
| Betriebsrat | hoch / neutral bis skeptisch | Betriebsvereinbarung zur Datennutzung vorbereiten | HR-Leitung | KW 22 |
| IT-Administration | mittel / unterstützend | Feste Ansprechpartner und Wartungsfenster abstimmen | IT-Leitung | KW 15 |
Jede Maßnahme braucht einen Verantwortlichen, einen Termin und ein angestrebtes Ergebnis. Maßnahmen ohne benannten Maßnahmenowner werden erfahrungsgemäß nicht umgesetzt. Und noch ein Schritt gehört dazu: Die Maßnahmen fließen als Vorgänge in die Projektplanung ein und werden dort mit Aufwand und Termin hinterlegt, statt als separate Liste neben dem Projektplan zu existieren.
Welche Ergebnisse liefert eine Projektumfeldanalyse?
Die Analyse mündet in vier typische Ergebnisdokumente, die jeweils eine eigene Funktion in der Projektsteuerung erfüllen: Übersicht, Bewertung, Priorisierung und Handlung. Die in den fünf Prozessschritten erarbeiteten Zwischenergebnisse verteilen sich genau auf diese vier Artefakte.
- Umfeldmatrix: Tabellarische Gesamtübersicht aller Umfeldfaktoren mit Kategorie, Nahtstelle, Bewertung und erfassten Erwartungen. Sie ist das Basisdokument, aus dem sich alle weiteren Darstellungen speisen. Wird sie nicht gepflegt, veralten auch die übrigen Artefakte.
- Kraftfeldanalyse: Grafische Darstellung der Faktoren nach Einflussstärke und Haltung, meist als Diagramm mit dem Projekt im Zentrum und Pfeilen unterschiedlicher Stärke und Richtung. Sie macht Kräfteverhältnisse auf einen Blick sichtbar und eignet sich besonders für die Kommunikation mit Lenkungsausschuss und Auftraggeber.
- Chancen-Risiken-Portfolio: Vier-Felder-Darstellung, in der die Umfeldfaktoren nach Eintrittswahrscheinlichkeit und Auswirkung eingeordnet werden. Sie trennt das Wesentliche vom Nebensächlichen und liefert die Priorisierungsgrundlage für das Risikomanagement.
- Maßnahmentabelle: Auflistung aller abgeleiteten Maßnahmen mit Verantwortlichen, Terminen und Status. Sie ist das einzige Dokument mit direkter Verbindlichkeit im Projektalltag und gehört deshalb in jedes Statusmeeting.

Nicht jedes Projekt benötigt alle vier Artefakte. Belastbare Durchschnittswerte dafür, wie viele Umfeldfaktoren pro Projekt erfasst werden, gibt es nicht, dafür sind Projektgrößen und Branchen zu unterschiedlich. Klar ist aber: Der Aufwand muss mit der Projektklasse skalieren. Losan Pharma unterscheidet bei Kundenprojekten beispielsweise drei Kategorien. Von den kleineren C-Projekten laufen rund 35 gleichzeitig, sie werden in PLANTA Project nur mit einem einzigen Vorgang geplant. Bei den B-Projekten laufen 20 bis 25 parallel, meist mit mehreren Vorgängen für das Reporting. Die großen A-Projekte sind Infrastrukturprojekte mit neuen Produktionslinien oder Gebäuden und Budgets in Millionenhöhe, von denen meist fünf gleichzeitig laufen. Übertragen auf die Umfeldanalyse heißt das: Für Projekte der C-Klasse reichen Umfeldmatrix und Maßnahmentabelle, A-Projekte brauchen die vollständige Dokumentation. Wer regelmäßig Projekte startet, legt Umfeldmatrix und Maßnahmentabelle als wiederverwendbare Projektumfeldanalyse-Vorlage im Projekthandbuch ab. Das spart Vorbereitungszeit und macht die Analysen verschiedener Projekte miteinander vergleichbar.
Wie werden die Ergebnisse der Projektumfeldanalyse im Projektmanagement weiterverwendet?
Die Weiterverwendung verbindet die Analyse mit den laufenden Projektmanagement-Prozessen, allen voran mit dem Risikomanagement im Projekt und dem Stakeholdermanagement. Für PMO-Verantwortliche, die diese Übergaben in standardisierten Projektabläufen verankern müssen, lohnt es sich, die Übergabepunkte explizit zu definieren.
| Ergebnis der Projektumfeldanalyse | Zielprozess | Konkrete Weiterverwendung |
|---|---|---|
| Faktoren mit hohem Einfluss und ablehnender Haltung | Risikomanagement | Übernahme ins Risikoregister mit Eintrittswahrscheinlichkeit, Auswirkung und Risikoowner |
| Einflussbewertung und erfasste Erwartungen | Kommunikationsmanagement | Aufbau des Kommunikationsplans mit Zielgruppen, Inhalten, Frequenz und Kanälen |
| Nahtstellen mit Genehmigungs- oder Abstimmungsbedarf | Terminplanung | Aufnahme als Vorgänge mit realistischen Vorlaufzeiten in den Projektplan |
| Interne Ressourcenkonflikte mit Parallelprojekten | Ressourcenplanung | Abstimmung der Kapazitäten im Portfolio und Eskalation offener Konflikte |
| Veränderte Umfeldfaktoren im Projektverlauf | Änderungsmanagement | Auslöser für Change Requests bei geänderten Rahmenbedingungen |
Der Kommunikationsplan ist dabei das Dokument, das festlegt, welche Zielgruppe zu welchem Zeitpunkt über welchen Kanal welche Information erhält. Er lässt sich fast vollständig aus der Umfeldmatrix ableiten. Entscheidend ist, dass diese Übergaben tatsächlich stattfinden und nicht als guter Vorsatz enden. Ohne die Überführung in Risikoregister, Kommunikationsplan und Terminplan bleibt die Analyse ein Dokument ohne Wirkung. Der Übergabeschritt ist der eigentliche Wertbeitrag der Methode.
Wie ernst unsere Kunden diesen Punkt nehmen, zeigt ein Blick in ihre Auswahlprozesse: Bei Siegfried war die Erfassung von Risiken und Chancen innerhalb der Projekte, wie bereits erwähnt, ein ausdrückliches Auswahlkriterium für die Software. Losan Pharma nutzt die Portfolio-Komponente, um Managemententscheidungen bei strategischen Projekten zu unterstützen, etwa durch eine Bewertung von Risiken und Chancen. Welcher Anteil der Umfeldfaktoren am Ende als Risiko im Register landet, hängt vom Projekt ab. Maßgeblich ist, dass die Übergabe systematisch erfolgt.
Beispiel für eine Projektumfeldanalyse
Als Projektumfeldanalyse-Beispiel dient die Einführung eines neuen ERP-Systems (Enterprise Resource Planning, eine integrierte Software zur Steuerung von Warenwirtschaft, Produktion, Finanzen und Personal) in einem mittelständischen Maschinenbauunternehmen mit 400 Mitarbeitern an zwei Standorten und einer geplanten Projektlaufzeit von 18 Monaten. Die folgende Umfeldmatrix durchläuft alle fünf Analyseschritte anhand dieses Falls: Sie benennt die Faktoren, ihre Nahtstellen und Bewertungen, dokumentiert für jeden Faktor Erwartung und Befürchtung und leitet daraus die Maßnahme ab. Bei sachlichen Faktoren stehen dabei die Erwartungen und Befürchtungen der jeweils verantwortlichen Stelle.
| Umfeldfaktor | Kategorie | Nahtstelle | Einfluss | Einstellung | Erwartung/Befürchtung | Maßnahme |
|---|---|---|---|---|---|---|
| Geschäftsführung | sozial/intern | Budgetfreigabe, Projektpriorisierung im Portfolio | hoch | unterstützend | Erwartung: messbar kürzere Durchlaufzeiten in der Auftragsabwicklung. Befürchtung: Budgetüberschreitung durch nachträgliches Customizing. | Monatliches Steuerungsmeeting, Sponsor sichtbar auftreten lassen |
| Fertigungsleitung | sozial/intern | Abnahme der Produktionsmodule, Freigabe der Testphasen | hoch | ablehnend | Erwartung: stabilere Auftragssteuerung, weniger manuelle Nacharbeit. Befürchtung: Produktionsstillstand während der Umstellung. | Frühe Einbindung in die Testplanung, Pilotbetrieb in einer Linie |
| Betriebsrat | sozial/intern | Mitbestimmung bei Leistungsdatenerfassung | hoch | neutral bis skeptisch | Erwartung: transparente Regelung zur Datennutzung. Befürchtung: Leistungskontrolle einzelner Mitarbeiter. | Betriebsvereinbarung mit sechs Monaten Vorlauf verhandeln |
| ERP-Anbieter und Implementierungspartner | sozial/extern | Lieferung, Customizing, Schulung | hoch | unterstützend | Erwartung: verbindliche Entscheidungen und feste Ansprechpartner im Projekt. Befürchtung: verzögerte Freigaben und Nachforderungen im Scope. | Vertraglich fixierte Meilensteine, wöchentlicher Jour fixe |
| Schlüsselkunden | sozial/extern | Auftragsbestätigungen und Liefertermine rund um den Go-live | mittel | neutral | Erwartung: unveränderte Liefertermintreue. Befürchtung: verzögerte Auftragsbestätigungen in den ersten Wochen nach der Umstellung (Annahme, noch zu verifizieren). | Kunden vorab über das Go-live-Fenster informieren, Ersatzprozess für Auftragsbestätigungen vorhalten |
| Bestehende IT-Systemlandschaft | sachlich/intern | Schnittstellen zu CAD- und PPS-System | hoch | Restriktion | Erwartung der IT-Leitung: Ende der Doppelpflege von Stammdaten. Befürchtung: instabile Schnittstellen und hoher Nachbesserungsaufwand nach dem Go-live. | Schnittstellenspezifikation vor Realisierungsstart abschließen |
| Parallelprojekt Werkserweiterung Standort 2 | sachlich/intern | Konkurrenz um IT-Ressourcen und Projektbudget | mittel | neutral | Erwartung der dortigen Projektleitung: verbindlich zugesagte IT-Kapazitäten. Befürchtung: Abzug von IT-Personal zugunsten der ERP-Einführung. | Ressourcenabstimmung im Portfoliogremium, Kapazitäten fixieren |
| DSGVO-Anforderungen | sachlich/extern | Verarbeitung personenbezogener Daten im HR-Modul | hoch | Restriktion | Erwartung des Datenschutzbeauftragten: dokumentierte Berechtigungs- und Löschkonzepte. Befürchtung: nachträgliche Anpassungen nach der Datenschutzprüfung. | Datenschutzbeauftragten ab Konzeptphase einbinden |
| Betriebsferien und Jahresabschluss | sachlich/extern | Sperrzeiten für den Go-live | mittel | Restriktion | Erwartung des Finanzbereichs: Go-live außerhalb der Abschlussarbeiten. Befürchtung: Datenmigration parallel zum Abschlussstichtag. | Go-live-Fenster außerhalb der Sperrzeiten festlegen |
Die Auswertung zeigt eine klare Prioritätenfolge. Höchste Aufmerksamkeit erhalten die Faktoren mit hohem Einfluss und ablehnender oder skeptischer Haltung, also Fertigungsleitung und Betriebsrat. Die Spalte Erwartung/Befürchtung erklärt, woran diese Haltung hängt: die Sorge um einen Produktionsstillstand auf der einen, die Sorge um Leistungskontrolle auf der anderen Seite. Genau dort setzen die Maßnahmen an, mit frühzeitiger Einbindung in die Testplanung, einem Pilotbetrieb in nur einer Fertigungslinie, verbindlich dokumentierten Rückfallszenarien für den Go-live und einer früh verhandelten Betriebsvereinbarung. Beim Betriebsrat zahlt sich zudem aus, den Zugriff auf personenbezogene Daten im System von Beginn an klar zu begrenzen – ein Vorgehen, wie es auch unser Kunde Hermes Arzneimittel umgesetzt hat. Bei den sachlichen Faktoren liefert dieselbe Spalte die inhaltliche Begründung für Vorlaufzeiten: Schnittstellenspezifikation vor Realisierungsstart, Datenschutzkonzepte ab der Konzeptphase, Go-live außerhalb von Betriebsferien und Abschlussarbeiten. Aus dieser Analyse folgen zwei konkrete Konsequenzen für die Projektplanung: ein zusätzlicher Zeitpuffer vor dem Go-live und ein eigener Vorgang für die Betriebsvereinbarung mit einer realistischen Vorlaufzeit von rund sechs Monaten. Die Kraftfeldanalyse zu diesem Fall würde zeigen, dass den beiden bremsenden Kräften mit Geschäftsführung und Implementierungspartner zwei starke unterstützende Kräfte gegenüberstehen, die sich gezielt einsetzen lassen.
Die Spaltenstruktur dieser Tabelle können Sie unverändert als Projektumfeldanalyse-Vorlage für eigene Projekte übernehmen, ergänzt um die Spalten Verantwortlicher und Termin aus der Maßnahmentabelle. Standardisieren Sie diese Vorlage im Projekthandbuch. Nur dann bleiben Analysen zwischen Projekten vergleichbar, und wiederkehrende Umfeldfaktoren fallen über mehrere Vorhaben hinweg auf.
Welche Fehler treten bei der Projektumfeldanalyse häufig auf?
Die häufigsten Fehler entstehen nicht aus methodischer Unkenntnis, denn die Methode ist einfach und in jedem PM-Lehrbuch beschrieben. Sie entstehen aus Abkürzungen im Vorgehen, meist unter Zeitdruck beim Projektstart. Und jede dieser Abkürzungen hat eine konkrete Folge im weiteren Projektverlauf.
- Beschränkung auf Personen und Gruppen: Sachliche Faktoren wie Normen, Genehmigungspflichten oder Systemabhängigkeiten bleiben unentdeckt. Sie treffen das Projekt dann in der Realisierung ungebremst, wenn kein Handlungsspielraum mehr besteht. Gegenmaßnahme: alle vier Kategorien als verbindliche Checkliste abarbeiten und leere Felder ausdrücklich begründen.
- Einmalige Erstellung ohne Aktualisierung: Veränderte Haltungen, neue Akteure oder geänderte Rahmenbedingungen bleiben unbemerkt, und die Analyse beschreibt einen Zustand, den es nicht mehr gibt. Gegenmaßnahme: feste Aktualisierungstermine zu jedem Phasenübergang im Projektplan verankern, idealerweise als Checklistenpunkt in der Phasenfreigabe.
- Analyse allein durch die Projektleitung: Die Sicht eines Einzelnen erzeugt systematische blinde Flecken, gerade bei Fachbereichen, mit denen wenig Kontakt besteht. Gegenmaßnahme: Workshop mit Kernteam und ausgewählten Fachvertretern.
- Bewertung ohne Begründung: Einstufungen ohne dokumentierte Erwartungen und Befürchtungen lassen sich später nicht überprüfen und liefern keinen Handlungsansatz. Gegenmaßnahme: zu jeder Bewertung mindestens einen Grund dokumentieren, auch wenn er nur eine Annahme ist. Bei heiklen Personen hilft es, beobachtbares Verhalten statt Wertungen festzuhalten.
- Keine Maßnahmenableitung: Die Analyse endet als Dokument in der Projektablage und entfaltet keinerlei Wirkung auf die Projektarbeit. Gegenmaßnahme: jede Maßnahme mit Verantwortlichem und Termin in die Projektplanung überführen, nicht in eine separate Liste.
- Nur negative Faktoren erfassen: Unterstützende Akteure und günstige Rahmenbedingungen bleiben ungenutzt, obwohl sie im Konfliktfall die stärkste Hebelwirkung haben. Gegenmaßnahme: Chancen gleichrangig erfassen und Fürsprecher aktiv einbinden.
- Übermäßiger Detaillierungsgrad: Eine Analyse mit 80 Faktoren wird nach dem ersten Update nicht mehr gepflegt und verliert ihre Steuerungsfunktion. Gegenmaßnahme: auf die planungsrelevanten Faktoren fokussieren und Randfaktoren bewusst und dokumentiert ausklammern.

Für PMO-Verantwortliche, die Standards für mehrere Projekte setzen, lohnt ein genauer Blick auf die beiden häufigsten Fehler: fehlende Aktualisierung und fehlende Überführung in die Projektplanung. Beide haben dieselbe Wurzel. Sie treten auf, wenn die Analyse getrennt von der übrigen Projektdokumentation geführt wird, meist in einer Datei auf einem Laufwerk, die niemand öffnet, weil sie nicht Teil des Arbeitsablaufs ist.
Wie unterstützt Projektmanagement-Software die Projektumfeldanalyse?
Methodisch funktioniert eine Projektumfeldanalyse auch mit Tabellenkalkulation. Ihre Steuerungswirkung entfaltet sie allerdings erst dann, wenn Umfeldfaktoren, Maßnahmen und Projektplanung in derselben Projektmanagement-Software geführt werden. Manuell gepflegte Dateien liegen getrennt von der Planung, veralten schnell und lassen sich über mehrere Projekte hinweg nicht auswerten. Fünf Funktionen sind für die Unterstützung der Methode relevant:
- Zentrale Erfassung und Kategorisierung: Umfeldfaktoren werden strukturiert nach den vier Kategorien erfasst und bleiben für alle Berechtigten an einer Stelle auffindbar.
- Verknüpfung mit dem Risikomanagement: Kritische Umfeldfaktoren werden als Risiko im selben System geführt, statt in einer separaten Datei.
- Maßnahmenverfolgung mit Verantwortlichen und Terminen: Abgeleitete Maßnahmen werden zu terminierten Aufgaben mit Status statt zu Zeilen in einer Liste.
- Projektübergreifende Auswertung: Wiederkehrende Faktoren und Engpässe werden über mehrere Projekte hinweg sichtbar.
- Nachvollziehbarkeit und Zugriffsrechte: Änderungen an Stakeholder-Daten werden mit Änderungsdatum und Bearbeiter dokumentiert. Über die differenzierte Rechtevergabe lässt sich zudem steuern, welche Benutzer auf Projekte und die darin enthaltenen Stakeholderinformationen zugreifen oder diese bearbeiten dürfen.
Mit PLANTA Project steht Ihnen eine Projektmanagement-Software für Einzel- und Multiprojektmanagement zur Verfügung, die klassische, agile und hybride Projektmanagement-Methoden in einem System vereint. Gerade dieser hybride Ansatz passt zur Umfeldanalyse: Sie starten mit einer strukturierten Erstanalyse und führen die Ergebnisse anschließend in klassischen Phasen oder agilen Iterationen weiter, ohne das System zu wechseln. Entwickelt wird die Lösung durchgehend in Karlsruhe, als Software made in Germany.
Im Kontext der Umfeldbetrachtung heißt das konkret: Umfeldfaktoren lassen sich zusammen mit den daraus abgeleiteten Risiken und Maßnahmen im Projekt dokumentieren und mit dem Risikomanagement verknüpfen. Die abgeleiteten Maßnahmen führen Sie als terminierte Aufgaben mit Verantwortlichen und verfolgen ihren Fortschritt im Projektstatus mit. Ressourcenkonflikte mit Parallelprojekten, einer der wichtigsten internen Umfeldfaktoren im Multiprojektmanagement, werden über die projektübergreifende Ressourcenplanung sichtbar, bevor sie zum Terminproblem werden. Damit die Fortschreibung nicht allein von der Disziplin Einzelner abhängt, können PMO und Multiprojektmanagement in PLANTA zentral nachvollziehen, für welche Projekte seit einem definierten Zeitpunkt kein Statusbericht vorliegt. Quality Gates verankern Kontrollen zusätzlich an festen Projektzeitpunkten.

Das Funktionsprinzip dahinter ist eine zentrale Datenhaltung über alle Projekte hinweg statt getrennter Einzeldateien. Echtzeit-Übersichten und Frühwarnfunktionen zeigen Abweichungen an, bevor sie den Terminplan treffen. Anpassbare Workflows bilden Ihre unternehmenseigenen Freigabe- und Abstimmungsprozesse ab, etwa den Genehmigungsweg für Maßnahmen mit Budgetwirkung oder – wie bei Losan Pharma – einen kompletten PM-Leitfaden mit Checklisten und Phasenfreigaben. Zugriffsrechte lassen sich so fein vergeben, dass sensible Einschätzungen nur einem kleinen Kreis zugänglich sind. Für Sie als Projektmanager oder PMO-Verantwortlichen ergeben sich daraus vier praktische Vorteile:
- Umfeldfaktoren, Risiken und Maßnahmen liegen in einem System statt in verstreuten Dateien.
- Aktualisierungen sind für alle Beteiligten sofort sichtbar, ohne Versandschleifen.
- Die projektübergreifende Auswertung deckt wiederkehrende Umfeldfaktoren und Ressourcenkonflikte auf.
- Der Betrieb ist wahlweise On-Premises oder als Cloud-/SaaS-Version möglich.
Weiterführende Produktinformationen zu PLANTA Project und PLANTA Enterprise finden Sie in der Produktübersicht. Einen Überblick über alle Preisoptionen beider Editionen erhalten Sie in unserer Preisübersicht. Dort können Sie auch einen kostenlosen Termin vereinbaren, in dem Ihr persönliches Testsystem eingerichtet wird.
Fazit zur Definition und Durchführung einer Projektumfeldanalyse
Vier Umfeldkategorien, fünf Prozessschritte, vier Ergebnisdokumente und eine Aktualisierung, die zur Daueraufgabe wird: Das ist das methodische Gerüst der Projektumfeldanalyse. Einflussfaktoren werden durch die systematische Umfeldbetrachtung planbar, weil sie benannt, bewertet und mit einer Nahtstelle zum Projekt versehen sind. Wer dabei nur Personen betrachtet, übersieht die sachlichen Restriktionen des Projekts, also genau jene Vorschriften, Systemabhängigkeiten und Fristen, die sich später nicht mehr verhandeln lassen. Der Wert der Analyse hängt zudem an ihrer frühen Erstellung und regelmäßigen Fortschreibung. Und er entsteht nicht durch das Dokument selbst, sondern durch die Maßnahmen, die daraus in die Projektarbeit übergehen.
Für die Praxis ergeben sich drei Anwendungskontexte, die sich in jeder Organisation verankern lassen: die Erstanalyse im Projektstart-Workshop, die Aktualisierung zu jedem Phasenübergang und die Standardisierung der Umfeldmatrix als Vorlage im Projekthandbuch. Ein pragmatischer Einstieg gelingt schon mit einer schlichten Umfeldmatrix, die die vier Kategorien abfragt und eine Maßnahmenspalte enthält. Die Detailtiefe skalieren Sie anschließend mit der Projektgröße, von der Ein-Seiten-Übersicht bis zur vollständigen Maßnahmentabelle mit Statusverfolgung. Wer mehrere Projekte parallel steuert, führt Umfeldfaktoren, Risiken und Maßnahmen sinnvollerweise zentral in einer Projektmanagement-Software statt in verteilten Einzeldateien – und bindet die Fortschreibung an Statusberichte und Quality Gates, damit sie auch im hektischen Projektalltag nicht untergeht.
Häufig gestellte Fragen zur Projektumfeldanalyse
Wer ist für die Projektumfeldanalyse verantwortlich?
Die Verantwortung liegt bei der Projektleitung, die Durchführung erfolgt jedoch gemeinsam mit dem Kernteam und ausgewählten Fachvertretern. In größeren Organisationen unterstützt das PMO durch standardisierte Vorlagen, die Moderation der Workshops und die Sicherung der Vergleichbarkeit zwischen Projekten.
Welche Vorlage eignet sich für eine Projektumfeldanalyse?
Bewährt hat sich eine Tabellenvorlage mit den Spalten Umfeldfaktor, Kategorie, Nahtstelle, Einfluss, Einstellung, Erwartung/Befürchtung und Maßnahme. Bei Projekten mit vielen Beteiligten lohnt sich ergänzend eine Kraftfeldanalyse als grafische Übersicht für die Kommunikation mit Auftraggeber und Gremien.
Welche Maßnahmen leitet man aus der Projektumfeldanalyse ab?
Typische Maßnahmen sind Informieren, Einbinden, Überzeugen und Beobachten, abhängig von Einflussstärke und Haltung des jeweiligen Umfeldfaktors. Jede Maßnahme braucht einen Verantwortlichen und einen Termin, sonst bleibt sie wirkungslos und taucht im nächsten Statusbericht unverändert wieder auf.
Related Posts
LETZTE BEITRÄGE
Was ist eine Projektumfeldanalyse? Erklärung, Prozess und Beispiel
Beate Schulte2026-11-10T20:42:45+00:0011. November 2026|
KI im Risikomanagement: Wie KI Projektrisiken erkennt und wo der Mensch entscheidet
Beate Schulte2026-11-10T14:19:06+00:0029. Oktober 2026|
SMART im Projektmanagement: Bedeutung, Kriterien, Formulierung und Beispiele
Beate Schulte2026-10-25T15:09:38+00:0026. Oktober 2026|



