Markus Baersch

Analytics · Beratung · Lösungen

<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. 2

Inhaltsverzeichnis. 2

1����� Einleitung. 4

1.1������� Allgemeines. 4

1.1.1��������� Zweck und Ziel dieses Dokuments. 4

1.1.2��������� Abkürzungen. 4

1.1.3��������� Ablage, Gültigkeit und Bezüge zu anderen Dokumenten. 4

1.2������� Projektstammdaten. 4

1.2.1��������� Projekttitel / Projektkürzel 4

1.2.2��������� Auftraggeber 4

1.2.3��������� Projektleiter 5

1.2.4��������� Projektteam.. 5

1.2.5��������� Lenkungsausschuss. 5

1.3������� Reviewvermerke und Meeting-Protokolle. 6

1.3.1��������� Erstes bis n-tes Review.. 6

2����� Details Projektauftrag. 7

2.1������� Ziele des Projekts. 7

2.1.1��������� Übersicht Projektziele. 7

2.1.2��������� Details zur Zieldefinition. 7

2.1.3��������� Kennzahlen zur Zielerreichung. 7

2.2������� Aufgabenstellung. 8

2.2.1��������� Rollen und Verantwortlichkeiten. 8

2.3������� Rahmenbedingungen, kritische Erfolgsfaktoren und Rollen. 8

2.4������� Ressourcen. 9

2.5������� Budget 9

2.5.1��������� Rentabilitätsbetrachtung. 9

2.6������� Übersicht der Meilensteine. 10

2.7������� Bemerkungen. 10

2.8������� Freigabe / Projektentscheid. 11

3����� Anhang / Ressourcen. 12

 


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

E-Mail

Bemerkungen

Projektleiter

Name eintragen

Telefon nicht vergessen!

[email protected]

z. B. Arbeitszeiten

Teilnehmer 1..n

Name eintragen

Telefon nicht vergessen!

[email protected]

z. B. Arbeitszeiten

Teilnehmer 1..n

Name eintragen

Telefon nicht vergessen!

[email protected]

z. B. Arbeitszeiten

Teilnehmer 1..n

Name eintragen

T Telefon nicht vergessen!

[email protected]

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

E-Mail

Bemerkungen

Vorsitzender

Name eintragen

Telefon nicht vergessen!

[email protected]

z. B. Arbeitszeiten

Teilnehmer 1..n

Name eintragen

Telefon nicht vergessen!

[email protected]

z. B. Arbeitszeiten

Teilnehmer 1..n

Name eintragen

Telefon nicht vergessen!

[email protected]

z. B. Arbeitszeiten

Teilnehmer 1..n

Name eintragen

Tel Telefon nicht vergessen!

[email protected]

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

http://www.markus-baersch.de

 

 

 

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!

 

 

© 2001 - 2024 Markus Baersch