Projektdokumentation für die IHK-Abschlussprüfung.

Aufbau, Gliederung, formale Anforderungen und Bewertung der Projektdokumentation für Fachinformatiker und andere IT-Berufe.

Stand:

Die Projektdokumentation ist der schriftliche Nachweis deiner betrieblichen Projektarbeit. Sie zeigt dem Prüfungsausschuss, wie du vorgegangen bist, welche Entscheidungen du getroffen hast und ob dein Projekt fachlich, wirtschaftlich und organisatorisch nachvollziehbar ist. Die Dokumentation gehört zur Prüfungszeit der Projektarbeit; Umfang, Upload, Dateiformat, Anlagen und Eigenständigkeitserklärung regelt deine zuständige IHK.

Die Prüfer bewerten nicht nur das fertige Ergebnis. Sie bewerten den gesamten Weg: Ausgangssituation, Analyse, Planung, Umsetzung, Qualitätssicherung, Wirtschaftlichkeit, Übergabe und Reflexion.

Ziel der Projektdokumentation

Eine gute Projektdokumentation beantwortet drei Fragen:

  1. Welches Problem sollte gelöst werden?
  2. Warum hast du dich für genau diese Lösung entschieden?
  3. Woran sieht man, dass das Projekt erfolgreich war?

Die Dokumentation ist keine Bedienungsanleitung und kein Projekttagebuch. Sie muss nicht jede kleine Tätigkeit beschreiben. Entscheidend sind die fachlichen Entscheidungen und der rote Faden. Wer nur Arbeitsschritte auflistet, verschenkt Punkte, weil Analyse, Begründung und Bewertung fehlen.

Gliederung als Vorlage

Die genaue Struktur hängt von deiner IHK und deinem Projekt ab. Als Grundgerüst funktioniert für viele IT-Projekte diese Gliederung:

KapitelInhalt
Deckblatt und VerzeichnisseProjekttitel, Prüfling, Betrieb, Ausbildungsberuf, Inhaltsverzeichnis
EinleitungProjektumfeld, Auftraggeber, Ausgangssituation
Ist-AnalyseProblem, bestehende Systeme, Rahmenbedingungen
Soll-KonzeptZiele, Anforderungen, Abgrenzung
LösungsalternativenVarianten, Bewertung, Entscheidung
ProjektplanungZeitplan, Ressourcen, Kosten, Risiken
DurchführungZentrale Umsetzungsschritte und wichtige technische Entscheidungen
QualitätssicherungTeststrategie, Testfälle, Ergebnisse, Abnahme
WirtschaftlichkeitKosten, Nutzen, Amortisation oder Nutzwertbetrachtung
ProjektergebnisSoll-Ist-Vergleich, Übergabe, Zielerreichung
FazitReflexion, Abweichungen, Verbesserungsmöglichkeiten
AnhangKundendokumentation, Quellcode-Auszüge, Pläne, Protokolle

Nicht jedes Projekt braucht jedes Kapitel in derselben Tiefe. Ein Softwareprojekt hat andere Schwerpunkte als ein Infrastrukturprojekt. Die Prüfer müssen aber in beiden Fällen erkennen können, dass du strukturiert gearbeitet und Entscheidungen begründet hast.

Formale Anforderungen

Die formalen Vorgaben unterscheiden sich je nach IHK. Prüfe deshalb immer die aktuelle Handreichung deiner Kammer. Typische Vorgaben betreffen:

  • maximale Seitenzahl ohne Anhang
  • Schriftart und Schriftgröße
  • Zeilenabstand und Seitenränder
  • Umfang und Aufbau des Anhangs
  • Dateiformat und Upload-Frist
  • Eigenständigkeitserklärung
  • Umgang mit Quellen, Abbildungen und KI-Hilfsmitteln

Viele IHKs erlauben ungefähr 10 bis 15 Seiten Dokumentation ohne Anhang, manche mehr, manche weniger. Beispiele: Die IHK Bonn/Rhein-Sieg nennt 10 bis 15 Seiten Projektbericht, die IHK Rhein-Neckar nennt 12 bis 15 Seiten, und die IHK Köln unterscheidet nach Beruf und Fachrichtung. Plane nicht bis zur letzten Zeile. Eine zu lange Dokumentation ist kein Qualitätsmerkmal, sondern oft ein Zeichen für fehlende Priorisierung.

Bei KI-Hilfsmitteln musst du besonders vorsichtig sein. Einzelne IHKs beschränken den Einsatz ausdrücklich, zum Beispiel auf Recherche oder Rechtschreib- und Grammatikprüfung. Behandle KI deshalb nicht als Schreibhelfer für die eigentliche Prüfungsleistung, solange deine IHK das nicht ausdrücklich erlaubt. Quellen, fremde Inhalte und verwendete Hilfsmittel müssen nachvollziehbar angegeben werden.

