<Ihr Logo>
Lesehinweis:
�
Alle Angaben in kursiver dunkelblauer Schrift sind im Dokument zu ersetzen und
dienen als "Anleitung". Es existiert eine zweite Fassung dieser Vorlage im
Word-Format ohne diese Kommentare, die zum Ausfüllen geeigneter ist als
diese Anleitung, die Sie einfacher als Vorlage für eigene Dokumente verwenden
können.
Sie finden diese unter www.markus-baersch.de/projektmanagement-vorlagen.html
Dort ist ebenso - wenn Sie gerade ein PDF betrachten - eine Word-Datei dieser
kommentierten Fassung erhältlich.
Interne Fassung: 2.0 vom 10.04.2006; Reformatiert für Webansicht am 01.07.2011
Projektauftrag
Vorlage Projektauftrag
Version 0.1
Tipp: Dokumentfelder nutzen!
Dies ist ein Dokumentenfeld, welches Sie über die rechte Maustaste
aktualisieren können, nachdem Sie den Titel Ihres Projekts und den Autoren in
den Eigenschaften des Dokuments unter "Datei - Eigenschaften" eingetragen
haben.
Nutzen Sie die Dateieigenschaften, um Dokumente unter Windows möglichst effizient (durch)suchen zu können!
Nutzen
Sie die Dokumentfelder auch im Deckblatt und aktualisieren Sie Autor und
Dokumentname, wenn Sie die Eigenschaften korrigiert haben! Das Datum der
Erstellung sollten Sie zur Übersicht hier auch manuell eintragen und nicht aus
dem Dokument als Feld übernehmen - schließlich basiert fast jedes neue Dokument
auf einer Vorlage oder einer Fassung eines älteren Projekts durch Anpassung...
Historie der Dokumentversionen
Version |
Datum |
Autor |
Änderungsgrund / Bemerkungen |
0.1 |
<Eintragen> |
<Ihr Name> |
Ersterstellung |
0.2 |
<Eintragen> |
<Ihr Name> |
Geben Sie an, warum das Dokument verändert wurde und gegen Sie Links mittels "Einfügen - Hyperlink - Aktuelles Dokument" auf neue Abschnitte. Verwenden Sie bei Bedarf dazu auch Textmarken, um genaue Stellen im Dokument zu treffen. |
|
|
|
|
|
|
|
|
Wozu das denn?
Wenn ein Dokument nicht gleich in einem Schritt entsteht;
zwischenzeitlich Änderungen erfährt oder auch nach der eigentlichen "Benutzung"
noch angepasst werden könnte, spendieren Sie jedem Dokument eine
Historie. Nur so können Sie sicherstellen, dass Sie einigermaßen vernünftig
nachvollziehen können, ob Sie eine aktuelle Fassung in der Hand halten, welche
Anpassungen seit der Erstellung aus welchem Grund durchgeführt wurden und ggf.
auch, wer diese Änderungen durchgeführt hat - vor allem dann, wenn die
Erstellung schon ein paar Monate zurückliegt.
Tipp: Änderungen nachverfolgen
Sie sollten diese Funktion auch dann benutzen, wenn Sie die Nachverfolgung
von Änderungen ("Extras") ebenso eingeschaltet haben, da ab einer bestimmten
Anzahl von Überarbeitungen keinesfalls nachvollziehbar ist, was genau wann
geändert wurde, weil die Ansicht extrem unübersichtlich wird.
Die Spalte
"Autor" benötigen Sie natürlich nur dann, wenn mehrere Autoren an einem
Dokument arbeiten; sonst genügt der "Hauptautor" aus dem Deckblatt
Inhaltsverzeichnis
Historie der Dokumentversionen
1.1.1��������� Zweck und Ziel dieses Dokuments
1.1.3��������� Ablage, Gültigkeit und Bezüge zu anderen Dokumenten
1.2.1��������� Projekttitel / Projektkürzel
1.2.5��������� Lenkungsausschuss
1.3������� Reviewvermerke und Meeting-Protokolle
1.3.1��������� Erstes bis n-tes Review
2.1.1��������� Übersicht Projektziele
2.1.2��������� Details zur Zieldefinition
2.1.3��������� Kennzahlen zur Zielerreichung
2.2.1��������� Rollen und Verantwortlichkeiten
2.3������� Rahmenbedingungen, kritische Erfolgsfaktoren und Rollen
2.5.1��������� Rentabilitätsbetrachtung
2.6������� Übersicht der Meilensteine
2.8������� Freigabe / Projektentscheid
Formatdisziplin:
Das Verzeichnis funktioniert nur dann, wenn Sie sich an die Formatvorlagen
für Überschriften, Fließtext etc. halten. Dieses Dokument besitzt für Tabellen,
Zwischentitel etc. gesonderte Dokumentvorlagen. Diese ermöglichen es auch
besser, komplette Dokumente ggf. nachträglich an ein CI anzupassen. Gewöhnen
Sie sich einfach Formatvorlagen an, wenn Sie mit Word arbeiten, sie sind sehr
praktisch!
1 Einleitung
1.1 Allgemeines
1.1.1 Zweck und Ziel dieses Dokuments
Dieses Dokument beschreibt die Rahmenbedingungen für und Anforderungen an das im Titel genannte Projekt. Es dient...
- zur Definition des Projektziels und
- des groben Projektverlaufs;�
- der Findung aller beteiligten Personen und Institutionen sowie der benötigten Ressourcen
- zur Vorbereitung eines Projektentscheids und
- Kommunikation der Ziele und Meilensteine an alle Beteiligten
Nachtragen: die individuelle Zielsetzung des Auftrags für Ihr konkretes Projekt. Achtung: nicht die Projektziele eintragen, die kommen erst im nächsten Abschnitt. Hier wird also nur das Ziel des Projekts "Projektauftrag" definiert!
1.1.2 Abkürzungen
[Optional:] Ein Dokument ist nur dann lesbar, wenn alle Leser eine Chance bekommen, es zu verstehen. Führen Sie hier entweder einen Verweis zu einem internen Dictionary im Intranet, Wortlisten und Begriffserklärungen in anderen Dokumenten und / oder individuelle Abkürzungen für Personen oder anderen "Betriebsjargon" hier ein, wenn z. B. jemand außerhalb Ihres Unternehmens am Projekt beteiligt sein sollte. Das vermeidet Rückfragen.
1.1.3 Ablage, Gültigkeit und Bezüge zu anderen Dokumenten
Geben Sie an, an welcher Stelle dieses Dokument in seiner einzig gültigen Fassung abgelegt ist! Alle anderen Fassungen sind lokal und dienen höchstens der Lektüre, aber nie als Basis für eine Überarbeitung! Stellen Sie sicher, dass es einen geeigneten zentralen Ort zur Ablage aller Dokumente gibt (es muss ja nicht gleich ein teures DMS sein, aber ein zentraler Ordner - im Netzwerk - , der regelmäßig gesichert wird, ist sicher sinnvoll!
[Optional:] Bezieht sich das Dokument auf eine bestimmte Fassung Ihres Produkts? Wenn ja, benennen Sie dies an dieser Stelle. Gibt es Verweise zu anderen internen Dokumenten? Geben Sie dies gleich hier an, wenn diese ebenso in einem zentralen Ablageort zu finden sind. Externe Quellen und Verweise
1.2 Projektstammdaten
1.2.1 Projekttitel / Projektkürzel
Fast alle Projekte dieser Welt haben einen Codenamen oder ein Kürzel oder andere Bezeichnungen, die in den internen Sprachgebrauch übergehen und eigentlich etwas anderes, nämlich das fertige Produkt meinen, welches dann oft ganz anders heißt. Eintragen vermeidet Verwechslungen!
1.2.2 Auftraggeber
Es sollte klar sein, wer Initiator des Projekts ist und wer (das muss nicht die gleiche Person sein) den Auftrag dazu gegeben hat. Das mag heute noch ganz klar sein, bei längeren Projekten geht diese Information aber tatsächlich in der echten Welt ab und zu verloren! Tragen Sie es einfach ein, selbst wenn es nur Ihr eigener Name ist. Man weiß ja nie...
1.2.3 Projektleiter
Einer hat den Hut auf - das ist immer so und muss so sein! Benennen Sie ihn hier oder nominieren Sie Personen, wenn dieses Dokument als Diskussionsgrundlage erstellt wird. Auch evtl. Vertreter sollten hier benannt sein. Nochwas: der Projektleiter sollte eine faire Chance erhalten, von seinem Glück zu wissen. Vergessen sie ihn also nicht bei der frühen Verteilung dieses Dokuments!
1.2.4 Projektteam
Rolle / Rollen |
Name |
Telefon |
|
Bemerkungen |
Projektleiter |
Name eintragen |
Telefon nicht vergessen! |
z. B. Arbeitszeiten |
|
Teilnehmer 1..n |
Name eintragen |
Telefon nicht vergessen! |
z. B. Arbeitszeiten |
|
Teilnehmer 1..n |
Name eintragen |
Telefon nicht vergessen! |
z. B. Arbeitszeiten |
|
Teilnehmer 1..n |
Name eintragen |
T Telefon nicht vergessen! |
z. B. Arbeitszeiten |
Tipp:
Tragen Sie vorzugsweise das ganze Team hier ein. Hier "genügen" alle, die eine
aktive Rolle im Projekt haben und aktiv und / oder beratend an der Realisierung
teilhaben. Die Telefonnummern helfen enorm, wenn man wirklich mal
Rücksprache mit jemandem halten will, der nicht im Haus sitzt. Die Mailadressen
können, wenn Sie in dieser Tabelle erfasst werden, prima per Copy & Paste
in die Adresszeile einer E-Mail kopiert werden, wenn Sie alle Beteiligten des
Projekts (oder unten die Teilnehmer des Lenkungsausschusses) schnell
informieren wollen.
Ist das Projekt umfangreicher? Dann erstellen Sie Teilteams für Teilprojekte
- schon hier - und definieren Sie die jeweiligen Teilnehmer eines Teilprojekts
separat.
Ab einer gewissen Größe des Projektteams benötigen Sie möglicherweise auch noch weitere Angaben in der Tabelle, um möglichst viele erforderliche Informationen gleich zum Start des Projekts zu besitzen. So sollte z. B. eine Gewichtung (1..100%) in einer separaten Spalte erfasst werden, wenn nicht alle Mitglieder zu gleichen Teilen für das Projekt zur Verfügung stehen.
1.2.5 Lenkungsausschuss
Firma / Abteilung |
Name |
Telefon |
|
Bemerkungen |
Vorsitzender |
Name eintragen |
Telefon nicht vergessen! |
z. B. Arbeitszeiten |
|
Teilnehmer 1..n |
Name eintragen |
Telefon nicht vergessen! |
z. B. Arbeitszeiten |
|
Teilnehmer 1..n |
Name eintragen |
Telefon nicht vergessen! |
z. B. Arbeitszeiten |
|
Teilnehmer 1..n |
Name eintragen |
Tel Telefon nicht vergessen! |
z. B. Arbeitszeiten |
�����������
Wer gehört in den Lenkungssausschuss?
Nein, der Lenkungsausschuss ist nicht das Projektteam J! In diese Tabelle tragen Sie die
Personen ein, die...
- ���� ���� Statusberichte über das Projekt erhalten sollen (oder auch manche, die dies nur wollen, siehe Stakeholder)
- ������ �� an den Meetings zum Projekt teilnehmen sollen und / oder müssen. In den Bemerkungen können Sie jetzt schon hinterlegen, wer als optionaler Teilnehmer zu definieren ist
- ����� ��� als Stakeholder (in jeder Form und Ausprägung) informiert bleiben sollen. Suchen Sie Multiplikatoren, die eine "kaskadierende" Kommunikation nach unten für Sie übernehmen, wenn die Liste allzu groß ist
�- ���� ��� als Leiter oder Schlüsselpersonen in beteiligten Abteilungen tätig sind und daher alle Informationen über das Projekt für ihre Arbeit brauchen. Lassen Sie diese weg, machen Sie es sich und dem Projekt selbst schwer! Soll das fertige Produkt nachher auch verkauft werden? Dann sollte der Vertrieb auch im Boot sitzen - und alle anderen, die ihnen jetzt gerade einfallen.
�- �� ����� für das Budget und Controlling verantwortlich sind. Wer die Musik bezahlt, will auch wissen, wie es um sein Geld bestellt ist
Diese
Liste kann sich durchaus auch im Laufe des Projekts ändern und nicht in jeder
Phase oder jedem Teilprojekt muss diese Liste gleich sein. Sie können diese
Liste anpassen oder nach Erreichen einer neuen Projektphase einfach eine neue
Überschrift über die alte Liste setzen und für Phase xyz eine neue Liste
einfügen. Vorsitzender des Ausschuss muss nicht der Projektleiter sein, kann
oder darf es sogar manchmal nicht. Je nach Projekt sollte auch ein Moderator
extern hinzugezogen oder rotierend oder dauerhaft benannt werden, damit die
Meetings (ob virtuell oder real) Effizient bleiben.
1.3 Reviewvermerke und Meeting-Protokolle
1.3.1 Erstes bis n-tes Review
[Optional:] Wenn Sie mehrere Fassungen dieses Dokuments erstellen und ggf. mit dem Lenkungsausschuss oder anderen Personen besprechen, bevor es zu einem Projektentscheid kommt, sollten Sie in separaten Abschnitten dieses Unterkapitels die Teilnehmer der Reviews benennen und kurz skizzieren (Verweise auf die oder aus der Dokumenthistorie sind denkbar und sinnvoll), was geändert wurde und warum. Benennen Sie Einwände und Änderungsvorschläge und deren Behandlung in Stichworten - spätestens im zweiten Meeting werden Sie sich selbst für das Kurzprotokoll dankbar sein. Vergessen Sie auch das Datum des Meetings nicht!�
Übrigens: Protokolle der Projektmeetings (nicht der Meetings zu diesem Projektauftrag) gehören in separate Dokumente und sollten in einem ordern gesammelt werden, in dem Sie auch diesen Auftrag, alle Reports und sonstigen Unterlagen - und im Idealfall ein Projekttagebuch - ablegen. Protokolle meint in diesem Zusammenhang also nur Informationen, die sich mit der Definition und Entscheidung dieses Projektauftrags befassen!
2 Details Projektauftrag
2.1 Ziele des Projekts
2.1.1 Übersicht Projektziele
- Ziel 1 (Hauptziel
- Ziel 2 (Nebenziel)
- Ziel 2..n (weitere Nebenziele definieren)
Gewichten und Kategorisieren Sie bei größeren oder komplexeren Projekten
nach operativen und strategischen Zielen bzw. verbinden Sie beides und nennen
Sie nicht nur den erwarteten Umsatz und die Grenzwerte für laufende Kosten,
sondern stellen Sie auch dar, wie das Projekt ggf. in einem
"gesamtstrategischen Zusammenhang" steht. Auch hier hilft ggf. eine Tabellenansicht
und vorzugsweise auch gleich eine einfache 123-Priorisierung (machen Sie
es sich in dieser Phase nicht gleich zu schwer), den Überblick zu erhalten.
Vergessen Sie nicht, dass Ziele aus unterschiedlichen Blickwinkeln betrachtet werden müssen, wenn verschiedene Gruppen von Umsetzung, Einführung, Pflege und vor allem der Anwendung des Produkts oder Systems, welches diesem Projekt entsteigen soll, betroffen sind.
Außerdem
immer zu bedenken: Sind Ihre Ziele wirklich die Ihres Kunden?
Meistens nicht. Es ist daher von Fall zu Fall empfehlenswert, hier nicht nur
Ziele, sondern auch den Nutzen zu definieren; wiederum getrennt nach
"ich" und "mein Kunde".
2.1.2 Details zur Zieldefinition
Geben Sie an, was das Ziel des Projekts ist. Je genauer dies geschieht, desto besser können neue und veränderte Anforderungen an das Projekt hinsichtlich der ursprünglich geplanten Zielsetzung beurteilt werden. Sie werden den Auftrag nur dann noch mal zur Hand nehmen, wenn Sie diesen Part ordentlich ausfüllen!
In der Diskussion kann es sich auch als erforderlich erweisen, einen Abschnitt hier einzufügen, der beschreibt, was nicht zum Projekt gehört, um unerfüllbare Erwartungen gleich im Vorfeld zu unterbinden.
2.1.3 Kennzahlen zur Zielerreichung
Sicher ist dies einer der schwierigsten Schritte, dennoch kann er nicht einfach ausgelassen werden, wenn Sie am Ende des Projekts eine Beurteilung darüber abgeben wollen, wie gut das Ziel erreicht ist (bzw. die Teilziele). Für jedes definierte Ziel sollte eine objektive Messgröße (Kennzahlen, die nicht herbeigebetet werden, sondern messbar sind!) existieren. Finden Sie nicht? Dann stellen Sie auch das in der Übersicht der Ziele dar! Es gibt sicherlich auch weiche Ziele, die nicht direkt messbar sind. Seien Sie aber versichert, dass kaum Projekte begonnen werden, die nicht auch konkrete Ziele verfolgen, welche "irgendwie" messbar sind, wenngleich vielleicht - mit dann zu akzeptierender - relativ hoher Ungenauigkeit.
Wessen Ziele haben Sie beschrieben?
Projekte haben selten nur ein Ziel, meistens sind es mindestens zwei oder drei,
unterschiedlichen Gewichts (Hauptziel, Nebenziele - je nach Blickwinkel /
Abteilung auch gern unterschiedlich definiert). Geben Sie auch anderen
Beteiligten in der Diskussion dieses Dokuments die Chance, ihre eigenen
Ziele in den Auftrag einzubringen - so vermeiden Sie Konflikte
zwischen offenen und verdeckten Zielen schon im Vorfeld (zumindest manchmal...).
Tipp: Wenn die Formulierung gezwungenermaßen etwas weiter ausholen muss
oder dieser Abschnitt mit notwendigen Hintergrundinfos ausgestattet werden
soll, verschieben Sie möglichst viel in den Anhang und / oder füllen Sie auf
jeden Fall die eine vollständige stichpunktartige Übersicht der Ziele am
Anfang dieses Abschnitts aus! Nichts ist schlimmer, als Ziele, die in der Masse
übersehen werden oder im Kontext untergehen. Ausführlichkeit ist immer gefragt,
aber es muss auch möglich sein, das Wesentliche durch überfliegen des Dokuments
zu erfassen. Wenn zum Begreifen des Projekts, speziell des Ziels die Lektüre
des ganzen Dokuments erforderlich ist, ist der Projektauftrag Mist, da er
nicht "managementkompatibel" ist! Das betrifft auch einen Projektauftrag,
den "nur Sie und der Kollege" lesen. Betrachtet sich keine von ihnen beiden als
Manager, so geben Sie sich einfach trotzdem nicht mit weniger zufrieden ;)
2.2 Aufgabenstellung
Die Aufgaben, die zum Erreichen der Ziele erforderlich sind, sind je Projekt unterschiedlich und sollten ebenso einmal per Übersicht und dann bei Bedarf in erklärender Prosa zumindest skizziert werden, da sonst auch kein (nicht mal ein grober) Meilensteinplan aufgestellt werden kann.
2.2.1 Rollen und Verantwortlichkeiten
Ob Sie schon hier im Projektauftrag oder erst später beim Anforderungsmanagement eine Übersicht darüber erstellen können oder müssen, wer (im welcher Rolle; oft haben Mitglieder� des Teams mehr als eine Rolle) welchen Beitrag zu welcher Aufgabe leistet, ist wie vieles andere auch abhängig vom jeweiligen Projekt. Im Zweifelsfall ist das Projekt überschaubar und die Anzahl der Teammitglieder so klein, dass Sie tatsächlich auf eine Verteilung verzichten können. Da man aber nie wissen kann, wie sich das Projekt entwickelt, schadet eine IMV- oder RACI-Matrix an dieser Stelle nie. Googeln Sie nach diesen Begriffen, wenn Sie bisher noch nie mit einer Verantwortlichkeitsmatrix gearbeitet haben; das Konzept ist simpel; die Anwendung und Befüllung kostet nur leider mitunter viel Zeit.
Übrigens: Spätestens jetzt werden Sie vielleicht damit anfangen, die Namen der Teammitglieder und oder die Rollenbezeichnungen abzukürzen. Findet der Leser diese irgendwo? Wenn nicht, sollten diese in die Übersicht der Abkürzungen in der Einleitung.
2.3 Rahmenbedingungen, kritische Erfolgsfaktoren und Rollen
Gibt es vielleicht Bedingungen, die nicht als konstant vorausgesetzt werden können und deshalb in eine Risikoanalyse einfließen sollten, die während des Projektverlaufs laufend beobachtet werden sollten? Dies können spezielle Aspekte der Markt- oder Wettbewerbssituation sein; ein technischer Vorsprung, der nicht unendlich lange hält u. Ä.
Kann das Projekt nur dann erfolgreich sein, wenn bestimmte Rahmenbedingungen erst geschaffen werden oder verlässlich dauerhaft garantiert werden müssen? Siehe hierzu auch den folgenden Abschnitt "Ressourcen".
Sind vorbereitende Gespräche mit Partnern erforderlich, die das Projekt noch kippen können?
Können Sie heute schon verschiedene Kennzahlen vorgeben, die das zu schaffende System / Produkt erfüllen soll?
Kann ggf. heute schon die Überlastung einzelner Ressourcen abgesehen werden, da diese bereits in anderen Projekten stecken? Aha: Müssen ggf. die Bedingungen erst bei anderen Projekten eingefordert werden? Schreiben Sie es auf! Wie immer: Liste für Manager, Erklärung für Soldaten hier einfügen!
Dieser Bereich bietet sich auch an, um sich bereits erste Gedanken zur Risikoanalyse zu machen. Welche Faktoren sollten ggf. in einer dauerhaft projekt- begleitenden Analyse berücksichtigt werden?� Sie machen sich mehr Freunde als Feinde, wenn Sie dies ernsthaft schon beim Projektauftrag dokumentieren... Eine einfache Tabelle oder Stickwortlisten reichen aus, machen Sie es erst dann kompliziert, wenn das Projekt gestartet wurde.
2.4 Ressourcen
Müssen Schnittstellen "als Ressource eingebunden werden"? Sprich: Werden Ressourcen aus anderen Abteilungen oder Einheiten benötigt, die weder zum Projektteam gehören, noch über den Lenkungssausschuss bereitgestellt werden können? Hier nennen... und nicht vergessen, diese zu sichern, wenn das Projekt beginnen darf.
Geben Sie an, welche Ressourcen - noch über das Projektteam hinaus - Sie benötigen. Blockiert oder belastet die Implementierung dauerhaft einen Server? Oder andere technische Voraussetzungen?
Wo finden die Meetings statt und wo sitzen Teilnehmer des Projekts, wenn diese temp. Zu einer neuen Einheit zusammengefasst werden und eigentlich verstreut im Unternehmen sitzen?
Werden bestimmte andere allgemeine Arbeitsmittel benötigt und ist dies heute schon absehbar?
2.5 Budget
Wie Sie das ausfüllen, bleibt vollkommen Ihnen überlassen J
Im Ernst: Das Budget muss definiert sein, wenn das Projekt einer Zustimmung bedarf. Es muss definiert sein, wenn Sie ganz allein am Projekt arbeiten. Es muss selbst dann definiert sein, wenn Sie wissen, dass die reine Nennung der Zahlen schon eine Genehmigung unwahrscheinlich macht. Und die Zahl muss so realistisch sein, dass Abweichungen im Nachhinein nicht als "Pfusch" dargestellt werden können.
Nun wissen Sie auch, warum Sie die Ziele und Aufgaben genau definieren sollten: Ändert sich die Gestalt des Projekts während der Umsetzung, dient nur der Projektauftrag noch dazu, Abweichungen bei den Kosten (das machen andere für Sie) zu rechtfertigen, wenn sich auch die Ziele ändern. Denken Sie auch daran, dass mit Kosten nicht nur "Geld" gemeint sein muss, sondern ggf. auch andere Faktoren wie Gewährung von bestimmten Konditionen oder einfach nur Zeit bedeuten kann.
Budgetfindung:
Wie man ein Budget erstellt und durchboxt, füllt ganze Bücher und passt sicher
nicht in diese Anleitung. Aber halten Sie sich an die Regel: Ehrlichkeit
am Anfang eines Projekts zahlt sich immer am Ende aus - und ein guter Puffer,
der nachher im besten fall nicht gebraucht wird, auch ;)
2.5.1 Rentabilitätsbetrachtung
[Optional]: Nicht für jedes Projekt ist eine Berechnung des Zeitpunkts, zu dem der Profit aus dem Projekt die Kosten (endlich) decken wird - und noch oft weniger der darüber hinaus zu erwartenden Gewinne - möglich. Im Rahmen des Budgets ist es aber immer eine gute Idee aufzuzeigen, wann und wie sich der Aufwand bezahlt macht und damit beginnt, neues Geld zu verdienen statt altes auszugeben. Das dient dem "Verkauf" des Projekts, was je nach herrschenden Bedingungen durchaus entscheidend für oder gegen ein "Go" sein kann.
Gelingt dies nicht oder trauen Sie ihren eigenen Angaben nicht, weil sie auf zu wackeligen Füßen stehen, lassen Sie diesen Abschnitt lieber weg - zu schnell wird man an dem gemessen, was hier - oft auf Basis reiner Annahmen - eingetragen wird.
2.6 Übersicht der Meilensteine
Projektstart |
x.x.200x |
Projektentscheid |
x.x.200x |
Vorbereitungsphase |
|
Schritt 1 |
x.x.200x |
Schritt 2..n |
x.x.200x |
Implementierungsphase (ggf. auch oder separate Testphase, je nach Projekt) |
|
Schritt 1 |
x.x.200x |
Schritt 2..n |
x.x.200x |
Einführung |
|
Schritt 1 |
x.x.200x |
Schritt 2..n |
x.x.200x |
Verkaufsstart |
x.x.200x |
Lebensdauer |
|
Schritt 1 |
x.x.200x |
Schritt 2..n |
x.x.200x |
Projektende |
x.x.200x |
Achtung: Wenn es Ihnen nicht gelingt, voraussichtliche Daten für den Projektstart und das Ende anzugeben, haben Sie vielleicht gar kein Projekt - oder das Projekt ist falsch definiert. Glauben Sie es ruhig und fangen Sie bei der Zieldefinition noch mal an; spätestens bei der Aufgabenstellung sollte klar werden, dass alle Schritte endlich sind. Sind sie es nicht, erhalten Sie (als Projektleiter) eine lebenslange und ab einem gewissen Zeitpunkt rein "ehrenamtliche" Aufgabe zum Preis eines Projekts... meistens ein schlechter Deal!
Ein Meilensteinplan ist kein Projektplan, wird aber schnell verbindlich!
Die Tabelle soll nur ein Beispiel geben und ist je nach Projekt sicher
im Detail auch als Übersicht anders aufgebaut. Der grobe Aufbau kann aber aus
dieser Tabelle prinzipiell für alle Projekte abgeleitet werden. Sollten mehrere
Teilprojekte existieren, teilen Sie die Phasen ggf. auf, erstellen Sie
für einen Projektauftrag aber auf jeden Fall eine komplette Übersicht �inkl.
der einzelnen Arbeitspakete (Arbeitsschritte).
Lassen Sie in dieser Phase ruhig die Finger von MS Projekt & Co, sondern
beschränken Sie sich auf gesunden Menschenverstand und diese relativ einfache
Tabelle (im Ernstfall auch Excel, wenn der Plan sonst zu kompliziert zu erstellen
sein sollte). Achten Sie auch hier schon auf Puffer, die der Unsicherheit �der
Planung zu diesem Zeitpunkt Rechnung tragen. Wenn es nicht anders geht,
schreiben Sie lieber "zwischen xx.xx und xx.xx" statt eines konkreten Datums,
wenn Sie sich (jetzt noch) nicht sicher sind, dass die hier genannten Termine
realistisch sind.
2.7 Bemerkungen
Alles, was nicht in den Rest des Dokuments passt, bringen Sie vorzugsweise in einem separaten Block vor dem Projektentscheid unter, damit das Dokument im Zusammenhang lesbar ist.
2.8 Freigabe / Projektentscheid
Das Projekt wurde mit allen Beteiligten hinreichend besprochen. Dieses Dokument beinhaltet in der Fassung <eintragen!>� die geplanten groben Meilensteine, Rahmenbedingungen und verfügbare Ressourcen in der zur Erteilung des Projektauftrags benötigten Genauigkeit. Das Projekt soll wie hier skizziert durchgeführt werden.
Datum: |
|
Unterschrift Auftraggeber: |
|
Unterschrift Projektleiter: |
|
<Weitere Unterschriften>: |
|
3 Anhang / Ressourcen
Dieser Abschnitt findet Verwendung für Literaturverzeichnisse, Hintergrundinfos, Quellennachweise, Verzeichnisse u. Ä.
Hat Ihr Projektauftrag keine solchen Anhänge? Prima. Lassen Sie den Abschnitt trotzdem drin und schreiben Sie "keine". So weiß man auch nachher noch, dass der Abschnitt mit Absicht fehlt und nicht nur vergessen wurde.
Viel Erfolg mit Ihrem Projekt wünscht
Markus
Baersch
Softwareberatung und Lösungen
P.S.: ������ Wenn Sie diese Vorlage hilfreich
bei der Vorbereitung Ihres Projekts fanden, würde ich mich freuen, wenn Sie über einen Link auf
Ihrer Webseite und / oder in Ihrem Blog auf die Quelle dieser Vorlage unter der
Adresse
www.markus-baersch.de/projektmanagement-vorlagen.html
oder auf die Startseite http://www.markus-baersch.de
verweisen würden. J
Vielen Dank!