      |
 |
|
|
|
Projektmanagement |
kurzer Guide für ProjektmanagementInhalt
Allgemein:Ursprünglich war es uns ärgerlich bei jedem Projekt von neuem Informationen über Projektmanagement zu beschaffen um dann erst wieder zur Erkenntnis zu kommen, dass man einige gute Ideen aus den vorhergehenden Projekte (im Sinne des Projektmanagements) wieder nicht umgesetzt hatte und dadurch viel Zeit verloren geht. Aus dieser Motivation heraus, beschlossen wir bei diesem Projekt einmal alle Ideen und PM-Ansätze zusammenzuschreiben um beim nächsten Projekt schon einen praktischen Guide zur Verfügung zu haben. Und da es wahrscheinlich nicht nur uns so geht, haben wir gleich beschlossen, das ganze "Tutorial" auch für alle anderen zugänglich zu machen. Nun aber gleich mitten in die Materie. 1. KontaktWie schon eine alte Lebensweisheit meint: "der erste Eindruck ist immer der wichtigste.". Im Zuge dieses Leitsatzes gilt es vor allem bei jedem möglichen Projekt einen guten Eindruck zu hinterlassen. Da dieser erste Kontakt meist über das Telefon stattfindet, ist es wichtig immer einen Notizblock und einen (bzw. auch mehrere) Stift(e) bereitzuhalten, um gleich Notizen aufnehmen zu können, damit man bei einem Anruf eines möglichen Auftraggebers nicht gleich als schusselig und vergesslich dasteht. Ausserdem sollte man eine aufrechte Haltung einnehmen (auch wenn man "nur" telefoniert), da dadurch gewährleistet wird, dass man deutlicher spricht, was ohnehin extrem wichtig ist. Mit deutlichen und eigenen Worten sollte man die wichtigsten Aussagen zusammenfassen, um dem Auftraggeber das Gefühl zu geben und auch sicherzustellen, dass Sie die Dinge verstehen, die er Ihnen erzählt. Endresultat eines jeden ersten Kontaktes sollte ein Termin für ein persönliches Treffen sein. Warum ein persönliches Treffen in der IT Branche? Sie haben damit die Möglichkeit dem möglichen Auftraggeber ein Gesicht zu der Arbeit zu geben und eine stärkere Bindung zu schaffen. Sie sollten diese Möglichkeit schätzen, sich vorstellen zu können und näheren Kontakt herzustellen. Für dieses Treffen sollten Sie sich genug Zeit nehmen, jedoch sollte dieser Zeitrahmen nicht nur Ihrerseits vorhanden sein, sondern auch vom Gegenüber bestätigt. Dies gewährleistet, dass Sie genügend Zeit für Ihre Präsentation zu haben. Somit gleich zum 1.TreffenBevor Sie ins erste Treffen hineinstolpern, sollten Sie sich natürlich vorbereiten. Führen Sie Recherchen durch: Um welches Unternehmen handelt es sich? Welche Produkte werden angeboten? Mitbewerber? Lesen Sie sich etwas in die Branche ein und beschäftigen Sie sich mit dem Fachjargon dieses Gebiets. Schreiben Sie sich ein Konzept und planen Sie das gesamte Treffen durch; dazu sollten Sie das passende Outfit wählen, eine kurze Einleitung über Sie selbst (wer Sie sind, was Sie schon gemacht haben, usw.). Erlauben Sie Ihrem Gegenüber ein Bild von sich zu schaffen. Vergessen Sie auch nicht einen Notizblock mitzunehmen, und notieren Sie sich wichtige Details aus dem Gespräch. Ein weiteres wichtiges Utensil ist eine ansprechende Visitenkarte, um auch einen handfesten, materiellen und eindeutigen "Eindruck" zu hinterlassen. Nun auch noch eine kurze Checkliste für Fragendie beim ersten Treffen gestellt werden sollten (vor allem wichtig für Webauftritte):
Am Wichtigsten ist jedoch, dass, falls Sie kein Lastenheft direkt vom Kunden vorbereitet bekommen, dass Sie jenes gemeinsam mit dem Kunden erarbeiten. Ein Lastenheft soll die vom Auftraggeber gewünschten Funktionen enthalten. Eigentlich sollte dieses vom Auftraggeber geliefert werden, nur wird dies bei kleineren Projekten meist nicht getan, da ein derartiges Verfahren den Auftraggeber gar nicht interessiert. Somit haben Sie die Aufgabe die Ziele des Produktes herauszuarbeiten. Am besten gelingt dies, wenn Sie sich eine Liste mit möglichen Gewichtungen für das Projekt vorzubereiten (eine Liste mit Qualitätsmerkmalen eignet sich hervorragend dafür). Wenn Sie den möglichen Kunden diese Gewichtung machen lassen, bekommen Sie ein erstes Gefühl für das Projekt. Gemeinsam mit den Verantwortlichen sollten Sie nun die einzelnen Funktionen herausarbeiten. Ausserdem sollten Sie gleich vorab ansprechen, woher Sie Rohmaterial (z.B.Daten) für das Projekt bekommen. nach dem 1.Treffensollten Sie das Erabeitete nochmals Durchgehen und Analysieren. Nun ist es auch Zeit für eine erste Kosten-/Nutzenrechnung. Dabei sollten Sie sich die Fragen stellen:
Nun sollten Sie nach einiger Zeit nochmals eine schriftliche Zusammenfassung des gesamten Gesprächs (vor allem Lastenheft) dem möglichen Auftraggeber zusenden um noch einmal sicherzustellen, dass beide Seiten das gleiche meinen. Exkurs: Lastenheft ("Wunschliste des Kunden"): enthält alle Kundenwünsche
Eine weitere Lastenheftgliederung finden Sie auch in den Vorlagen unserer Downloadsektion. PflichtenheftNach diesem Schritt können Sie beginnen ein Pflichtenheft auszuarbeiten. Das Pflichtenheft baut auf dem Lastenheft auf, ist jedoch im Gegensatz zu diesem vom Auftragnehmer zusammengestellt und sollte so exakt wie möglich alle angebotenen Leistungen/Funktionen und Ergebnisse festhalten. Diese fachlich korrekte Zusammenfassung aller Forderungen aus Auftragsnehmersicht ist bei Aufträgen besonders wichtig, aus organisatorischen als auch aus rechtlichen Gründen. Deshalb muss auch eine einfach verständliche Sprache verwendet werden und alles sehr klar definiert sein, da es sowohl für den Auftraggeber als auch für den Entwickler eine Rücksicherung ist, damit sich das Projekt in klar definierten Grenzen bewegt und somit von keiner Seite Dinge eingefordert/nicht erbracht werden können. Ein mögliches Pflichtenheft könnte folgende Punkte beinhalten:
Wichtig dabei ist auch das Pflichtenheft und das Lastenheft gesondert zu verrechnen (und darauf auch im Vorhinein hinzuweisen), da beim Erstellen dieser Dokumente viel Aufwand dahintersteckt, obwohl noch kein Auftrag zustandegekommen ist. Bekommt man den Auftragszuspruch schliesslich nicht, hätte man diese Arbeit umsonst gemacht. Das erstellte Pflichtenheft kann so auch vom Auftraggeber verwendet werden, falls er sich entschliesst mit einem anderem Auftragnehmer zusammenzuarbeiten. Imaginäre Kundenanforderungen an das Projekt niCEKundenzufriedenheit ist der Schlüssel zum Erfolg.Das Projekt niCE ging von Beginn an nur von imaginären Kundenanforderungen aus, da kein wirklicher Auftrag zur Durchführung dieses Projekts vorlag. Auf Grund der hohen Bedeutung von Kundenzufriedenheit in der Software-Entwicklungsbranche haben sich die Projektteilnehmer dennoch Gedanken darüber gemacht, wie solche Kundenanforderungen aussehen könten. Hier die zu Beginn des Projekts angefertigte Liste:
Angebot und Mitarbeiter:Nun da Sie das Pflichtenheft bereits erstellt haben, können Sie auch beginnen ein Angebot zu erstellen: dazu müssen Sie einen vorläufigen Projektplan erstellen und den zu erwartenden Aufwand schätzen. Wie machen Sie das? Am Besten teilen Sie das Projekt zuerst in Phasen, dann die Phasen wiederum in kleinere Module. Diese Auftrennung betreiben Sie solange bis Sie untrennbare und leichter abschätzbare Teile haben. Diese Teile können Sie nun schätzen. Da der Mensch jedoch dazu neigt sich selbst "besser" einzuschätzen, kommt es oft zu zu knappen Kalkulationen.
Nun ist auch der Zeitpunkt gekommen, Ihre Wunschmitarbeiter anzusprechen und vorab zu fragen, ob Sie noch über freie Kapazitäten verfügen. Sie sollten sich im Übrigen angewöhnen eine Adressliste zu erstellen mit möglichen Teampartnern, deren Arbeit Sie schätzen und die auch mit Ihnen gut zusammenarbeiten. Falls Sie über eine solche Liste noch nicht verfügen, sollten Sie über einschlägige Foren, usw. beginnen sich Mitarbeiter zu suchen und anzuschreiben. Dabei sollten Sie folgende folgende Grundregeln beachten:
Nachdem Sie das mögliche Projektteam zusammenhaben, können Sie auch die Stundensätze der einzelnen mit den Aufwänden zu multiplizieren und können somit Ihr Angebot erstellen. Ausserdem haben Sie auch die Möglichkeit Teile des Projekts als externe Teilleistungen zu deklarieren und durchzuführen (dh. dass Sie nicht alles am Projekt selbst durchführen, sondern wieder diese Teile als Projekte an andere Firmen vergeben). Für was auch immer Sie sich entscheiden, letztendlich sollte ein Angebot entstanden sein, wobei Sie nicht alles zu genau aufschlüsseln sollten, da es sonst passieren kann, dass der Auftraggeber beginnt, Ihr Angebot zu zerpflücken, da er wichtige Aufwände wie zB. Dokumentation oder vieles mehr für nicht so wichtig empfindet. Jedoch sollten die einzelnen Positionen auch für den Auftraggeber nachvollziebar sein. Legen Sie auch Teilzahlungen fest, damit Sie das Projekt nicht selbst vorfinanzieren müssen und das Risiko tragen, dass der Auftraggeber die gesamte erbrachte Leistung nicht bezahlen kann. Diese Teilzahlungen werden am Besten mit der Abnahme von Teilleistungen kombiniert und sollten auch im Pflichtenheft festgehalten werden. Ein weiterer wichtiger Punkt ist, dass Sie einen bestimmten Gültigkeitszeitraum für das Angebot festlegen, da Sie die Mitarbeiter nicht die ganze Zeit auf Abruf halten können und da sich ja auch die Stundensätze ändern. Wenn Sie nun meinen das Angebot abgeschlossen zu haben, schicken Sie es schriftlich an den Auftraggeber. Falls Sie trotzdem das Angebot als Email schicken wollen, sollten Sie das Angebot in gekapselter Form schicken (dh. zB. als PDF), damit so leicht keine Veränderungen seitens des Kunden möglich sind. Dann heisst es erstmal abwarten. Nach 5-8 Tagen, falls noch keine Rückmeldung gekommen ist, können Sie einmal höflich nachfragen, ob sich schon etwas getan hat. Dabei ist es jedoch wichtig auf keinen Fall lästig zu werden. Nachdem der Auftraggeber das Angebot durchgearbeitet hat, wird er Sie meist um weitere Vertragsverhandlungen bitten. Bereiten Sie auch diese vor. Setzen Sie sich schon im vorhinein eine Untergrenze, die Sie auf keinen Fall unterschreiten wollen (dabei muss natürlich auch eine angemessene Gewinnspanne enthalten sein). Eventuell können Sie auch Zusatzangebote vorbereiten, die für Sie weniger Aufwand bringen, als Sie dem Auftraggeber nutzen. Bei den Verhandlungen sollten Sie auch darauf achten, dass Sie sich nicht aufweichen lassen und nur den Preis nach unten korrigieren. Falls Sie mit dem Preis nach unten gehen, sollten Sie auch entsprechende Leistungen kürzen, da sonst die Qualität der Arbeit darunter leiden würde. Haben Sie schliesslich den Zuschlag bekommen (lassen Sie sich die Auftragserteilung auf alle Fälle auch schriftlich geben!), können Sie mit Ihren Mitarbeitern Kontakt aufnehmen und auch ihnen den Auftrag bestätigen. Konzeption und Vorarbeiten:Beginnen Sie nun Ideen zu sammeln, sprechen Sie mit Bekannten (müssen nicht IT Experten sein) über das Projekt und lassen Sie sich inspirieren. Bringen Sie Ihre Ideen auch immer gleich zu Papier, damit Sie nichts vergessen. Sortieren Sie anschliessend Ihre Ideen. Dabei können Sie auf hilfreiche Tools zurückgreifen, wie Tools die es erlauben MindMaps zu erstellen oder Outline-Dokumente. Nachdem Sie Ihren Ideenstrom festgehalten haben, sollten Sie diesen nun auch sortieren und eine klare Linie ausarbeiten, wie Sie das Projekt nun umsetzen wollen. Nun beginnt das Erstellen des Configuration ManagementJe größer das Projekt, desto größer der Planungs-, Regel- und Dokumentationsaufwand.
Als Grundlage unserer Überlegungen auf diesem Gebiet diente der Grundsatz: "Aktualität und Einheitlichkeit ist alles". Da wir in manchen Teilen des Projektes (speziell in der Implementierungsphase) sehr eng zusammengearbeitet und teilweise auch dieselben Dateien zur selben Zeit bearbeitet haben, war es notwendig alle Dokumente für alle Projektteilnehmer aktuell verfügbar zu halten. Wir waren leider gezwungen unser Projekt auf 2 Server auszulagern: der Erste für administrative Dokumente und der Zweite für Source-Code. Warum leider? Es macht einfach viel mehr Arbeit 2 Server zu verwalten als mit einem Server zu arbeiten. Das ist auch schon alles. Was die Einheitlichkeit betrifft, haben wir ein eigenes Regelprotokoll verfasst, dass zB für die Programmierung Richtlinien vorgibt. Das Sich-an-Regel-halten-Müssen nervt natürlich am Anfang enorm, da man möglicherweise ganz andere Regeln gewohnt ist. Wir haben aber gemerkt, dass man sich sehr schnell einarbeitet. Hat man sich erst einmal an manche Regeln gewöhnt, geht Vieles einfach leichter. Das ist ja auch ein Grund für die Vorteile, die aufeinander eingespielte Teams haben: Regeln, etc. sind klar definiert, man muss wenig sagen und kann gleich losstarten. Was aber sollte erledigt werden, um alle Dokumente verfügbar und einheitlich zu halten? Hier eine Checklist zum Thema:
Motivation zur Ablage einer DB für CMDer Grund, aus dem man sich mit CM auseinander setzt, ist die klare Strukturierung eines Projekts. Datenbanken bringen Ordnung in Versionsführung und bieten außerdem eine zentrale Übersicht über möglicherweise dezentral verwaltete Dokumente. Wir haben in unserem Projekt nur eine Datenbank für Dateien angelegt. Man kann aber auch mehrere Datenbanken verwenden (zB eine für Sourcecode-Dateien, eine für Projektmanagement-Dateien). Außerdem kann man auch Datenbanken für Funktionen anlegen, das heißt: Jede Funktion wird dokumentiert, indem ihre Source-Datei angegeben wird und diverse Abhängigkeiten. Generell gilt: Je größer das Projekt, desto besser muss man sich die Datenbankumgebung überlegen. Zurück zu unserem Projekt: Wir haben - wie gesagt - nur eine Datenbank für Angaben zu den im Projekt verwendeten Dateien angelegt. Hier einige Hinweise, was in einer solchen DB enthalten sein sollte:
Wichtig ist außerdem, dass alle Projektteilnehmer Zugriff auf diese Datenbank haben. Ordnerstruktur im ProjektUm die geplante Projektstruktur auch elektronisch umzusetzen, empfiehlt es sich eine geeignete Ordnerstrukur für Ihr Projekt anzulegen. Es kommt natürlich auf den Typ des Projektes an, welche Struktur Sie wählen. In diesem Abschnitt wird ein kurzer Überblick über eine mögliche Struktur für ein Softwareentwicklungsprojekt mit der Programmiersprache ANSI-C vorgestellt.
Kurzer Exkurs: Was ist ein Dokument?Ein Dokument ist eine - meist für alle Mitarbeiter eines Projektes - bindende Zusammenfassung von Information. Diese kann enthalten wie sich der Mitarbeiter in einem Projekt zu verhalten hat, wie kommuniziert wird, wie programmiert wird, etc. Es wird generell zwischen internen und externen Dokumenten unterschieden, wobei interne Dokumente selbst erstellt werden (von irgendeinem befugten Projektteilnehmer) und externe Dokumente - wie der Name schon sagt - von außen kommen (zB Gesetze, staatliche Richtlinien etc.). Beispiel: Richtlinien. Nicht zu Dokumenten zählen Protokolle und Informationen, die nicht bindend sind. Verwendete Software im Projekt niCEUm das Projekt möglichst realisitisch zu gestalten, wurde neben Programmiersoftware auch Projektmanagement-Software verwendet. Geben Sie die Dateiformate der verwendeten Programme an, um anderen Projektteilnehmern das Leben zu erleichtern. Hier die Liste des Projekts als Beispiel (ohne Dateierweiterungen):
ProjektplansFalls Sie nicht geübt sind in der Handhabung von Projektmanagementtools, würde ich Ihnen empfehlen, die Projektplanung von Hand auf einem gewöhnlichen Blatt Papier vorzunehmen, auch auf die Gefahr hin, dass dies als steinzeitlich interpretiert werden könnte. Die Projektplanung wird ohnehin Ihre ganze Konzentration aufwenden, sodass Sie sicherlich keine Zeit haben, "nebenbei" auch noch neue Funktionen zu erstellen. Ausserdem kennen Sie dann auch wahrscheinlich gar nicht die besten Möglichkeiten, das Projekt digital zu verarbeiten. Aus diesen Gründen - Mut zu Papier und Stift. Vorerst sollten Sie das Projekt in einzelne Teilphasen gliedern: diese sollen eine relativ grobe Gliederung darstellen, was alles im Laufe des Projekts geschehen muss. zB:
Diese Phasen sollten Sie nun immer weiter verfeinern bis Sie von diesem eher allgemeinen Teil auf lauter kleine Module, die bereits den Inhalt und Umfang Ihres Projekts erkennen lasssen, kommen. Ob die Grösse der Module richtig ist, erkennen Sie daran, wenn Sie sich leicht abschätzen lassen. Nun müssen Sie die einzelnen Module nach zeitlichen und funktionalen Abhängigkeiten untersuchen und dies auch zu Papier bringen (dabei können Flussdiagramme sehr hilfreich sein). Nachdem Sie die einzelnen Aufwände geschätzt haben, können Sie mithilfe der möglichen Arbeitszeit Ihrer Mitarbeiter den Modulen auch Termine zuteilen. So entsteht ein relativ genauer Zeitplan für Ihr Projekt. Eventuell sollten Sie auch Pufferzeiten miteinplanen, wenn Sie erwarten, dass Komplikationen auftreten können oder wenn das spezifische Modul auch alle anderen Module verzögern würde. Ein weiterer Trick kann angewnadt werden um Mitarbeiter, die notorisch alles zu spät beginnen, ein bisschen unter Kontrolle zu bringen: Deadlines für die Module einfach für den Mitarbeiter früher setzen und sich im Hintergrund Pufferzeit vorbehalten. Dies mag nicht die ehrlichste Methode sein, kann aber das rechtzeitige Fertigstellen sicherstellen. Dabei sollten Sie auch nicht vergessen, dass Sie auch weiterdelegieren können. Da Sie ohnehin die Aufgabenbereiche auf Ihre Mitglieder verteilen sollten und so pro Aufgabengebiet - das Ihrer Ansicht nach für den Bereich - fähigste Mitglied einteilen sollten (diesem auch klipp und klar die Aufgabe übertragen; auch in der Projektplanung festhalten), können Sie auch demjenigen die Aufschlüsselung und Planung seines Teilbereichs überlassen. Sie sollten nun über eine relativ genaue Strukturierung Ihres Projekts verfügen, die es Ihnen ermöglicht Meilensteine zu definieren. Diese Meilensteine sollen dazu dienen, dass Sie und der Auftraggeber den Projektfortschritt anhand von festgesetzten Punkten einfach überprüfen können. Aus dieser Definition ergibt sich eigentlich auch, wie man die Meilensteine wählen sollte. Weiters sollten Sie schon im Auftrag ausgehandelt haben, dass abhängig vom Erreichen der einzelnen Meilensteine, bereits Teilzahlungen vom Auftraggeber erfolgen (siehe Auftrag). Falls Sie sich, wie empfohlen, dafür entschieden haben, den Projektplan von Hand anzulegen, müssen Sie diesen nun auch digitalisieren, um Ihn den anderen Projektmitgliedern zugänglich zu machen. Dazu gibt es mehrere Möglichkeiten:
Wie schon beim letzten Punkt angeklungen ist, wichtig ist immer eine verhältnismässige Lösung. Beinhalten muss der Projektplan auf alle Fälle:
Nun da Sie Ihren Projektplan erstellt haben, sollten Sie jedoch nicht in den Irrglauben verfallen, dass es damit mit den Terminen getan sei, und sich jeder seine Termine heraussucht. Teilen Sie ihren Mitgliedern die Projekttermine immer wieder mit und machen Sie sie darauf aufmerksam. Sie sind verantwortlich für die Einhaltung des Projektplans und der Termine. Dies ist besonders schwer, wenn es sich um ein kleineres Team handelt, und Sie selbst in der Entwicklung mitarbeiten, da Sie dann selbst gerne Termine übersehen, weil noch sooooo viel zu tun ist. Projekthandbuch:Angenehm kann es auch sein zusätzlich zu dem Projektplan ein sogenanntes Projekthandbuch zu haben, dass auch später als Referenz für Teammitglieder dienen kann. Im Projekthandbuch sollte eine Einführung für alle Teammitglieder sein und allgemein Infos über das Projekt. folgende kompakte Struktur hat sich als vorteilhaft herausgestellt:
Nach soviel Arbeit nun erst zum allgemeinen KickOff -MeetingDies soll dazu dienen, den Mitarbeitern, die nicht bereits in der Vorausplanung involviert waren, einen eindeutigen Projektstart aufzuzeigen und alle Mitglieder mit einer fix deklarierten Wissensbasis ins Rennen zu schicken. Alles was Sie am KickOff Meeting besprechen und offiziell ansprechen, kann als Basiswissen der Mitglieder angenommen werden. Dabei sind vor allem Dinge wie CM wichtig um die Mitglieder über die Projektstruktur und Organisation einzuweihen. Dies sollte besonders gründlich erledigt werden und es sollte auch auf Dateien hingewiesen werden, die als Referenz des Gesagten dienen sollen. Weiterer Projektverlauf:Nun sollte der Planungsverlauf für das Projektmanagement abnehmen, was jedoch nicht heisst, dass dieses Untätig sein darf. Es gilt mit den Mitgliedern in Verbindung zu bleiben, sich über den Projektverlauf im Klaren zu sein, mögliche Probleme für die Mitglieder zu lokalisieren und ev. vorzeitig zu entfernen. Auch müssen der Projektplan und die Berichte aktuell gehalten werden und der Kontakt zum Auftraggeber gewahrt werden. Wie sich schon herauslesen lässt, das wichtigste während des Projekts für das Managements ist es, den persönlichen Kontakt zu halten und immer über alles den Überblick zu behalten. Falls etwas nicht nach Plan laufen sollte, müssen natürlich auch geeignete Gegenmassnahmen eingeleitet werden. Projekabschluss:Wenn Sie mit Ihrem Projekt von Ihrer Sicht fertig sind, teilen Sie dies auch dem Auftraggeber schriftlich mit. Tun Sie das auch, wenn Sie mit Ihm während des Projekts in engem Kontakt standen und er darum weiss, dass Sie aus Ihrer Sicht fertig sind. Diese Mitteilung sollte auch eine Einladung zur kritischen Begutachtung beinhalten, und ev. auch gleich einen Termin vorschlagen. Die Prüfung soll anhand des Pflichtenhefts erfolgen und innerhalb ruhiger Athmosphäre stattfinden. Treten Kritikpunkte auf, so notieren Sie diese vorerst ohne jegliches Gegenargument einzuwerfen. Hinterfragen Sie jedoch die angeführten Punkte um ein besseres Verständnis dafür zu bekommen. Hat der Kunde das Produkt begutachtet, so teilen Sie ihm mit, dass Sie nun die angeführten Punkte überarbeiten wollen und sehen was verwirklichbar ist. Nehmen Sie sich etwas Zeit und gewinnen Sie etwas Distanz. Anschliessend sollten Sie die Punkte durcharbeiten und vorab prüfen, ob es sich um Mängel, die im Sinne der Gewährleistungspflicht behoben werden müssen, handelt oder um Zusatzleistungen, die im Pflichtenheft nicht angeführt wurden, jetzt aber verlangt werden. Handelt es sich um Mängel sind diese natürlich schnellstmöglich und ordentlich nachzubessern. Falls es sich um Zusatzleistungen handelt, sollten Sie den Auftraggeber darauf hinweisen, dass dies nicht Bestandteil des Pflichtenhefts sei und deshalb gesondert verrechnet werden muss. Sind es jedoch nur Kleinigkeiten, die sich der Auftraggeber wünscht, ist es besser, zwar auf die Zusatzleistung hinzuweisen, den Forderungen jedoch unentgeltlich nachzukommen, da man von Weiterempfehlungen und Folgeaufträgen somit weit mehr profitiert als von Paragraphenreiterei. Prinzipiell sollten jedoch nicht allzuviele Kritikpunkte auftreten, falls man mit dem Auftraggeber enger zusammenarbeitet und diesem auch immer wieder die Möglichkeit zur Einsicht gibt. Sind keine Kritikpunkte mehr vorhanden, sollte man sich die Projektabnahme schriftlich geben lassen. Als Zusatzservice Ihrerseits wäre es auch eine gute Idee stets eine Liste mitzuführen mit möglichen Verbesserungs- und Erweiterungsvorschlägen, die im Laufe des Projekts auftauchen, da keiner das Projekt jemals mehr so gut kennen wird, wie Sie zu diesem Zeitpunkt tun. Dies ist einerseits ein netter Service für den Kunden, falls er das Produkt später weiterentwickeln lassen will und andererseits gleich eine Möglichkeit wie Sie ev. einen Folgeauftrag erhalten. Abschliessen sollten Sie das Projekt mit einem Hinweis für den Kunden, dass in 6 Wochen Produktmängel nicht mehr sofort behoben werden müssen, da zu diesem Zeitpunkt die Ressourcen wahrscheinlich schon für andere Projekte verplant sind. Auch sollte geklärt werden, wie mit Supportanfragen umgegangen werden soll und ob der Wunsch des Kunden auf Support besteht (Standardstundensatz oder Pauschalpreis). Besteht dieser Wunsch so sollte man dem Kunden einen Terminplan zukommen lassen, wann und wo welche Spezialisten für ihn verfügbar sind. Zum Projektabschluss innerhalb des Teams gehört natürlich auch, dass Sie den erflogreichen Abschluss den Mitarbeitern mitteilen und Ihnen konstruktives Feedback geben und sich auch Rückmeldungen geben lassen. Am besten wäre es, das Projekt mit einem gemütlichen Essen ausklingen zu lassen und auf den erfolgreichen Abschluss anzustossen. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
