Meine Checkliste zur Prüfung von Projektanträgen

Beim Prüfen von Projektanträgen für die IHK-Prüfung achte ich immer insb. auf die folgenden Punkte. Ihr könnt die Liste gerne nutzen um euren eigenen Antrag auf Vollständigkeit und aussagekräftigen Inhalt zu überprüfen.

Projektbegründung

  • Wird das Projekt nachvollziehbar eingeführt und beschrieben?
    • Viele Prüflinge schreiben so, als wüsste jeder Prüfer, wie die internen Abläufe und Probleme im Unternehmen des Prüflings oder auch branchenspezifische Fragestellungen aussehen. Das ist nicht der Fall! Ein paar Sätze zum Unternehmen und der Problemstellung sollten selbstverständlich sein.
  • Was ist der wirtschaftliche Nutzen? Wird eine Kalkulation/Amortisationsrechnung durchgeführt?
    • Viele Prüflinge konzentieren sich ausschließlich auf den technischen Teil des Projekts (insb. die Programmierung) und vergessen den wirtschaftlichen Teil völlig. Solche Anträge gehen immer mit Änderungsauftrag zurück an den Prüfling.

Projektplanung

  • Ist der Aufbau der zeitlichen Projektplanung logisch und sinnvoll?
    • Einige Prüflinge setzen für die einzelnen Phasen des Projekts unrealistische Zeiten ein oder brechen sie nicht detailliert genug runter. So wird häufig die Implementierung z.B. einfach mit 35 Stunden angesetzt ohne genauer zu beschreiben, welche Komponenten entwickelt werden sollen und wie viel Zeit jeweils auf diese entfällt. Unbedingt erforderlich ist natürlich auch die Einhaltung der zeitlichen Vorgabe von 70 Stunden!
  • Stimmt das Verhältnis zwischen Entwurf und Implementierung?
    • Das Projekt sollte methodisch umgesetzt werden und nicht einfach „drauflos programmiert“. Daher ist eine entsprechend lange Entwurfsphase mit sinnvollen Entwurfsmethoden (z.B. Komponentendiagramm, Entity-Relationship-Model) im Verhältnis zur Implementierung anzuraten.
  • Wurde die Dokumentation in der Zeitplanung berücksichtigt?
    • Für das Projekt sollten (in den meisten Fällen) verschiedene Dokumentationen angefertigt werden, die sich nicht von alleine schreiben. Es sollte also ausreichend Zeit dafür eingeplant sein.

Implementierung

  • Welche Form hat das Programm (Webanwendung, Client mit GUI, CLI)?
    • Es ist erstaunlich aus wie vielen Projektanträgen nicht hervorgeht, welche Form das zu erstellende Programm eigentlich hat. Das ist aber durchaus interessant für die Prüfer, um die Projektplanung bewerten zu können (z.B. ob die Zeiten realistisch oder die Tests ausreichend sind).
  • Welche Programmiersprache/Datenbank wird verwendet?
    • Falls die technischen Details der Implementierung nicht erst während der Projektphase bestimmt werden (was wohl in den seltensten Fällen so ist), dürfen diese Informationen gerne deutlich im Projektantrag genannt werden.
  • Wie wird getestet bzw. welche Maßnahmen zur Qualitätssicherung werden angewendet?
    • Trotz dreijähriger Ausbildung sind die Prüflinge (und sicherlich auch die Ausbilder) nicht perfekt. Wie wird im Projekt also dafür gesorgt, dass ein vernünftiges Produkt erstellt wird? Hier dürfen ausgedehnte Testphasen, Test Driven Development oder auch Code Reviews eingeplant werden.

Sonstiges

  • Welche Methoden werden eingesetzt und welche Artefakte werden erstellt?
    • UML-Diagramme, ERM, Tabellenmodelle, Ablaufpläne, EPKs, Programmablaufpläne, Nutzwertanalysen, Mockups usw.
  • Und ganz wichtig: Was ist die konkrete Eigenleistung des Prüflings?
    • Häufig wird das Projekt so schwammig beschrieben, dass nicht ersichtlich ist, was genau der Prüfling eigentlich macht. In einigen Projekten muss man sich fragen, ob überhaupt eine Zeile Code produziert wird. Gerade bei Integrationsprojekten in großen Unternehmensanwendungen ist der organisatorische Overhead so groß, dass nur noch wenig Zeit für die Implementierung bleibt. Das wird aber in einem Abschlussprojekt erwartet.

Habt ihr noch weitere Punkte, die beim Projektantrag wichtig sind? Schreibt sie gerne in die Kommentare!

Weitere Infos zum Projektantrag

Du suchst noch mehr Tipps rund um den Projektantrag? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um den Projektantrag.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für den Projektantrag herunterladen.

Checkliste für den Projektantrag

