IHK-Projektdokumentation

1. Formale IHK-Vorgaben

Stand: aktuelle Merkblätter (z. B. IHK München 2025, IHK Köln, IHK Rhein-Neckar):

• Umfang: maximal 15 Seiten Hauptteil ohne Anhang.
• Schriftart/-größe: Arial 11 pt oder Times New Roman 12 pt.
• Zeilenabstand: 1,5-zeilig.
• Ränder: typischerweise 2,5 cm rundum (siehe IHK-Vorgabe).
• Nicht mitgezählt: Deckblatt, Inhalts-, Abbildungs-, Tabellen-, Abkürzungs-, Glossar- und Literaturverzeichnis sowie Anhang.
• Zeitumfang: 80 Stunden Projektarbeit gemäß Ausbildungsverordnung (FIAusbV).
• Quellcode: bei FIAE Pflicht im Anhang – nicht in den Hauptteil.
• Abgabe: meistens als PDF + Online-Upload, in manchen IHKs zusätzlich gedruckt + signierte Erklärung über die selbstständige Erstellung.

2. Empfohlene Gliederung (IHK-Standard)

1.  Einleitung / Projektbeschreibung               (~1–2 S.)
    1.1 Projektumfeld / Unternehmensvorstellung
    1.2 Ist-Analyse / Ausgangssituation
    1.3 Ziel des Projekts (Soll-Zustand)
    1.4 Projektabgrenzung (was NICHT Teil des Projekts ist)

2.  Projektplanung                                 (~2–3 S.)
    2.1 Projektphasen mit Zeitplanung (Soll-Plan)
    2.2 Stakeholder-Analyse
    2.3 Risikoanalyse
    2.4 Wirtschaftlichkeitsanalyse / Kosten-Nutzen

3.  Analysephase                                   (~2 S.)
    3.1 Anforderungsanalyse (funktional / nicht-funktional)
    3.2 Make-or-Buy-Entscheidung / Nutzwertanalyse
    3.3 Auswahl Technologien

4.  Entwurfsphase                                  (~2–3 S.)
    4.1 Architekturentwurf
    4.2 Datenmodell (ERM, ggf. Klassendiagramm)
    4.3 Schnittstellen / GUI-Mockups

5.  Implementierungsphase                          (~3–4 S.)
    5.1 Umgesetzte Funktionen (kein Code-Listing!)
    5.2 Wichtige Designentscheidungen mit Begründung
    5.3 Abweichungen vom Plan

6.  Test- und Abnahmephase                         (~1–2 S.)
    6.1 Testkonzept (Unit, Integration, Abnahme)
    6.2 Testdokumentation
    6.3 Abnahmeprotokoll

7.  Projektabschluss                               (~1 S.)
    7.1 Soll-Ist-Vergleich (Zeit, Kosten, Funktionen)
    7.2 Lessons Learned / Reflexion
    7.3 Ausblick / mögliche Erweiterungen

3. Was in den Anhang gehört

• Quellcode (Pflicht für FIAE) – ggf. nur die wichtigsten Klassen, nicht der ganze Build-Output
• Vollständige Diagramme in lesbarer Größe (Klassen-, Aktivitäts-, Sequenzdiagramm)
• SQL-Skripte und Datenbankschema
• Mockups / Screenshots der finalen Anwendung
• Testfälle / Testprotokolle
• Installationsanleitung oder Benutzerhandbuch (oft erwünscht)
• Abnahmeprotokoll mit Unterschrift des Auftraggebers
• Glossar / Abkürzungsverzeichnis

4. Best Practices

Inhaltlich

• Eigene Leistung klar kennzeichnen: Was hast du gemacht, was haben andere beigesteuert? Bei Co-Working: Schnittstellen sauber benennen.
• Begründen, nicht nur beschreiben: «Wir haben Postgres gewählt, weil …» statt «Wir haben Postgres gewählt.»
• Soll-Ist-Vergleich ist Pflicht: Plan vs. Realität bei Zeit, Kosten und Funktionen.
• Wirtschaftlichkeitsbetrachtung mit Amortisation oder ROI – meistens erwartet.

Formell

• Automatisches Inhaltsverzeichnis mit klickbaren Seitenzahlen (Word / LibreOffice / LaTeX).
• Konsistente Formatierung: Überschriftenebenen, Schriftart, Aufzählungen.
• Nummerierte Abbildungen und Tabellen mit Bildunterschrift.
• Quellenangaben nach einem konsistenten Stil (DIN 1505 oder Harvard).
• Rechtschreibung & Grammatik: Mind. 2 Personen Korrekturlesen lassen. Sprache fließt in die Bewertung ein.
• Bilder/Screenshots in lesbarer Auflösung – verkleinerte UML-Diagramme frusten den Korrektor.

Sprache

• Sachlich, knapp, präzise. Keine Ich-Erzählung im Hauptteil – Passivkonstruktionen sind ok, aber nicht zwanghaft.
• Fachbegriffe einmalig erklären (Glossar).
• Englisch-deutsche Mischbegriffe vermeiden («wir haben das deployt» → «… ausgeliefert»).

5. Bewertungskriterien der IHK (typisch)

6. Typische Fehler (aus IHK-Auswertungen)

• Unklare Trennung «eigene Leistung» vs. «Team-/Fremdleistung»
• Keine oder oberflächliche Wirtschaftlichkeitsbetrachtung
• Soll-Ist-Vergleich fehlt komplett
• Anforderungen nicht systematisch erfasst
• Diagramme zu klein oder fehlerhaft (z. B. UML-Notation falsch)
• Code-Snippets im Hauptteil → Verschwendung von Seiten
• Lehrbuchabschnitte als Füllmaterial
• Ich-Erzählungen, Plauderton
• Anhang ohne Inhaltsverzeichnis / Bezug