Block 04 · Projektmanagement

A · Erklärungssatz

Projektmanagement steht seit Sommer 2023 in jeder Prüfung als Teil 1, Aufgabe 1 (20–30 Punkte). Die Aufgabe beginnt mit einer kurzen Situation („Sie arbeiten in der Projektplanung mit …“) und fragt dann 2–4 Unterthemen ab: meist Stakeholder oder Projektbegriffe, dazu Risiko, Vorgehensmodell oder Anforderungen. Gerechnet wird selten – mit einer Ausnahme: der Netzplan in S26 mit 19 Punkten. Notationshilfen gibt es für Projektmanagement im Belegsatz nicht; alles, was du brauchst, steht in der Aufgabe oder muss gelernt sein.

Operatoren und Antworttechnik für Textaufgaben

Weil fast alles in Projektmanagement Text ist, entscheidet die Antworttiefe über die Punkte. Der Operator gibt sie vor:

PM-01 · Stakeholder und Projektbegriffe Meistens

Vorkommen: 7/9 · Prüfungen: S22, S23, W23, S24, W24, W25, S26 (immer Teil 1, Aufgabe 1)

Durchgehendes Beispiel im Erklärungssatz: Die Stadtbibliothek Ahlenfeld lässt von einem IT-Dienstleister die App „LeseKompass“ entwickeln (Katalogsuche, Ausleihkonto, Verlängern, Vormerken, Push-Erinnerungen) und führt gleichzeitig Selbstverbuchungsterminals ein.

Was ist ein Projekt?

Nach DIN 69901-5 ist ein Projekt ein Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist. In der Prüfung reicht es, die Merkmale zu kennen und am Szenario zu belegen:

Kein Projekt ist dagegen eine Routinetätigkeit (z. B. der monatliche Mahnlauf): Sie wiederholt sich und hat kein festes Ende.

Magisches Dreieck

Projektphasen und wichtige Begriffe

Phasen nach DIN 69901: Initialisierung (Idee, Machbarkeit, Projektauftrag) → Definition (Ziele, Anforderungen, Stakeholder, Grobplanung) → Planung (Projektstrukturplan, Termine, Kosten, Risiken) → Steuerung (Durchführung, Controlling, Änderungen) → Abschluss (Abnahme, Abschlussbericht, Lessons Learned).

Stakeholder und Stakeholder-Analyse

Stakeholder (Projektbeteiligte und -betroffene) sind alle Personen, Gruppen oder Organisationen, die am Projekt beteiligt sind, vom Projekt oder seinem Ergebnis betroffen sind oder Einfluss darauf nehmen können – intern (Geschäftsführung, Fachabteilung, Mitarbeitende, Betriebs- oder Personalrat, IT-Abteilung, Projektteam) und extern (Kunden, Nutzer, Lieferanten, Dienstleister, Behörden, Verbände, Öffentlichkeit).

So gehst du vor (Stakeholder-Analyse):

1. Identifizieren: Wer zahlt? Wer nutzt das System? Wer muss zustimmen? Wer verliert etwas? Wer liefert zu? (Brainstorming, Organigramm, Checkliste)
2. Analysieren: je Stakeholder Interessen/Erwartungen, Befürchtungen, Einfluss (Macht, Entscheidungs- oder Vetorecht) und Einstellung (positiv, neutral, negativ).
3. Einordnen: in eine Stakeholder-Matrix (Abb. A-2).
4. Maßnahmen planen: einbinden, informieren, überzeugen, beobachten – passend zur Befürchtung.
5. Laufend überprüfen: Einstellungen ändern sich im Projektverlauf.

Eine verbreitete Variante ordnet nach Einfluss × Interesse: hoher Einfluss und hohes Interesse → eng einbinden; hoher Einfluss, geringes Interesse → zufriedenstellen; geringer Einfluss, hohes Interesse → informieren; beides gering → beobachten.

Projekterfolg nach Projektende prüfen

Der Projekterfolg wird an den vorher festgelegten Zielen gemessen. Deshalb sollten Ziele SMART sein: spezifisch, messbar, akzeptiert/attraktiv, realistisch, terminiert – z. B. „Bis 31.12. werden mindestens 30 % aller Ausleihen über die Terminals abgewickelt.“ Möglichkeiten zur Erfolgsprüfung:

• Soll-Ist-Vergleich der Projektziele und des magischen Dreiecks: Leistung erreicht? Termin eingehalten? Budget eingehalten?
• Abnahme anhand der vereinbarten Anforderungen (Lasten-/Pflichtenheft), Abnahmeprotokoll mit Mängelliste.
• Kennzahlen nach der Einführung messen (z. B. nach drei Monaten): Nutzungsquote, Bearbeitungszeit, Fehlerquote, Anzahl Supportanfragen.
• Zufriedenheit von Auftraggeber und Nutzern erheben (Umfrage, Feedbackgespräch).
• Wirtschaftlichkeit nachrechnen: tatsächliche Einsparungen, Amortisation.
• Projektabschlussbericht und Lessons-Learned-Workshop.

PM-02 · Agile Vorgehensweisen, Scrum, User Stories Oft

Vorkommen: 5/9 · Prüfungen: S22, W22, W23, W24, W25 · in W23 mit englischem Fachtext zu User Stories

Agiles Manifest (2001)

Vier Werte – jeweils ist die linke Seite wichtiger als die rechte, die rechte ist aber nicht wertlos:

Aus den zwölf Prinzipien (sinngemäß): früh und regelmäßig wertvolle Software ausliefern; Änderungen auch spät willkommen heißen; kurze Lieferzyklen von wenigen Wochen; Fachleute und Entwickler arbeiten täglich zusammen; Gespräch von Angesicht zu Angesicht; funktionierende Software ist das wichtigste Fortschrittsmaß; gleichmäßiges, nachhaltiges Tempo; Einfachheit; selbstorganisierte Teams; regelmäßige Reflexion und Anpassung.

Scrum im Überblick

Scrum ist ein Rahmenwerk für iterativ-inkrementelle Entwicklung. Gearbeitet wird in Sprints fester Länge (höchstens ein Monat, oft zwei Wochen). Am Ende jedes Sprints steht ein nutzbares Increment.

* Höchstdauer bei einem Monat Sprintlänge, in Klammern übliche Werte bei zwei Wochen. Backlog Refinement (Einträge verfeinern, aufteilen, schätzen) ist eine laufende Tätigkeit, kein eigenes Event.

Definition of Done (DoD) und Akzeptanzkriterien werden gern verwechselt: Die DoD gilt für alle Einträge gleich (z. B. „Code-Review erfolgt, Unit-Tests grün, auf Testsystem installiert, Hilfetext aktualisiert“). Akzeptanzkriterien gelten nur für eine User Story und beschreiben fachlich, wann sie erfüllt ist. Manche Teams nutzen zusätzlich eine Definition of Ready: Wann ist ein Eintrag so klar, dass er in einen Sprint darf?

Kanban

User Stories

Eine User Story beschreibt eine Anforderung kurz aus Sicht eines Nutzers, mit dem Nutzen, den sie bringt. Standardformat (Rolle – Ziel – Nutzen):

Als <Rolle> möchte ich <Ziel / Funktion>, damit <Nutzen>.

Beispiel: „Als Leserin möchte ich meine Ausleihen in der App verlängern, damit ich keine Säumnisgebühren zahlen muss.“ Akzeptanzkriterien dazu:

• Verlängern ist nur möglich, wenn das Medium nicht von jemand anderem vorgemerkt ist.
• Nach dem Verlängern zeigt die App das neue Rückgabedatum an.
• Ein Medium kann höchstens zweimal verlängert werden; danach ist die Schaltfläche ausgegraut.

Akzeptanzkriterien kann man auch im Schema Gegeben … wenn … dann … (Given – When – Then) schreiben. Eine User Story besteht nach Ron Jeffries aus den „3 C“: Card (kurzer Text auf einer Karte), Conversation (Details werden im Gespräch geklärt), Confirmation (Akzeptanzkriterien bestätigen, dass sie erfüllt ist).

Ist eine Story zu groß, heißt sie Epic und wird aufgeteilt, z. B. nach Teilschritten eines Ablaufs, nach Rollen, nach Datenvarianten oder nach Operationen (anlegen / ändern / löschen).

Aus einem Use-Case-Diagramm User Stories ableiten (W23): Akteur → Rolle, Anwendungsfall → Ziel/Funktion, den Nutzen selbst ergänzen. Ein Use Case beschreibt die Interaktion zwischen Akteur und System (mit Ablauf und Varianten), eine User Story nur kurz Wunsch und Nutzen.