6 thoughts on “Meine Checkliste zur Prüfung von Projektanträgen

  1. Das ist ja alles schön und gut und richtig. Nur hat die IHK Vorlage bei uns lediglich knapp 100 Wörter/750 Zeichen Platz und der zeitliche Abstand der Abgabe des Antrages auf Zulassung hin zur Projektdurchführung beträgt über einen Monat. Mit anderen Worten, da hat man nicht das Gefühl „ich muss das jetzt schon ordentlich planen“. Da die Vorlage zudem nur so knapp gefasst ist und überhaupt nicht erklärt was gefordert wird, entsteht nicht der Eindruck dass das so genau gewollt ist. Mit anderen Worten, eine Erklärung wie hier auf der Seite, als Anlage zu einem Formular mit mehr Platz, würde zu mehr Stichhaltigen Anträgen führen. Solange sich das nicht ändert, sind die Anforderungen einfach nur überzogen. Immerhin ist das alles nochmal Teil der Dokumentation zum Projekt und ist dann quasi doppelt, oder aber vorgearbeitet.

  2. Hallo Lukas,

    ok, wenn deine IHK andere Vorgaben macht, dann halte dich natürlich dran. Ich finde 100 Wörter viel zu wenig für einen Antrag. Die Prüfer können ja nicht einmal ansatzweise bewerten, ob es sich um ein ausreichendes Projekt handelt. Mit 100 Wörtern kann man ja kaum die Aufgabe beschreiben. Das kenne ich ehrlich gesagt auch noch nicht von anderen IHKen. Nun denn, die werden schon ihre Gründe dafür haben.

    Viele Grüße!
    Stefan

  3. Hallo Stefan,

    ich hätte einmal eine Frage bezüglich der Zeitplanung.
    Nehmen wir einmal an ich habe 35 Stunden für meine Impentierungsphase angegeben.
    Nun habe ich z.B. folgende Liste für meinen Antrag erstellt:

    Implementierungsphase – 35 Stunden

    Implementierung der Klassen – 10 Stunden

    Implementierung der Controller – 25 Stunden

    Nun würde ich gerne noch einen Optionalen Punkt hinzufügen:

    Code verbessern (Refactoring) – optional, wenn bei anderen Punkten Zeit überbleibt

    Ist so etwas zulässig? Das Refactoring wäre für mich nur ein Punkt den ich in Angriff nehmen würde wenn z.B. bei der Implementierung der Klassen anstatt zehn Stunden nur neun benötigt werden.

    Grüße,
    Christoph

  4. Hallo Christoph,

    den Punkt könntest du dazunehmen, aber ich wäre vorsichtig bzgl. des Umfangs. Letztlich reden wir hier ja von einer Art „Puffer“, der genutzt wird, wenn Zeit übrig bleibt. Aber wieso sollte bei einer so tollen Planung wie der deinen Zeit übrig bleiben? Hast du nicht genau genug geplant? Hast du etwas übersehen? Das wirft potentielle Fragen für das Fachgespräch auf. (Ja, mir ist klar, dass niemand so genau planen kann! 😉 )

    Wieso planst du nicht einfach „hinten rum“ mehr Zeit für ein Refactoring ein, indem du die Implementierung etwas länger machst (oder so lässt wie jetzt) und in der Doku so etwas schreibst wie „Sollten Teile des Projekts schneller entwickelt werden können als geplant, wird die freie Zeit für Refactorings verwendet“. Allerdings würde ich dann in der Prüfung fragen, ob du deine Zeit so knapp kalkuliert hast, dass erstmal nur Spaghetti-Code entstehen kann, der vielleicht aufgeräumt wird „wenn noch Zeit ist“. 😉

    Also letztlich würde ich empfehlen, den Hinweis komplett wegzulassen. Ich erwarte von vernünftigen Entwicklern, dass die Zeit für die Implementierung inkl. Refactoring kalkuliert wird. So solltest du das in der Doku auch beschreiben, z.B.: „Die geplante Zeit für die Implementierung enthält bereits das Erstellen der Unit-Tests und ein Refactoring“.

    Viele Grüße!
    Stefan

  5. Hallo Stefan,

    ich weiß leider nicht so richtig bei meinem Projektantrag bei der Kategorie Dokumentation weiter.
    Hier steht nämlich:

    6.Dokumentation
    Bitte geben Sie hier die geplante Art der Dokumentation an (z. B. prozessorientierter Projektbericht), eine Grobgliederung (mindestens drei Phasen) und welche Anlagen Sie vorgesehen haben.

    Meine Grobgliederung würde jetzt so ungefähr aussehen:

    1.Projektdefinition
    2.IST-Analyse
    3.SOLL-Konzept
    4.Konzept
    5.Realisierung
    6.Test
    7.Wirtschaftlichkeitsanalyse
    8.Zusammenfassung
    9.Danksagung
    10.Begriffserklärung
    11.Quellenverzeichnis
    12.Anhang

    Würde diese schon mal passen? Und welche Arten von Dokumentation gibt es? Ich weiß leider überhaupt nicht, was meine Dokumentation für eine Art ist.

    Vielen Dank im Voraus

    Sophie

  6. Hallo Sophie,

    mhh, das habe ich so noch nicht gesehen. Da fragst du am besten deine IHK. Ich würde das jetzt als Benutzer-/Kundendokumentation interpretieren, aber wenn du die Gliederung angeben musst, kann es ja eigentlich nur die Projektdokumentation sein, die gemeint ist.

    Viele Grüße!
    Stefan

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax