Bei der Erstellung der Projektpräsentation taucht bei vielen Azubis oftmals die folgende Frage auf:

Soll ich gefundene Fehler in meiner Projektdokumentation in der Projektpräsentation erwähnen (und korrigieren)?

In der (teils sehr langen) Zeit zwischen der Erstellung der Projektdokumentation und der Vorbereitung der Projektpräsentation fallen vielen Prüflingen beim erneuten Lesen ihrer Ausarbeitung häufig doch noch einige Fehler auf, die ihnen bei der finalen Korrektur durch die Lappen gegangen sind. Sollen diese Fehler nun in der Projektpräsentation erwähnt und korrigiert werden?

Die kurze Antwort: Es kommt drauf an 😉

Um welche Fehler geht es hier?

Es geht natürlich nicht um Rechtschreibfehler oder andere Trivialitäten. Wenn die in der Projektpräsentation korrigiert werden müssten, würde bei den meisten Prüflingen keine Zeit mehr für den eigentlichen Inhalt bleiben 😉

Ich spreche hier z.B. von Rechenfehlern bei der Kalkulation, Planungsfehlern in der Zeitplanung, vergessenen Ressourcen oder Arbeitsstunden der Projektmitarbeiter, fehlenden Informationen über verwendete Frameworks oder Bibliotheken, nicht eingefügten Diagrammen usw.

Es geht also um Fehler, die ggfs. eine andere Einschätzung und Bewertung des Projekts zur Folge hätten.

Jeder Mensch macht Fehler

Vorweg: Niemand ist unfehlbar. Fehler passieren. Und (gerade) auch in der Projektdokumentation.

Grundsätzlich ist es kein Problem, wenn Fehler in der Projektdokumentation auftauchen. Das Schlimmste, das passieren kann, ist eine Abwertung der Dokumentation. Aber dafür müssen schon mehrere Punkte zusammenkommen. Also gilt erstmal: Ruhe bewahren.

Nur weil ein paar Zahlen falsch sind oder ein Diagramm fehlt, wird die Dokumentation nicht mit „ungenügend“ bewertet (was die Horrorvorstellung vieler Prüflinge nach dem Entdecken der Fehler ist). Ich sage nicht, dass man trotzdem noch ein „sehr gut“ bekommt, aber für eine deutliche Abwertung der Dokumentation müssen schon mehrere Fehler zusammenkommen.

Soll ich in der Projektpräsentation auf meine Fehler hinweisen?

Grundsätzlich gilt: Mit der Wahrheit fährt man immer am besten. Die Prüfer sind nicht dumm und prüfen die Dokumentation auf Herz und Nieren. Gerade Rechenfehler fallen ihnen sicher auf, da insb. die Kalkulation meist intensiv geprüft wird.

Wer also vorhat, die Fehler stillschweigend zu ignorieren oder gar zu leugnen, der tut sich damit keinen Gefallen. Fehler sind nur dann ein Problem, wenn man nicht aus ihnen lernt. Seht das Ganze wie im echten Leben: Wenn eure realen Projekte nicht laufen, müsst ihr das eurem Chef auch so schnell wie möglich beichten, damit noch gegengesteuert werden kann. Alles andere wäre fahrlässig.

Das bedeutet aber nicht, dass eure Präsentation nur aus Rechtfertigungen und Hinweisen auf eure schlechte Arbeit bestehen sollte. Ihr zieht eure Präsentation einfach durch und erwähnt an den entsprechenden Stellen in einem Nebensatz euren Fehler in der Präsentation.

Die fehlerhaften Teile sind Bestandteil der Projektpräsentation

Die erste Frage, die ich mir stellen würde, ist, ob die fehlerhaften Teile der Projektdokumentation ohnehin in der Projektpräsentation erwähnt worden wären. Handelt es sich z.B. um einen Rechenfehler in der Wirtschaftlichkeitsbetrachtung, so ist dies ein zentraler Bestandteil jeder Präsentation. Das bedeutet, ihr müsst die Prüfer darauf hinweisen, wenn ihr einen Fehler entdeckt – und noch wichtiger: auch korrigiert – habt.

Andernfalls würdet ihr in der Präsentation z.B. mit anderen Zahlen rechnen als in der Dokumentation und ggfs. zu anderen Ergebnissen kommen. Die Prüfer, die die Dokumentation gelesen haben, werden sich dann zurecht fragen, wieso auf einmal ein anderes Ergebnis herauskommt.

