Präsentation - Projektziel nicht erreicht

[Ein Byte namens Bernd]

Hallo,

nächste Woche Freitag halte ich meine Projektpräsentation und mein Ausbilder meint, ich solle meine Präsentation etwas anders anpacken.

Das Gesamtziel des Projektes habe ich nicht erreicht, das war in der Zeit nicht zu schaffen. Meine Planung ist also schon mal falsch gewesen - was nicht verwunderlich ist, da ich nur eine schlechte schulische Ausbildung genossen hatte und vor diesem Projekt keine wirkliche Praxis hatte. Mittlerweile ist der Ausbilder insolvent gegangen und das letzte halbe Jahr wurde ich von einer Behörde übernommen, die mir ein Projekt übergab.

Mein Ausbilder ist ganz zufrieden mit meiner Arbeit und meint, ich hätte das alles nicht in der Zeit schaffen können. Nun möchte ich in meiner Präsentation wie schon in der Dokumentation erläutern, aus welchen Gründen ich einige Ziele nicht erreicht habe. Aus Sicht meines Ausbilders sei das eine zu negative Herangehensweise. Ich solle eher alles Positive präsentieren und den Rest für das Fachgespräch aufbewahren.

Hat mein Ausbilder Recht? In diesem Falle wüsste ich gar nicht, wie ich die Präsentation gestalten soll. Schließlich erläutere ich im Soll-Konzept Funktionen, die gar nicht umgesetzt worden sind.

Ich würde lieber meine bisherige Präsentation zwar überarbeiten, aber das Ansprechen auf die eingetretenden Probleme drin lassen.

Wie seht ihr die Sache?

[i � unicode]

Hi

Das Soll-Konzept heisst "SOLL-Konzept", weil es darstellt, wie es später sein SOLL.

Ob du dein Ziel erreichst oder nicht, ist nicht ausschlaggebend für das Abschlussprojekt. Es gibt durchaus Projekte, die nicht zuende geführt werden (können).

Du solltest dies jedoch von vorn herein so aufzeigen.

Wenn in deiner Dokumentation steht, dass du alles problemlos durchgezogen und dein Ziel ohne weiteres erreicht hast, dann allerdings in der Präsentation genau das Gegenteil aufführst, werden die Prüfer stutzig. Ob das zum nicht-bestehen führen kann, weiss ich nicht. Du musst dich allerdings auf recht eindringliche Fragen einstellen.

Es ist keine Schande ein Ziel in der vorgegebenen Zeit nicht zu erreichen. Du solltest allerdings ausführlich erläutern wieso du es nicht erreichen konntest. "Schönreden" solltest du da nichts. Vor allem solltest du aufzeigen, wo genau du nun stehst.

Eine gute Präsentation wird nicht am Projektergebnis gemessen, sondern an der Art und Weise, wie das Ergebnis vermittelt wird. Im späteren Berufsleben wird auch nicht jedes Projekt 100%ig erfolgreich sein. Man sollte dem Kunden/Geldgeber gegenüber aber wenigstens ehrlich sein und erklären wo die Probleme liegen.

[Ein Byte namens Bernd]

In meiner Dokuementation habe ich unter Durchführung geschrieben, was ich erreicht habe und unter Abschluss einen Soll-Ist-Vergleich durchgeführt. Dort habe ich erläutert, welche Probleme zu einem Nichterreichen des Gesamtziels geführt haben. Also ist dem PA, der die Doku kennt, schon klar, das ich nicht alles geschafft habe.

Dann bleibe ich bei meiner Präsentationsstrategie und gehe auf die Probleme ein. Nach meinem IHK-Projekt habe ich weiter an der Anwendung gearbeitet. Dieses Folgeprojekt möchte ich im Fazit kurz erwähnen und aufzählen, was die Anwendung im aktuellen Stand nun im Vergleich zur Dokumentationsabgabe nun alles mehr kann. Ist das ratsam oder sollte ich vielleicht etwas mehr darauf eingehen? Letztendlich gehört es ja nicht ganz zu dem Projekt, das ich im Rahmen der IHK-Prüfung durchgeführt habe.

Ist denn davon auszugehen, dass jeder der drei vom PA auch die Doku gelesen hat? Ich hatte irgendwo mal aufgeschnappt, dass bei uns meist nur einer die Doku gelesen hatte und die anderen beiden gehen ohne Vorwissen in die Präsentation.

[i � unicode]

Ist denn davon auszugehen, dass jeder der drei vom PA auch die Doku gelesen hat?

Das ist von IHK zu IHK unterschiedlich. Das kann dir (bis auf den Prüfungsausschuss) niemand sagen.

Ich würde erwähnen, dass du (beispielsweise) in der vorgegebenen Zeit bei 80% aufhören musstest, dieses Projekt allerdings danach weitergeführt und vollendet hast. Du solltest davon aber nicht viel in die Präsentation aufnehmen. Es ist nicht Bestandteil des Projektes.

Beschränke dich auf das, was du innerhalb des Projektzeitraumes geschafft (oder nicht geschafft) hast.

Ich denke, dass du trotzdem auf dem richtigen Weg bist

[Ein Byte namens Bernd]

Okay, danke für die Hilfe!

[i � unicode]

Meine Antwort(en) sollten nicht die einzigen sein, auf die du dich beziehst. Kann ja auch sein, dass ich das völlig falsch sehe.

Am besten wartest du noch ein paar (andere) Meinungen ab.

[XspYroX]

Kommt u.a. darauf an, bei welcher IHK du deine Abschlussprüfung hast und worauf deren Schwerpunkt liegt.

Im allgemeinen ist es aber wie folgt:

Es geht in deiner Abschlusspräsentation NICHT primär um das Ergebnis.

Es geht in ERSTER Linie darum, WIE gut du dein Projekt dokumentiert hast, wie du vorangegangen bist, welche Überlegungen du dir gemacht hast, wie du geplant hast, wo es Probleme gab (und vor allem wie du diese dann gelöst hast) und so weiter...

Die Herangehensweise ist das wichtigste. Ob dein Projekt am Ende fertig ist oder nicht, spielt bei der benotung absolut keine Rolle. Hauptsache du legst den Entstehungsprozess deines Abschlussprojektes gut dar

Hätte ich das selber vor nem Jahr besser beachtet, hätte ich auch ne bessere Note gehabt ^^°

Viele Grüße

[Pixie]

Es geht in ERSTER Linie darum, WIE gut du dein Projekt dokumentiert hast, wie du vorangegangen bist, welche Überlegungen du dir gemacht hast, wie du geplant hast, wo es Probleme gab (und vor allem wie du diese dann gelöst hast) und so weiter...

Die Herangehensweise ist das wichtigste.

Wenn ich das so lese...

Wie detailiert beschreibt man denn dann sein Vorgehen und die kleinen und größeren Probleme? Es gab im Projekt die 1-2 großen Stolpersteine, die natürlich beschrieben und erläutert werden. Was ist mit dem ganzen "Kleinmist"... Wir haben irgendwann gemerkt, die Client-Server-Kommunikation schlägt fehl... geguckt, okay: Encoding paßt nicht. Also Spezifikation ums Encoding ergänzt. Weiter gemacht, Timeout-Problem... behoben.

Wie weit geht man da in die Tiefe?

Dann enthielt bei mir die Planungsphase recht viel Recherche in MSDN und Dokumentationen von Drittherstellern, Einarbeitung in den Quellcode des Projektes, das ich erweitert habe... Das waren Projektabschnitte, die nicht wenig Zeit beansprucht haben, man kann aber nicht großartig viel dazu erzählen ("hab in der MSDN auf den nächsten Link geklickt... und noch einen" kommt vielleicht nicht sooo toll). Wie räumt man dem im Vortrag den nötigen Stellenwert ein? Bedeutungsvoll mit den Augen rollen?

Wie stelle ich eine Kosten-Nutzen-Analyse dar, wenn ich eigentlich nicht erzählen möchte, wieviel das fertige Produkt kostet und wievielen Kunden es erfolgreich angeboten wurde bzw. wie groß der Kundenstamm mit Interesse daran ist?

Fragen über Fragen...

.