Story Points schätzen den Umfang einer Story relativ zu anderen (Aufwand, Komplexität, Unsicherheit), nicht in Stunden. Üblich ist eine Fibonacci-ähnliche Skala (1, 2, 3, 5, 8, 13, 20 …): Je größer die Zahl, desto größer die Unsicherheit. Beim Planning Poker legen alle Developers gleichzeitig verdeckt eine Karte; wer am weitesten abweicht, begründet, dann wird erneut geschätzt, bis Einigkeit besteht. Die Velocity (pro Sprint erledigte Story Points) hilft, künftige Sprints zu planen. Relativ wird geschätzt, weil Menschen Vergleiche („doppelt so groß wie …“) zuverlässiger treffen als absolute Zeiten und weil die Schätzung nicht von der Geschwindigkeit einzelner Personen abhängt.

PM-03 · Anforderungen Oft ↓

Vorkommen: 5/9 · Prüfungen: S22, W22, S23, W23, S24 · in den letzten drei Prüfungen nicht mehr als eigene Teilaufgabe

Funktionale und nicht-funktionale Anforderungen

• Funktionale Anforderungen beschreiben, was das System tun soll: Funktionen, Verhalten, Ein- und Ausgaben, Daten. Prüffrage: „Kann das System das – ja oder nein?“
• Nicht-funktionale Anforderungen beschreiben, wie gut bzw. unter welchen Bedingungen es das tut: Qualitätseigenschaften (Leistung, Benutzbarkeit, Sicherheit, Zuverlässigkeit, Wartbarkeit …) und Randbedingungen (rechtlich, technisch, organisatorisch).

Messbar formulieren: Eine Anforderung ist erst dann gut, wenn man sie bei der Abnahme prüfen kann. Hilfreich ist eine Satzschablone: „Das System muss/soll/kann <wem?> die Möglichkeit bieten, <Objekt> <Tätigkeit>.“

Weitere Qualitätsmerkmale guter Anforderungen: eindeutig, vollständig, widerspruchsfrei, realisierbar, notwendig und verfolgbar (Nummer, Quelle).

Lastenheft und Pflichtenheft

Anforderungen erheben

Priorisieren mit MoSCoW

PM-04 · Risikoanalyse Oft ↑

Vorkommen: 4/9 · Prüfungen: S23, S24, W25, S26 · steigender Trend

Ein Risiko ist ein mögliches künftiges Ereignis, das mit einer gewissen Wahrscheinlichkeit eintritt und dann die Projektziele (Termin, Kosten, Leistung/Qualität) negativ beeinflusst. Ein Problem ist ein Risiko, das bereits eingetreten ist. Das positive Gegenstück heißt Chance.

Gute Risikobeschreibung = Ursache → Ereignis → Auswirkung: „Weil der Hersteller des Bibliothekssystems nur einen Schnittstellen-Entwickler hat (Ursache), kann die Schnittstelle verspätet geliefert werden (Ereignis), wodurch sich der Start der Selbstverbuchung um Wochen verschiebt (Auswirkung).“

Risikomanagement-Prozess

1. Identifizieren – Brainstorming, Checklisten/Risikokataloge, Expertenbefragung, Lessons Learned früherer Projekte, Stakeholder-Analyse, Annahmen des Projektplans hinterfragen.
2. Analysieren und bewerten – Eintrittswahrscheinlichkeit (EW) und Schadensausmaß (S) schätzen, Risikowert bilden, in Risikomatrix einordnen.
3. Maßnahmen planen – Strategie wählen (siehe unten), Verantwortlichen festlegen.
4. Überwachen und steuern – Risikoliste regelmäßig (z. B. in jedem Statusmeeting) aktualisieren: neue Risiken, veränderte Bewertungen, Wirkung der Maßnahmen. Risikomanagement ist ein laufender Prozess.

Bewerten: Risikowert und Risikomatrix

Risikowert = Eintrittswahrscheinlichkeit × Schadensausmaß. Qualitativ mit Punkteskalen (z. B. jeweils 1–5), quantitativ mit Prozent und Euro: 20 % × 30.000 € = 6.000 € erwarteter Schaden (Grundlage für ein Risikobudget).