Ignoriert ihr stattdessen euren Fehler und arbeitet mit den gleichen Werten aus der Dokumentation, ist die Chance groß, dass der Fehler entdeckt wird und zu interessanten Fragen im Fachgespräch führt. Natürlich könnt ihr dann sagen, dass der Fehler euch nicht aufgefallen ist, aber das spricht nicht gerade für eure Arbeit. Denn zweimal den gleichen Fehler zu machen – in der Projektdokumentation und erneut bei der Erstellung der Projektpräsentation, für die man den Stoff eigentlich noch einmal intensiv aufbereitet – deutet auf eine fehlende Qualitätssicherung hin.

Ich würde also dringend dazu raten, gefundene Fehler anzusprechen und gleich zusätzlich auf die Korrektur und die Auswirkungen auf das Projekt einzugehen, z.B. so:

Das Projekt hat insg. Kosten von 4.000 Euro verursacht. In die Projektdokumentation hat sich leider ein Rechenfehler eingeschlichen, sodass dort mit 3.500 Euro gerechnet wurde. Trotzdem amortisiert sich das Projekt noch innerhalb der geplanten 2 Jahre.

Oder ein anderes Beispiel:

In der Projektdokumentation habe ich leider vergessen zu erwähnen, dass ich mit ActiveRecord gearbeitet habe, um den Datenbankzugriff zu vereinfachen. Das ist Grund, warum meine Implementierungsphase für die Datenbankanbindung nur 1 Stunde gedauert hat. Dies hat allerdings keine Auswirkung auf den weiteren Projektablauf, der wie geplant durchgeführt wurde.

Die fehlerhaften Teile werden nicht in der Projektpräsentation erwähnt

Etwas anders verhält es sich, wenn die fehlerhaften Teile eurer Dokumentation gar nicht in der Projektpräsentation auftauchen sollen. Habt ihr z.B. einen Fehler in der Implementierung eures Unit-Tests gefunden, aber zeigt den Quelltext gar nicht in der Präsentation, gibt es auch keinen Grund, den Fehler anzusprechen.

Man sollte sich als Prüfling natürlich von seiner besten Seite zeigen und nicht die Teile der Projektarbeit hervorheben, die nicht gut gelaufen sind. Die Auswahl der interessanten und positiven Inhalte der Projektarbeit ist wichtiger Bestandteil des Prozesses zur Erstellung der Projektpräsentation. Niemand wird in der Projektpräsentation eine Liste aller gefundenen Fehler erwarten.

Bereitet euch aber bei allen gefundenen Fehlern auf Rückfragen im Fachgespräch vor. Fehler sind natürlich ein guter Einstiegspunkt in eine spannende Diskussion mit dem Prüfling 🙂 Überlegt euch schon vorher eine vernünftige Argumentation, falls ihr auf den Fehler angesprochen werdet, z.B.

Ja, den Fehler habe ich auch schon entdeckt. Er ist inzwischen im Programm behoben und die Software läuft korrekt. Dies haben auch die Benutzertests bestätigt. Dadurch wurde mir wieder einmal die Wichtigkeit von Unit-Tests bewusst, die diesen Fehler wahrscheinlich direkt aufgedeckt hätten. Alternativ hätte vielleicht ein Code-Review den fehlerhaften Code identifiziert. Das werde ich auf jeden Fall bei meinen zukünftigen Projekten berücksichtigen.

Wichtig dabei ist: Ihr solltet das, was ihr sagt, auch ernst meinen und nicht nur den Prüfern nach dem Mund reden. Seht jeden Fehler als potentielle Verbesserung eurer zukünftigen Arbeit!

Fazit

Fehler macht jeder. Aber das ist erst dann ein Problem, wenn man nicht aus ihnen lernt. Also geht offen mit euren Fehlern in der Projektdokumentation um und korrigiert sie in der Projektpräsentation.

Das bedeutet jedoch nicht, dass der Fokus auf euren Fehlern liegen sollte. Zeigt einfach, dass ihr etwas gelernt habt und behandelt die Fehler als das, was sie sind: ein normaler Bestandteil der Projektarbeit.

Wie seht ihr das? Habt ihr Fehler in eurer Dokumentation „gestanden“? Oder habt ihr sie verheimlicht? Wie ist das Ganze für euch ausgegangen?

Weitere Infos zur Projektpräsentation

Du suchst noch mehr Tipps rund um die Projektpräsentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektpräsentation.

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

---

Jetzt anmelden!