Ein IT-Projekt planbar machen und steuern

Was du nach dieser Lektion kannst

Das Bildungszentrum Nordhafen richtet einen neuen Schulungsraum ein. Zwölf vorhandene Notebooks sollen zentral verwaltet werden. Dazu kommen ein Präsentationssystem, ein getrenntes WLAN für Teilnehmende und eine kurze Einweisung für das Schulungsteam. Der Raum ist für einen Kurs ab dem 5. Oktober fest gebucht.

Der Auftrag klingt überschaubar. Trotzdem liegen darin mehrere Fragen: Wer darf Entscheidungen treffen? Was gehört zum Ergebnis? Welche Aufgaben hängen voneinander ab? Was passiert, wenn die Access Points später geliefert werden? Und wann ist eine Abweichung groß genug, um sie zu melden?

Projektmanagement beantwortet diese Fragen nicht mit möglichst vielen Dokumenten. Es schafft ein gemeinsames Bild davon, was erreicht werden soll, wer beteiligt ist und wie das Team Abweichungen rechtzeitig erkennt.

Nach dieser Lektion kannst du:

• einen unklaren Projektauftrag in eine belastbare Arbeitsgrundlage überführen,
• Ziele und Projektgrenzen prüfbar formulieren,
• Stakeholder, Arbeitspakete, Termine und Risiken miteinander verbinden,
• einen Projektstatus aus Fakten und einer Prognose ableiten,
• eine notwendige Entscheidung knapp und nachvollziehbar vorbereiten.

Du brauchst kein Vorwissen zu Scrum, Wasserfall oder Netzplänen. Diese Lektion behandelt die gemeinsame Grundlage eines IT-Projekts. Vorgehensmodelle und detaillierte Netz- oder Gantt-Pläne gehören in die Lektion “Projektvorgehen”. Eine prüfungsbezogene Projektdokumentation ist Thema der Lektion “Projektdokumentation”.

Ein Projektauftrag schafft einen gemeinsamen Startpunkt

Ein Projekt ist ein zeitlich begrenztes Vorhaben mit einem bestimmten Ziel. Es unterscheidet sich damit von einer regelmäßig wiederkehrenden Aufgabe. Jeden Montag Benutzerkonten zu prüfen ist ein betrieblicher Prozess. Einen neuen Schulungsraum bis zu einem festgelegten Termin betriebsbereit zu machen, ist ein Projekt.

Der Projektauftrag gibt diesem Vorhaben einen verbindlichen Rahmen. Er sollte mindestens sechs Fragen beantworten:

Die Abgrenzung ist kein nebensächlicher Ausschluss. Sie schützt das Projekt vor stillen Erweiterungen. Wenn die Fachabteilung später zusätzlich eine neue Lernanwendung entwickeln lassen möchte, ist das nicht automatisch Teil des laufenden Auftrags. Zuerst werden Auswirkung, Aufwand und Entscheidung geklärt.

Ein Ziel beschreibt den überprüfbaren Endzustand

“Den Schulungsraum verbessern” zeigt eine Absicht, aber keinen überprüfbaren Endzustand. Ein Projektziel beschreibt, welches Ergebnis bis wann unter welchen Bedingungen erreicht sein soll.

Für die Formulierung hilft das SMART-Prinzip. Die Buchstaben werden unterschiedlich übersetzt. Der tragende Gedanke bleibt gleich: Ein Ziel soll konkret, überprüfbar, sinnvoll erreichbar und terminiert sein.

Bis zum 29. September sind zwölf vorhandene Notebooks in die zentrale Geräteverwaltung aufgenommen, das Präsentationssystem ist eingerichtet und das Teilnehmer-WLAN ist technisch vom internen Netz getrennt. Alle vereinbarten Abnahmetests sind bestanden. Die Projektkosten überschreiten 18.000 Euro nicht.

Dieses Ziel verbindet Leistung, Termin, Qualität und Kosten. Es legt noch nicht jeden technischen Lösungsweg fest. Das Team behält damit Raum für fachliche Entscheidungen.

Mehrere Ziele können miteinander konkurrieren. Ein früher Termin, ein enger Kostenrahmen und ein hoher Leistungsumfang lassen sich nicht immer gleichzeitig halten. Dann braucht das Projekt eine Priorität. Im Beispiel hat der sichere Kursstart Vorrang. Eine optionale drahtlose Bildschirmübertragung darf entfallen, wenn sie den Abnahmetermin gefährdet. Die Netztrennung darf dagegen nicht still abgeschwächt werden.

Ziele, Anforderungen und Aufgaben erfüllen verschiedene Rollen

Diese drei Ebenen werden leicht vermischt:

• Das Projektziel beschreibt den gewünschten Endzustand.
• Eine Anforderung beschreibt eine Eigenschaft oder Leistung des Ergebnisses, etwa die technische Trennung der Netze.
• Eine Aufgabe beschreibt Arbeit auf dem Weg dorthin, etwa die VLAN-Konfiguration auf dem Switch.

Wenn “Switch konfigurieren” als Ziel erscheint, fehlt die Frage nach dem Nutzen. Wenn “sicheres WLAN” nur als Aufgabe auftaucht, fehlt ein prüfbares Ergebnis. Die Ebenen greifen ineinander, ersetzen sich aber nicht.

Stakeholder beeinflussen Entscheidungen und Erfolg

Ein Stakeholder ist eine Person oder Gruppe, die das Projekt beeinflusst, von seinem Ergebnis betroffen ist oder ein berechtigtes Interesse daran hat. Für den Schulungsraum gehören dazu nicht nur Auftraggeberin und Projektteam.

Einfluss beschreibt, wie stark ein Stakeholder Entscheidungen oder Verlauf verändern kann. Interesse beschreibt, wie stark die Person oder Gruppe betroffen ist. Beide Werte helfen bei der Kommunikation. Eine Gruppe mit hohem Einfluss braucht nicht automatisch jede technische Einzelheit. Sie braucht die Informationen, mit denen sie entscheiden kann.

Ein häufiger Fehler ist, Stakeholder erst kurz vor der Abnahme einzubeziehen. Dann werden berechtigte Anforderungen spät sichtbar. Im Beispiel muss der IT-Betrieb die Netztrennung prüfen, bevor Geräte montiert und Termine zugesagt sind.

Arbeitspakete machen Ergebnisse verantwortlich

Ein Projektziel ist zu groß, um es direkt abzuarbeiten. Ein Projektstrukturplan zerlegt das Vorhaben in überschaubare Teile. Die kleinste plan- und steuerbare Einheit ist das Arbeitspaket.

Ein brauchbares Arbeitspaket benennt:

• ein erwartetes Ergebnis,
• eine verantwortliche Person,
• Voraussetzungen und Abhängigkeiten,
• Aufwand oder geplante Dauer,
• ein eindeutiges Fertig-Kriterium.

“WLAN bearbeiten” ist dafür zu unklar. Tragfähiger ist:

AP 3: Teilnehmer-WLAN einrichten. Verantwortlich: Samira. Voraussetzung: freigegebenes Netzkonzept und gelieferte Access Points. Ergebnis: SSID, Authentifizierung und Netztrennung sind konfiguriert. Fertig, wenn Verbindungs-, Trennungs- und Abdeckungstest protokolliert bestanden sind.

Für den Schulungsraum entstehen beispielsweise diese Pakete:

Ein Meilenstein ist kein Arbeitspaket. Er markiert ein wichtiges, überprüfbares Ereignis ohne eigene Dauer. “Technisches Konzept freigegeben” und “Gesamtabnahme bestanden” sind Meilensteine. “Konzept erstellen” ist Arbeit und damit ein Arbeitspaket.

Termine entstehen aus Abhängigkeiten

Ein Endtermin allein ist noch kein Terminplan. Das Team muss erkennen, welche Arbeitspakete voneinander abhängen und welche Verschiebung den Zieltermin berührt.

Im Beispiel darf die Beschaffung erst nach Freigabe des technischen Konzepts beginnen. Der Gesamttest braucht sowohl die eingerichteten Notebooks als auch das betriebsbereite Netzwerk. Verzögert sich die Lieferung, kann das Team die Geräteverwaltung vielleicht trotzdem vorbereiten. Den Netztest kann es aber nicht vollständig abschließen.

Ein Terminplan braucht deshalb mindestens:

• Start und geplantes Ende jedes Arbeitspakets,
• fachliche oder technische Abhängigkeiten,
• verantwortliche Personen und verfügbare Ressourcen,
• Meilensteine für Freigaben und Abnahmen,
• bewusst eingeplante Reserven für Unsicherheit.

Eine Pufferzeit ist keine beliebige freie Zeit. Sie schützt den Endtermin vor erwartbaren Schwankungen. Ist jeder Puffer bereits fest verplant, bevor die Arbeit beginnt, gibt es keine Reserve mehr.

Risiken werden vor dem Problem bearbeitet

Ein Risiko ist ein mögliches zukünftiges Ereignis, das ein Projektziel beeinflussen kann. Ein bereits eingetretener Lieferverzug ist kein Risiko mehr, sondern ein Problem. Diese Unterscheidung verändert die Reaktion: Risiken beobachtest und behandelst du vorbeugend. Probleme brauchen eine konkrete Lösung und gegebenenfalls eine neue Prognose.

Eine einfache Risikoanalyse verbindet vier Angaben:

1. Ursache und Ereignis: Was könnte warum passieren?
2. Auswirkung: Welches Ziel wäre betroffen?
3. Bewertung: Wie wahrscheinlich und wie schwer wäre die Auswirkung?
4. Reaktion: Wie wird die Wahrscheinlichkeit oder Auswirkung reduziert, und wer beobachtet den Auslöser?

“Lieferung kommt zu spät” ist als Risikonotiz zu knapp. Sie nennt weder Auswirkung noch Handlungsgrenze. Eine brauchbare Formulierung lautet: “Wenn die Access Points nach dem 22. September eintreffen, kann der vollständige Netztest nicht wie geplant beginnen. Die Projektleitung prüft am 15. September den bestätigten Versand. Fehlt er, wird das freigegebene Ersatzmodell bestellt.”

Projektstatus verbindet Rückblick und Prognose

Ein Statusbericht ist keine Tätigkeitsliste. Er beantwortet vier Fragen:

• Was war bis heute geplant?
• Was ist nachweislich erreicht?
• Welche Ziele oder Meilensteine sind gefährdet?
• Welche Entscheidung oder Maßnahme wird jetzt gebraucht?

Am 18. September sieht der Schulungsraum so aus:

Der Gesamtstatus ist damit nicht einfach “fast fertig”. Die Geräteverwaltung läuft planmäßig. Die fehlende Versandbestätigung gefährdet aber einen abhängigen Test und damit den Meilenstein. Eine entscheidungsfähige Meldung lautet:

Status Gelb: Konzept und Geräteverwaltung liegen im Plan. Für die Access Points fehlt die zugesagte Versandbestätigung. Ohne Versand bis zum 19. September ist der Netztest am 25. September gefährdet. Empfehlung: Das bereits technisch geprüfte Ersatzmodell bis zum 19. September, 12 Uhr, freigeben. Mehrkosten: höchstens 900 Euro. Entscheidung durch die Leitung erforderlich.

Die Farbe fasst nur zusammen. Sie ersetzt nicht Ursache, Auswirkung, Maßnahme und Entscheidung. Ein Status bleibt auch dann ehrlich, wenn noch keine exakte Lösung feststeht.

Transfer: Plane ein neues IT-Vorhaben

Das Wichtigste in Kürze

• Der Projektauftrag verbindet Zweck, Ergebnis, Grenzen, Rahmen und Verantwortung.
• Ziele beschreiben einen überprüfbaren Endzustand. Anforderungen und Aufgaben liegen auf anderen Ebenen.
• Stakeholder werden nach ihrem Einfluss, Interesse und notwendigen Beitrag eingebunden.
• Arbeitspakete liefern Ergebnisse. Meilensteine markieren überprüfbare Ereignisse.
• Terminplanung folgt Abhängigkeiten und berücksichtigt bewusst gesetzte Reserven.
• Risiken liegen in der Zukunft. Eingetretene Risiken werden als Probleme mit Maßnahme und neuer Prognose gesteuert.
• Ein Projektstatus vergleicht Plan und Ist, bewertet die Auswirkung und benennt den nächsten Entscheidungsbedarf.

Quellenbasis und Abgrenzung

Die berufliche Handlung knüpft an Lernfeld 2 des KMK-Rahmenlehrplans an. Dort organisieren die Lernenden einen Kundenauftrag, berücksichtigen Lieferzeiten, übergeben das Ergebnis und bewerten ihr Vorgehen. Der Ausbildungsrahmenplan der Fachinformatikerausbildungsverordnung nennt in Abschnitt A Nummer 1 ausdrücklich das Anwenden von Projektmanagementmethoden, das Prüfen eines Auftrags, das Festlegen der Arbeitsschritte sowie die Terminplanung und -überwachung.

Der interne AP1-Prüfungskatalog grenzt die Themenbreite über Projektmerkmale, SMART-Ziele, Meilensteine, Terminplanung, Stakeholder, Risikoanalyse und Bearbeitungsstatus ein. Eine frühere Beispielprüfung wurde ausschließlich als Hinweis auf wiederkehrende Aufgabenformen zu Stakeholdern und Meilensteinen ausgewertet. Szenario, Zahlen, Formulierungen und Übungen dieser Lektion sind neu. Sie bilden keine echte Prüfungsaufgabe ab und sagen keinen konkreten Prüfungstermin voraus.

Diese Lektion erklärt die operative Grundstruktur, mit der ein überschaubares IT-Projekt planbar und steuerbar wird. Sie vertieft weder klassische und agile Vorgehensmodelle noch die Berechnung von Netzplänen, Puffern und kritischem Weg. Das gehört in die Lektion “Projektvorgehen”. Sie behandelt auch nicht Aufbau, Bewertung oder Abgabe einer betrieblichen Projektdokumentation. Das gehört in die Lektion “Projektdokumentation”. Betriebliche Vorlagen und Entscheidungsbefugnisse haben in der Praxis Vorrang vor den vereinfachten Mustern dieser Lektion.

Belegmatrix