Strategien zur Risikobehandlung

Zusätzlich unterscheidet man präventive Maßnahmen (vor Eintritt, wirken auf die EW) und korrektive Maßnahmen bzw. Notfallpläne (nach Eintritt, begrenzen den Schaden). Nach einer Maßnahme wird das Restrisiko neu bewertet.

PM-05 · Klassische Vorgehensmodelle und Prototyping Wahrscheinlich

Vorkommen: 3/9 · Prüfungen: S22, W24, W25 (zusätzlich Prototyping in W25 T1 A3c)

Vorgehensmodelle lassen sich in zwei Kategorien einteilen: klassische (sequenzielle, plangetriebene) Modelle wie Wasserfall- und V-Modell und agile (iterativ-inkrementelle) Vorgehensweisen wie Scrum, Kanban oder Extreme Programming. Dazwischen liegen iterative Modelle (Spiralmodell, inkrementelles Modell, Prototyping) und hybride Ansätze.

Wasserfallmodell

Die Phasen laufen nacheinander ab; jede endet mit einem Ergebnisdokument (Meilenstein), das die nächste Phase freigibt.

Vorteile: klare Struktur, gut planbar (Termine, Kosten, Festpreis), gut dokumentiert, einfach zu steuern; geeignet bei stabilen, vollständig bekannten Anforderungen (z. B. gesetzlich vorgegebene Formate).

Nachteile: Anforderungen müssen zu Beginn vollständig bekannt sein; Fehler werden erst spät im Test entdeckt; Änderungen sind teuer; der Kunde sieht ein lauffähiges Ergebnis erst am Ende.

V-Modell

Das V-Modell erweitert den Wasserfall um eine Teststufe für jede Entwurfsstufe. Links wird von grob nach fein spezifiziert, rechts von fein nach grob getestet. Die Testfälle werden schon in der jeweiligen Entwurfsphase festgelegt. In Deutschland ist das V-Modell XT Standard für IT-Projekte des Bundes.

Verifikation: Wird das Produkt richtig gebaut (entspricht es der Spezifikation)? Validierung: Wird das richtige Produkt gebaut (erfüllt es den Zweck des Kunden)?

Spiralmodell, inkrementell, iterativ

Das Spiralmodell (Boehm) ist risikogetrieben: Das Projekt durchläuft mehrere Zyklen; jeder Zyklus hat vier Quadranten (Abb. A-8). Vor jeder Entwicklung werden die größten Risiken analysiert und z. B. mit Prototypen reduziert. Geeignet für große, riskante Vorhaben; Nachteil: hoher Planungs- und Steuerungsaufwand.

Inkrementell: Das Produkt wird in Ausbaustufen geliefert; jede Stufe ist nutzbar und erweitert den Funktionsumfang (Katalog → Ausleihkonto → Mahnwesen).

Iterativ: Ein Ergebnis wird in wiederholten Durchläufen verfeinert und verbessert. Scrum ist iterativ und inkrementell.

Prototyping

Ein Prototyp ist ein früh erstelltes, vereinfachtes Modell des Systems (klickbar oder lauffähig), mit dem Anforderungen geklärt oder die technische Machbarkeit geprüft werden.

Vorteile: frühes Feedback der Nutzer, Missverständnisse werden früh erkannt, Nutzer werden eingebunden (Akzeptanz), Risiken sinken. Nachteile/Risiken: zusätzlicher Aufwand; der Kunde hält den Prototyp für fast fertig (falsche Erwartungen an Termin und Kosten); Wegwerf-Code wird aus Zeitdruck doch übernommen; Dokumentation wird vernachlässigt.

Das passende Vorgehen wählen

PM-06 · Change-Management und Akzeptanz Sonstige

Vorkommen: 3/9 · Prüfungen: S22, S23, W23 · eng verwandt mit der Stakeholder-Analyse (PM-01)

Neue Software verändert Arbeitsabläufe – Widerstand der Betroffenen ist normal und meist berechtigt aus deren Sicht. Ziel des Change-Managements: Betroffene zu Beteiligten machen, damit das System später wirklich genutzt wird.

Betriebsrat: Bei der Einführung technischer Einrichtungen, die dazu geeignet sind, Verhalten oder Leistung der Beschäftigten zu überwachen, hat der Betriebsrat ein Mitbestimmungsrecht (§ 87 Abs. 1 Nr. 6 BetrVG). Ohne seine Zustimmung darf das System nicht eingeführt werden. Ergebnis ist meist eine Betriebsvereinbarung (Zweck, gespeicherte Daten, Zugriffsrechte, Auswertungsverbot, Löschfristen). Im öffentlichen Dienst übernimmt der Personalrat diese Rolle.

Workshop gegen Widerstände – mögliche Ziele: über Ziele, Gründe und Nutzen informieren; die Folgen des Status quo bewusst machen; Erwartungen und Befürchtungen sammeln und ernst nehmen; Betroffene an der Gestaltung beteiligen; Befürworter, Unentschlossene und Gegner erkennen; Befürworter als Multiplikatoren stärken; konkrete nächste Schritte vereinbaren.

Pilotbetrieb mit einer kleinen Gruppe: Vorteile – Erfahrungen unter realen Bedingungen, Fehler vor dem flächendeckenden Start beheben, Erfolgsbeispiele und Multiplikatoren, begrenztes Risiko. Nachteile – zeitweise Doppelstrukturen, Pilotgruppe evtl. nicht repräsentativ, längere Gesamtdauer.

Konflikte lösen: Ursache klären (Sach-, Beziehungs-, Ziel-, Verteilungs- oder Rollenkonflikt); früh das persönliche Gespräch suchen; Interessen statt Positionen betrachten („Was brauchen Sie, damit …?“); gemeinsame Lösung (Win-win) statt Machtwort; bei Bedarf neutrale Moderation; Eskalation an die Leitung erst als letzter Schritt. Beispiel: Eine Thekenkraft der Bibliothek fürchtet, durch die Selbstverbuchung überflüssig zu werden → Gespräch mit der Leitung, verbindliche Zusage, neue Rolle in Leseberatung und Veranstaltungen, Schulung dafür.

PM-07 · Kosten, Make-or-Buy, Nutzwertanalyse Sonstige ↓

Vorkommen: 2/9 · Prüfungen: S22 (Make-or-Buy), S23 (Kostenarten) · klassische Kalkulation spielt laut Themenanalyse kaum eine Rolle, die Begriffe sollte man trotzdem sicher können

Kostenarten im Projekt

Einmalige Kosten fallen für die Einführung an (Investition), laufende Kosten jedes Jahr für den Betrieb. Außerdem unterscheidet man Einzelkosten (direkt dem Projekt zurechenbar) und Gemeinkosten (nur anteilig über Zuschläge).

Einfache Projektkalkulation

Personalkosten = Aufwand × Stundensatz. Ein Personentag (PT) hat in der Regel 8 Stunden. Ein Stundensatz enthält neben dem Lohn auch Lohnnebenkosten, Gemeinkosten und – bei Dienstleistern – einen Gewinnzuschlag.

Make-or-Buy

Bei Make-or-Buy wird entschieden, ob eine Leistung selbst erstellt (Eigenentwicklung, „Make“) oder eingekauft wird (Standardsoftware, fertige Komponente oder Fremdvergabe an einen Dienstleister, „Buy“).

Nutzwertanalyse

Mit der Nutzwertanalyse vergleicht man Alternativen auch anhand nicht in Geld messbarer Kriterien. So gehst du vor:

1. Kriterien festlegen (K.-o.-Kriterien vorher prüfen: Wer sie nicht erfüllt, scheidet aus).
2. Kriterien gewichten – Summe der Gewichte = 100 %.
3. Jede Alternative je Kriterium mit Punkten bewerten (z. B. 1–10).
4. Teilnutzen = Gewicht × Punkte; alle Teilnutzen addieren = Nutzwert.
5. Rangfolge bilden und Entscheidung begründen (bei knappen Ergebnissen: Sensitivität prüfen).

X gewinnt knapp, obwohl Y am günstigsten ist. Stärke der Methode: qualitative Kriterien werden vergleichbar und die Entscheidung ist dokumentiert. Schwäche: Gewichte und Punkte sind subjektiv; kleine Unterschiede (7,0 zu 6,8) täuschen Genauigkeit vor.

Amortisationsrechnung (statisch)