Was Prüfer besonders sehen wollen

Die Projektdokumentation wird stärker, wenn du nicht nur beschreibst, was du getan hast, sondern warum du es getan hast.

Wichtige Bewertungspunkte:

  • Nachvollziehbare Ausgangslage: Das Problem ist klar, konkret und betrieblich relevant.
  • Saubere Zieldefinition: Die Ziele sind messbar oder zumindest überprüfbar.
  • Begründete Lösungsentscheidung: Alternativen werden nicht nur genannt, sondern verglichen.
  • Realistische Planung: Zeit, Kosten, Ressourcen und Risiken passen zum Projekt.
  • Fachliche Tiefe: Die technische Umsetzung ist angemessen erklärt.
  • Qualitätssicherung: Tests und Abnahme zeigen, dass das Ergebnis funktioniert.
  • Wirtschaftlichkeit: Der Nutzen wird fachlich und betriebswirtschaftlich eingeordnet.
  • Kritische Reflexion: Abweichungen werden erklärt, nicht versteckt.

Gerade die Wirtschaftlichkeitsbetrachtung wird oft unterschätzt. Auch technische Projekte müssen zeigen, warum sich die Lösung lohnt: durch Zeitersparnis, geringere Ausfallrisiken, bessere Wartbarkeit, höhere Sicherheit oder messbaren Geschäftsnutzen.

Unterschiede zwischen FiSi und FiAe

Für Fachinformatiker Systemintegration liegt der Schwerpunkt häufig auf Infrastruktur, Betriebssicherheit, Netzwerken, Diensten, Berechtigungen, Monitoring oder Migrationen.

Typische Anhänge für FiSi:

  • Netzpläne
  • IP-Adresskonzepte
  • Konfigurationsauszüge
  • Testprotokolle
  • Rollback-Plan
  • Administrations- oder Betriebsdokumentation

Für Fachinformatiker Anwendungsentwicklung liegt der Schwerpunkt häufiger auf Anforderungen, Entwurf, Datenmodell, Schnittstellen, Implementierung, Qualitätssicherung und Wartbarkeit.

Typische Anhänge für FiAe:

Der Unterschied liegt nicht darin, dass eine Fachrichtung “technischer” ist als die andere. Beide müssen zeigen, dass Entscheidungen fachlich begründet und für die Zielgruppe verständlich dokumentiert wurden.

Häufige Fehler

Viele Projektdokumentationen verlieren Punkte durch vermeidbare Schwächen.

Typische Fehler:

  • Der Antrag und die Dokumentation passen nicht zusammen.
  • Die Ist-Analyse ist zu kurz oder fehlt ganz.
  • Ziele sind nicht messbar.
  • Lösungsalternativen werden nur behauptet, aber nicht bewertet.
  • Die Umsetzung ist zu kleinteilig beschrieben, die Entscheidungen fehlen.
  • Tests bestehen nur aus Screenshots ohne Aussage.
  • Wirtschaftlichkeit wird als Pflichtabsatz behandelt, aber nicht gerechnet oder begründet.
  • Der Anhang ersetzt den Hauptteil.
  • Fachbegriffe werden verwendet, aber nicht sauber erklärt.
  • Abweichungen vom Plan werden verschwiegen.

Eine gute Dokumentation darf Probleme zeigen. Entscheidend ist, dass du professionell damit umgehst: Was ist passiert, welche Entscheidung hast du getroffen, welche Auswirkung hatte das auf Ziel, Zeit oder Qualität?

Checkliste vor der Abgabe

Vor dem Upload solltest du die Dokumentation nicht nur korrekturlesen, sondern fachlich prüfen.

  • Stimmen Projekttitel, Ziel und Zeitplanung mit dem genehmigten Projektantrag überein?
  • Sind Ist-Zustand, Soll-Zustand und Projektabgrenzung klar?
  • Wird mindestens eine echte Lösungsentscheidung begründet?
  • Gibt es einen Soll-Ist-Vergleich?
  • Sind Testfälle und Abnahme nachvollziehbar?
  • Ist die Wirtschaftlichkeit konkret genug?
  • Sind alle Quellen angegeben?
  • Ist der Anhang sinnvoll nummeriert und im Text referenziert?
  • Sind Seitenzahl, Format, Dateiname und Abgabefrist nach IHK-Vorgabe erfüllt?
  • Kannst du die wichtigsten Entscheidungen später im Fachgespräch erklären?

Nach der Abgabe bereitest du dich auf Präsentation und Fachgespräch vor. Dafür ist die Fachgespräch-Checkliste der nächste sinnvolle Schritt. Den gesamten Ablauf findest du auf der Seite zur Projektarbeit.

Offizielle Quellen

Weiter in der Prüfung

Nächster sinnvoller Schritt