Amortisationsdauer = einmalige Investition ÷ jährlicher Rückfluss, wobei Rückfluss = jährliche Einsparungen bzw. Mehrerlöse − laufende Kosten des neuen Systems.

Beispiel: Investition 82.280 €, Einsparungen 28.000 €/Jahr, laufende Kosten 3.600 €/Jahr → Rückfluss 24.400 €/Jahr → 82.280 € ÷ 24.400 €/Jahr ≈ 3,37 Jahre (≈ 3 Jahre und 5 Monate). Kumuliert: nach Jahr 1 −57.880 €, nach Jahr 2 −33.480 €, nach Jahr 3 −9.080 €, nach Jahr 4 +15.320 €.

Die Gesamtkosten über die Nutzungsdauer (Total Cost of Ownership, TCO) = einmalige Kosten + Nutzungsjahre × laufende Kosten. Sie sind fairer als ein reiner Vergleich der Anschaffungspreise.

PM-08 · Netzplan Sonstige ⚠

Vorkommen: 1/9 · Prüfung: S26 (T1 A1c–e, 19 Punkte) · einmalig, aber in der letzten Prüfung und sehr punktreich – unbedingt können

Ein Vorgangsknotennetzplan stellt die Vorgänge eines Projekts als Knoten (Kästchen) und ihre Abhängigkeiten als Pfeile dar. Daraus ergeben sich die Projektdauer, die Puffer jedes Vorgangs und der kritische Pfad. Normalfall ist die Ende-Anfang-Beziehung: Ein Vorgang kann erst beginnen, wenn alle Vorgänger beendet sind.

Formeln

Hinweis zur Konvention: Hier (und in S26: A von 0 bis 10, B von 10 bis 25) werden Zeitpunkte gezählt – der Nachfolger beginnt zum selben Zeitpunkt, zu dem der Vorgänger endet. In manchen Lehrbüchern werden stattdessen Tagesnummern verwendet (FAZ = 1, FEZ = FAZ + D − 1, Nachfolger beginnt am Folgetag). Beides ist richtig, solange man es konsequent durchhält; in der Prüfung an die vorgegebenen Knoten anpassen.

So gehst du vor

1. Vorgangsliste anlegen, falls der Text nur Fließtext ist: Nr. | Dauer | Vorgänger. Signalwörter: „im Anschluss“, „danach“ = Vorgänger; „parallel“, „zeitgleich“ = gleicher Vorgänger; „erst wenn … und …“ = mehrere Vorgänger.
2. Knoten anordnen von links nach rechts, parallele Vorgänge untereinander; Pfeile vom Vorgänger zum Nachfolger.
3. Vorwärtsrechnung: FAZ und FEZ für alle Knoten. Bei mehreren Vorgängern das Maximum nehmen.
4. Projektende = FEZ des letzten Vorgangs (bzw. größter FEZ).
5. Rückwärtsrechnung: beim letzten Vorgang SEZ = FEZ setzen, dann SAZ, SEZ zurück bis zum Start. Bei mehreren Nachfolgern das Minimum nehmen.
6. GP und FP für jeden Knoten berechnen.
7. Kritischen Pfad markieren (alle Knoten mit GP = 0, lückenlos verbunden).
8. Probe: Startvorgang hat SAZ = 0; kein Puffer ist negativ; FP ≤ GP.

Durchgerechnetes Beispiel: Einführung der Selbstverbuchung

Warum hat C einen Gesamtpuffer von 3, aber keinen freien Puffer? Verzögert sich C, beginnt E sofort später (FP = 0). Weil E selbst 3 Tage Luft bis zum Start von F hat, bleibt das Projektende trotzdem bei 16 – bis zu 3 Tage Verzögerung von C „verbrauchen“ den Puffer von E mit. C und E teilen sich also denselben Puffer.

Auswirkungen von Verzögerungen

Beispiel: E dauert 2 Tage länger → 2 ≤ FP (3) → keine Auswirkung. C dauert 4 Tage länger → 4 > GP (3) → Projektende 17; neuer kritischer Pfad A → C → E → F, B und D haben jetzt 1 Tag Puffer.

Projektdauer verkürzen: Nur die Beschleunigung kritischer Vorgänge verkürzt das Projekt – durch mehr Personal, Überstunden (Kosten ↑), Parallelisieren bzw. Überlappen von Vorgängen (Risiko ↑) oder weniger Umfang. Danach kann ein anderer Pfad kritisch werden.

Gantt-Diagramm (Balkenplan)

Das Gantt-Diagramm zeigt Vorgänge als Balken auf einer Zeitachse. Es ist für Termine und Auslastung anschaulicher, Abhängigkeiten sieht man aber schlechter als im Netzplan (sie können durch Pfeile ergänzt werden). Meilensteine werden als Raute (Dauer 0) eingezeichnet.

PM-09 · Machbarkeitsanalyse Sonstige ⚠

Vorkommen: 1/9 · Prüfung: W25 (T1 A1a, 8 Punkte)

Eine Machbarkeitsanalyse (Machbarkeitsstudie) wird vor dem eigentlichen Projektstart durchgeführt, meist in der Initialisierungsphase. Sie prüft, ob ein Vorhaben unter den gegebenen Bedingungen realisierbar und sinnvoll ist, und endet mit einer Empfehlung: durchführen, mit Änderungen durchführen oder nicht durchführen. So werden „No-Gos“ erkannt, bevor viel Geld ausgegeben ist.

Manchmal werden zusätzlich ökologische oder soziale Machbarkeit genannt. Andere sinnvolle Kriterien werden in der Regel akzeptiert, wenn sie gut erläutert sind.

PM-10 · Nutzen eines Systems beschreiben Sonstige

Vorkommen: 1/9 · Prüfung: S24 (T1 A1a, 8 Punkte)

Der Nutzen begründet, warum sich ein Projekt lohnt (Projektbegründung, Business Case). Er sollte je Zielgruppe beschrieben werden, denn Leserinnen, Personal und Leitung haben unterschiedliche Vorteile.

Quantitativer Nutzen lässt sich in Zahlen oder Geld ausdrücken (eingesparte Stunden, Euro, Fehlerquote), qualitativer Nutzen nur beschreiben oder schwer messen (Zufriedenheit, Image, Motivation, bessere Entscheidungsgrundlage). Man unterscheidet außerdem direkten (unmittelbar durch das System) und indirekten Nutzen (Folgewirkung, z. B. bessere Kundenbindung).

Zeitersparnis in Geld umrechnen: Anzahl Vorgänge × eingesparte Minuten ÷ 60 × Stundensatz. Beispiel: 40.000 Ausleihen pro Jahr × 1,5 Minuten = 60.000 Minuten = 1.000 Stunden × 30 €/h = 30.000 € pro Jahr.

Aufbau einer Projektbegründung (Business Case): Ausgangslage/Problem → Ziel → Lösung → Kosten → Nutzen (quantitativ und qualitativ) → Risiken → Wirtschaftlichkeit (z. B. Amortisation) → Empfehlung.

B · Belegsatz

Für Projektmanagement legt die IHK keine Notationshilfe bei – alle Informationen stehen in der Ausgangssituation und in den Aufgaben. Sie sind hier als Anlagen gesammelt. Einzige „Notation“: die Legende des Netzplanknotens (Anlage 10), wie sie in S26 bei der Aufgabe stand. Keine Erklärungen.

C · Aufgaben

Alle Aufgaben beziehen sich auf die Ausgangssituation in Anlage 1 (Projekt „PflegeMobil“). Stichwortartige Antworten sind zulässig, sofern nicht ausdrücklich ganze Sätze verlangt werden. Wenn eine bestimmte Anzahl gefordert ist („zwei …“), werden nur so viele Angaben gewertet.

PM-01 · Stakeholder und Projektbegriffe

PM-02 · Agil / Scrum / User Stories

PM-03 · Anforderungen

PM-04 · Risikoanalyse

PM-05 · Klassische Vorgehensmodelle und Prototyping

PM-06 · Change-Management und Akzeptanz

PM-07 · Kosten, Make-or-Buy, Nutzwertanalyse

PM-08 · Netzplan

PM-09 · Machbarkeitsanalyse

PM-10 · Nutzen eines Systems beschreiben

Originalaufgaben zum Üben

Diese echten Prüfungsaufgaben passen zu diesem Block (Dateien im Ordner Prüfungsvorbereitung). Projektmanagement steht immer in Teil 1. Lösungen gibt es nur für 2023 Sommer, 2023 Winter, 2024 Sommer und 2025 Winter (dort vom u-form-Verlag).