Was beinhaltet die Projektdefinition?

Bevor ein Projekt „so richtig“ ins Laufen kommt, müssen vorher einige Vorbereitungen getätigt werden und gewisse Voraussetzungen erfüllt sein.

Auf Grund des neuartigen Charakters eines Projekts und der meist doch längeren Dauer von einigen Monaten bis hin zu Jahren ist es nicht möglich, alle Details zu Projektbeginn zu kennen und damit schon beim Projektstart dokumentieren zu können. Allerdings gibt es einige grundlegende Themen, die im ersten Schritt weitgehend abgeklärt und vorhanden sein müssen. Dazu gehören:

• Das Vorliegen eines Projektauftrags samt Zeit- und Kostenrahmen
• Festgehaltene und messbare Projektziele
• Eine zumindest in den Grundzügen festgelegte Projektorganisation
• Der zu erbringende Leistungsumfang
• Die wichtigsten Ansprechpartner und Stakeholder des Projekts

Der Projektmanager hat daher zu Projektbeginn immer abzuschätzen, ob all diese grundlegenden Informationen in einer ausreichenden Menge und Qualität vorhanden sind, sodass er durch seine Unterschrift auf den Projektauftrag auch seine Zustimmung für die Durchführung eines erfolgreichen Projekts geben kann.

Wie wird es im Projekthandbuch definiert?

Das Projekthandbuch (Abk.: PHB) ist das zentrale Arbeitsdokument in einem Projekt. Alle wesentlichen Projektinformationen wie Ziele, Ansprechpartner etc. sind hier enthalten. Es ist dabei grundsätzlich gleichgültig, ob das Projekthandbuch elektronisch in einer Projektverwaltungs-Software integriert ist oder als eigenes Dokument geführt wird.

Es gibt eine Vielzahl von Vorlagen für Projekthandbücher und vermutlich haben die meisten davon den Anspruch „vollständig“ sein zu wollen. Nun ist es an sich schon fraglich, ob diesbezüglich jemals eine Vollständigkeit überhaupt erreicht werden kann – viel wichtiger ist es jedoch zu beachten, dass gerade eine Vorlage für ein Projekthandbuch ein Dokument ist, welches an die spezifische Situation eines Projekts jedes Mal neu angepasst werden muss.

Dies kann größere und kleinere Anpassungen erforderlich machen. In einem kleinen Projekt wird man beispielsweise die ToDo-Listen und die Projektberichte im Projekthandbuch selbst führen – in einem großen Projekt wird man eher die ganze Sektion aus dem Projekthandbuch entfernen und ToDo-Listen und Projektberichte gesondert verwalten und dokumentieren.

Haben Sie auch hier Mut zur Lücke und verwenden Sie nur genau das, was sie auch in einer bestimmten Situation benötigen und nicht mehr. Die Vorlage hat den Charakter einer Checkliste, um möglichst wenige Aspekte, die für ein Projekt wichtig sind, unberücksichtigt zu lassen, d.h. nichts vergessen zu können.

Was ist ein Änderungsverzeichnis?

Die Definition eines Projekts macht bereits deutlich, dass in einem Projekt eine Reihe von Änderungen im Projektverlauf zu erwarten sind. Dies können Änderungen mit groben Auswirkungen wie eine Zieleanpassung oder kleine Änderungen wie ein Wechsel von Ansprechpartnern sein. Änderungen in den Projektinhalten, also z.B. eine Änderung einer Anforderung, fallen hier nicht darunter (diese müssen anderweitig geeignet dokumentiert werden).

Das Projekthandbuch ist somit ein lebendes Dokument. Das heißt, dass es nicht nur zu Beginn eines Projekts erstellt und danach abgelegt wird, sondern laufend am aktuellen Stand gehalten werden muss. Um derartige Änderungen im Projekthandbuch zu dokumentieren, gibt es den Abschnitt „Änderungsverzeichnis“:

Änderungsverzeichnis
Version	Datum	Änderung	Ersteller
0.1	07.03.2019	Erstentwurf	Name
0.2	21.03.2019	Einarbeitung Änderungen seitens Auftraggeber	Name
1.0	01.04.2019	Erster Version zur Verteilung	Name
1.1	27.05.2019	Finalisierung zur Einreichung	Name

Das Änderungsverzeichnis hat typisch folgende Spalten:

Version:
hier wird eine fortlaufende Versionsnummer eingetragen. Es ist üblich, die erste „fertige“ Version mit 1.0 zu bezeichnen. Vorversionen können entsprechend z.B. mit 0.1, 0.2 oder 0.91 bezeichnet werden. Bei kleineren Änderungen erhöht man üblicherweise die Zahl hinter dem Komma (also z.B. von 1.0 auf 1.1), bei größeren Änderungen erhöht man üblicherweise die Zahl vor dem Komma (also z.B. von 2.3 auf 3.0).

Datum:
hier wird das Datum der fertiggestellten Änderung eingetragen.

Änderung:
hier wird ein aussagekräftiger Grund für die Änderung eingetragen.

Ersteller:
hier wird der Name oder ein vereinbartes Kurzzeichen jener Person, welche die Änderung vorgenommen hat, eingetragen.

Wer ist Ansprechpartner und Stakeholder?

In einem Projekt arbeiten typisch 5…50 Personen, die in irgendeiner Form in das Projekt involviert sind – bei großen Projekten können es auch einige hundert Personen sein. Um nun die wesentlichen Personen sowohl zu kennen als auch erreichen zu können, gibt es die Liste mit Ansprechpartnern:

Die Liste der Ansprechpartner hat typisch folgende Spalten:

Name:
hier wird der Name des Ansprechpartners eingetragen.

Organisations-Einheit:
hier wird die Organisationseinheit eingetragen. Dies kann sein ein Unternehmensname (wenn Personen aus verschiedenen Unternehmen im Projekt arbeiten) und/oder eine Abteilungsbezeichnung

Rolle:
hier wird die Rolle der Person im Projekt eingetragen, beispielsweise „Projektleiter“, „IT-Ansprechpartner Kunde“ oder „Projektoffice“

Telefon:
hier werden eine oder mehrere Telefonnummern angeführt, unter denen die Person am besten zu erreichen ist

E-Mail:
hier wird die E-Mail-Adresse der Person eingetragen, welche im Projekt verwendet wird (also normalerweise z.B. nicht die private E-Mail-Adresse)

Diese Liste der Ansprechpartner hat rudimentären Charakter und kann und soll nach Bedarf erweitert werden. Je nach Projekt machen z.B. folgenden Spalten zusätzlich Sinn:

• Kurzname, z.B. „RSCH“ für Richard Schneider
• Stellvertretung, z.B. bei Urlaub oder Nichterreichbarkeit in dringenden Fällen
• Position im Unternehmen (getrennt von der Rolle im Projekt)

und dergleichen mehr. Ebenso können in die Liste der Ansprechpartner beispielsweise Gruppen-Mail-Adressen eingetragen werden, unter denen bestimmte Personenkreise sachbezogen angeschrieben werden können (z.B. „entwicklung@projekt_xy.com“ oder „projekt_office@projekt_z.com“). Ferner lässt sich diese Liste verwenden oder adaptieren, um (Post-)Adressen von Ansprechpartnern oder Örtlichkeiten zu verwalten.

Jetzt gilt es noch festzulegen, wer denn als „wesentliche Person“ gilt und daher in die Liste der Ansprechpartner aufgenommen werden soll. Zunächst nicht zu verwechseln mit den Ansprechpartnern sind die Stakeholder, also all jene Personen, die einen Einfluss auf das Projekt und/oder ein Interesse am Projekt haben).

Auch wenn meist einige der beteiligten Personen gleichzeitig Stakeholder und Ansprechpartner sein werden, sollten diese dennoch getrennt behandelt werden, da die Rolle „Stakeholder“ und die Rollen als „Ansprechpartner“ unterschiedliche Auswirkungen auf das Projekt haben. Als Ansprechpartner sind jene Personen aufzunehmen, die im ständigen Projektverlauf „gebraucht“ werden und involviert sind, also typisch das gesamte Projektteam im weitesten Sinne. 

In die Stakeholderliste kommen hingegen jene Personen, die Interessen am Projekt haben (also beispielsweise laufend oder gelegentlich informiert werden müssen), die Einfluss auf das Projekt haben (also z.B. in der Umfeldanalyse berücksichtigt werden müssen) oder die punktuell in das Projektgeschehen mit einbezogen werden sollen (z.B. bestimmte Benutzer zwecks Erhebung von Anforderungen).

Wenn die Anzahl von Personen in beiden Listen überschaubar klein ist oder sich mehrere Personen gleichzeitig sowohl in der Liste der Ansprechpartner als auch in der Liste der Stakeholder wiederfinden, macht es auch Sinn, die beiden Listen zusammenzuführen (und die Personen beispielsweise mit zusätzlichen Spalten als „Ansprechpartner“ und/oder „Stakeholder“ zu kennzeichnen). 

Grund für eine Zusammenführung kann auch sein, dass ansonsten die Gefahr von Inkonsistenzen entsteht, wenn sich Personendaten ändern und diese Änderungen nur an einer Stelle eingetragen werden.

Was ist der Projektauftrag?

Der Projektauftrag ist – neben den Zielen – einer der wichtigsten Inhalte des Projekthandbuchs, da hier die wesentlichen Eckpunkte des Projekts zwischen dem Projektauftraggeber und dem Projektleiter definiert werden. Er beinhaltet typisch zumindest die folgenden Punkte:

Projektstartereignis
Hier wird eingetragen, was dazu geführt hat, dass das Projekt tatsächlich gestartet wurde. Das kann beispielsweise das positive und freigegebene Ergebnis einer Vorstudie, eine externe Beauftragung oder eine Gesetzesänderung sein.

Projektdauer
Hier sind das Startdatum des Projekts sowie das geplante Ende des Projekts einzutragen.

Als Startdatum wird typisch jenes Datum eingetragen, an welchem sich das Projektstartereignis zugetragen hat. Bei Projekten kann auf Grund von Risiken und Unsicherheiten konsequenterweise nur ein geplantes Ende-Datum eingetragen werden. Gibt es Rahmenbedingungen für das Ende-Datum (wie beispielsweise eine schon angekündigte, feierliche Eröffnung eines neuen Gebäudes zu einem bestimmten Termin) ist dies entsprechend zu vermerken.

Projektendereignis
Hier wird eingetragen was dazu führt, dass das Projekt formal beendet ist. Dies wird in vielen Fällen eine erfolgreiche Abnahme einer Lieferung sein, kann aber auch aus der Fertigstellung und Freigabe einer Vorstudie resultieren. Wichtig ist eine möglichst genaue Definition, damit ein Projekt auch ein definiertes Ende finden kann.

Projektbudget
Das zur Verfügung stehende Projektbudget wird üblicherweise als Geldwert angegeben, kann aber auch z.B. bei bekannten internen Stundensätzen in Zeiteinheiten vereinbart werden. Oft ist das Projektbudget gleich dem Gesamtpreis eines vorangegangenen Angebots.

Projektphasen
Wenn in einem Projekt einzelne Phasen vorgesehen sind, so können diese hier grob skizziert werden. Ebenso ist beispielsweise ein Verweis auf ein anderes Dokument wie ein Lastenheft möglich (siehe dazu auch PM-104).

Projektklasse
Da Projekte unterschiedliche Größenordnungen haben, macht es Sinn, diese in Klassen aufzuteilen. Meist genügen dafür 3 Klassen, die beispielsweise mit „A“ (sehr komplexes Projekt, neuartig, risikoreich, umfangreich) über „B“ (mittlere Komplexität, geringe Neuartigkeit, gewisses Risiko) bis „C“ (geringes Risiko, geringer Umfang) bezeichnet werden können. Was genau für ein Unternehmen komplex, neuartig oder risikoreich bedeutet muss zuvor vereinbart und definiert werden.

Die Klassifizierung und die Benennung der Klassen sind somit situationsspezifisch. Insbesondere die Klassifizierung kann nach einer Vielzahl von Kriterien erfolgen, die sein können

• Projektbudget im Vergleich zum Unternehmens-Jahresumsatz
• Dauer und Neuartigkeit des Projekts
• Risiken und Chancen im Projekt
• Komplexität, z.B. auf Grund der Anzahl von Stakeholdern

und dergleichen mehr. Generell gilt auch hier, dass die Kriterien für eine Bewertung in einem überschaubaren Rahmen bleiben sollen.

Wozu überhaupt eine Klassifizierung benötigt wird? Hauptsächlich deshalb, um den Umfang des Projektmanagements festlegen zu können. Sehr komplexe und risikoreiche Projekte benötigen mehr Aufmerksamkeit und Konzentration als kleine, kurze und überschaubare Projekte (vergleiche z.B. Tabelle 2). 

Es macht daher Sinn, denn Aufwand für das Projektmanagement anhand der Komplexität festzulegen. Beispielsweise kann daraus resultieren, ob ein aktives Risikomanagement verpflichtend oder nur empfohlen durchgeführt werden soll oder ob ein Standard-Strukturplan verwendet werden kann oder ein spezifischer Strukturplan erstellt werden muss.

Projektart
Unter der Projektart wird festgelegt, ob es sich um ein internes Projekt, um ein externes Kundenprojekt, um eine Vorstudie usw. handelt. Diese Information unterstützt die Projektteam-Mitglieder in der Einschätzung, worum es in diesem Projekt grob geht.

Anmerkungen, Sonstiges
Hier können zusätzliche Anmerkungen und Kommentare angeführt werden, die als grobe Information für den Projektauftrag wichtig sind. Alle Informationen, die in anderen Abschnitten des Projekthandbuchs eingeordnet werden können (beispielsweise Rahmenbedingungen), sollen auch dort vermerkt werden und nicht unter den Anmerkungen.

Unterschriften
Ein Projektauftrag macht nur dann Sinn, wenn dieser von beiden Seiten – also vom Projektauftraggeber und vom Projektleiter – unterschrieben werden. Eine Unterschrift stellt ein klarer Kommittent zu einer Vereinbarung da – es hat die Bedeutung „zu diesen Rahmenbedingungen haben wir beide ja gesagt“.

Ohne beidseitige Unterschriften ist der Projektauftrag nichts wert, da damit keine nachvollziehbare Bestätigung einer Vereinbarung vorliegt. 

Da das Projekthandbuch meistens elektronisch geführt und gepflegt wird, stellt sich die Frage, wie hier mit Unterschriften umgegangen werden soll. Es gibt beispielsweise die Möglichkeit, dass die Seite mit dem Projektauftrag ausgedruckt, unterschrieben, eingescannt und gesondert als Projektauftrag abgelegt wird. Eine andere Möglichkeit ist, dass durch Versionskontrollsysteme oder durch Workflowsysteme eine Nachvollziehbarkeit der Bestätigung des Auftrags gegeben ist.

Ergänzungen
Wie bei allen anderen Vorlagen macht es auch hier Sinn, den Projektauftrag spezifisch für eine Situation zu ergänzen. Typische, zusätzliche Felder könnten sein

• Besondere Risiken und Chancen im Projekt
• Besonderheiten bei Ressourcen personeller oder maschineller Form
• Spezielle Hinweise auf Lieferanten im Projekt
• Hinweise auf zugehörige Unterlagen wie Auftragskalkulation oder Verträge zum Projekt
• Hervorzuhebende Meilensteine im Projekt

und dergleichen mehr.

Was sind Projektziele?

Ohne klare Ziele kein Projekt! Wie soll das Projektteam sonst wissen, wozu das Projekt eigentlich gut ist und zu welchem Zweck sie ihre Arbeitsleistung einbringen? Wie soll am Ende festgestellt werden, ob das, was mit dem Projekt bezweckt wurde, auch erreicht ist?

Gleichzeitig ist es oft ungemein schwierig, verbindliche Ziele zu definieren. Das liegt einerseits daran, dass die meisten Beteiligten in einer guten Zielformulierung nicht geübt sind, andererseits klare Ziele auch Auftraggeber und Auftragnehmer an konkrete Ergebnisse binden und damit transparent werden.

Projektziele“ im Projekthandbuch“ class=“wp-image-205931″/>

Welche Kategorien gibt es?

Wie aus dem Projekthandbuch ersichtlich ist, gibt es drei Kategorien von Zielen: Hauptziele, Nebenziele und Nicht-Ziele.

Hauptziele sollen mindestens 2, maximal 5 definiert werden. Zu wenige Hauptziele bringen die Gefahr mit sich, dass die Zielsetzung verwässert wird, zu viele Hauptziele sind auf Dauer nicht im Gedächtnis abzuspeichern.

An Nebenzielen können grundsätzlich beliebig viele Ziele definiert werden, allerdings soll natürlich auch hier die Anzahl auf ein vernünftiges, merkbares und überschaubares Maß beschränkt werden. Wichtig ist auch, dass die Nebenziele nicht mit Hauptzielen im Widerspruch stehen, sondern diese ergänzen.

Wenn es notwendig und wichtig ist – besser gesagt der Verständlichkeit und Abgrenzung dienlich ist – können und sollen auch Nicht-Ziele definiert werden. Diese können die Haupt- und Nebenziele konkret einschränken und damit auch unterstützen, den Projektumfang genauer abzugrenzen. Auch hier soll die Anzahl an Nicht-Zielen beschränkt und überschaubar bleiben.

Welche Regeln für Zieldefinition gibt es?

Ziele sollen nach der SMART-Regel definiert werden. SMART ist die Abkürzung für

Specific Measurable Accepted Realistic Timely

(Spezifisch Messbar Akzeptiert Realistisch Terminierbar)

Dies ist eine der gebräuchlichen Interpretationen von SMART, gelegentlich finden sich auch andere alternative Auflösungen:

SMART bedeutet:

S	Spezifisch Ziele müssen eindeutig definiert sein (nicht vage, sondern so präzise wie möglich).
M	Messbar Ziele müssen messbar sein (Messbarkeitskriterien).
A	Akzeptiert/Angemessen Ziele müssen von den Empfängern akzeptiert werden/sein. Ziele müssen auch der Situation entsprechend angemessen sein.
R	Realistisch Ziele müssen erreichbar sein.
T	Terminierbar Zu jedem Ziel gehört eine klare Terminvorgabe, bis wann das Ziel erreicht sein muss.

Nur bei konsequenter Anwendung der SMART-Regel ergeben sich klare und vor allem mess- und überprüfbare Ziele. Ist ein Ziel beispielsweise nicht messbar formuliert, ist es in sich unbrauchbar, da nicht überprüft werden kann, ob das Ziel erreicht wurde oder nicht und somit auch nicht überprüft werden kann, ob ein Projekt beendet werden kann bzw. erfolgreich ist.

Bei der Kommunikation und Festlegung von Zielen hilft folgende Checkliste (16), um sicherzustellen, dass alle Beteiligten auf die gleiche Weise verstehen, worum es geht:

1. Information über den Zweck des Projekts (d.h. die Ziele höherer Ordnung, Hauptziele – warum wird das Projekt überhaupt in Angriff genommen)
2. Information über die Zielsetzung des Projekts (z.B. durch Vermittlung eines Bildes des angestrebten Resultats – wie sieht das Bild eines erfolgreichen Abschlusses des Projekts aus)
3. Information über die Schritte, die gemäß der Planung ausgeführt werden müssen (was haben sich die Auftraggeber grob bei dem Projekt gedacht, welche Abhängigkeiten gibt es)
4. Information über die Gründe des Projekts (wie bzw. aus welchen Überlegungen heraus ist das Projekt entstanden)
5. Information über die Schlüsselentscheidungen, mit denen sich die Beteiligten auseinander setzen müssen (Berücksichtigung von Eventualitäten und möglichen Schwächen bzw. Risiken)
6. Information über Nicht-Ziele (d.h. unerwünschte Resultate – welche sinnvollen Alternativen kann es geben)
7. Information über Einschränkung von Handlungsmöglichkeiten und andere zu berücksichtigende Faktoren (welche Besonderheiten könnte es geben, …)

Nicht immer sind alle Arten von Informationen notwendig; die Checkliste hilft dabei festzustellen, welche Informationen und welche Details mitgeteilt werden müssen. 

Was ist die Vor- und Nachprojektphase?

Gelegentlich ist es hilfreich darzustellen, wie es zu einem Projekt gekommen ist und wo eventuell ergänzende Unterlagen zu einer Vorprojektphase zu finden sind. Diese Information kann beispielsweise dazu beitragen, bereits einmal angedachte Wege nicht mehr neu überlegen zu müssen, sondern auf die entsprechende Dokumentation zurückgreifen zu können. Ebenso können Hinweise auf Erfahrungen aus ähnlichen Projekten zusätzlichen Nutzen bringen.

In gleicher Weise kann es wichtig sein, die aus dem aktuellen Projekt resultierenden Folgeprojekte (Nachprojektphase) kurz zu umschreiben. Diese Information ermöglicht es, künftige Vorhaben bereits während des aktuellen Projekts im Blickwinkel zu behalten und Entscheidungen und Konzepte darauf auszurichten.

Was ist die Projektumfeldanalyse?

Gelegentlich auch als Projektumweltanalyse bezeichnet wird hier bewusst der Ausdruck „Umfeld“ verwendet, um allfällige Missverständnisse mit dem Begriff „Umwelt“ zu vermeiden.

Die Projektumfeldanalyse liefert Information dazu, wo im Umfeld des Projekts Konflikte entstehen könnten (also wo Risiken vorhanden sind, welche den Projektverlauf negativ beeinflussen können) oder wo Potentiale vermutet werden (also wo Chancen vorhanden sind, welche den Projektverlauf positiv beeinflussen können). 

Die Projektumfeldanalyse steht damit auch in engem Zusammenhang mit der Risikoanalyse. Wichtig ist die Umfeldanalyse deshalb, weil ein frühzeitiges Erkennen von Einfluss- und Störgrößen den Handlungsspielraum zur Nutzung effizienter und kostengünstiger Varianten sichert, um diesen Einfluss- und Störgrößen begegnen zu können.

Sowohl potentiellen Risiken als auch Chancen werden Maßnahmen, eine verantwortliche Person und ein Zieldatum zugeordnet. Unter Maßnahmen wird eingetragen, wie mit einem Umfeld bestmöglich umgegangen wird. Die verantwortliche Person ist – wie immer im Kontext von Projekten – jene, die zwar nicht unbedingt die Maßnahme selbst durchführen muss, aber eben dafür verantwortlich ist, dass die Maßnahme bis zum Zieldatum erledigt wird.

Gespeist wird die Umfeldanalyse zum Teil aus der Stakeholderliste – dort sind ja all jene Personen eingetragen, welche Einfluss auf das Projekt und Interesse am Projekt haben. Zusätzlich können nun auch reale und virtuelle Umfelder wie Mitbewerb, die Öffentlichkeit oder Medien hinzukommen.

Das folgende, in der Projektumfeldanalyse enthaltene, Bild gibt einige zusätzliche Ideen, wo Potentiale und Konflikte im Umfeld typisch entstehen können. Es macht auch durchaus Sinn, zur Visualisierung selbst eine Grafik des spezifischen Umfelds zu erstellen und darzustellen.

Projektumfeldanalyse“ aus dem Projekthandbuch“ class=“wp-image-205934″/>

An dieser Stelle sei wieder erwähnt, dass die Umfeldanalyse ein typisches Beispiel dafür ist, dass das Projekthandbuch insgesamt ein lebendes Dokument ist. Meist wird man im ersten Ansatz viele potentielle Konflikte und Potentiale kennen, ebenso werden sich im Verlauf des Projekts zusätzliche Umfelder ergeben oder ursprünglich angenommene Umfelder wegfallen – dies ist auch der Grund, warum es sich beim Projektmanagement um ein Management-Thema handelt – nämlich um die kontinuierliche Steuerung, Überprüfung, Verfolgung und Adjustierung von Annahmen, Planungen, Maßnahmen und neuen Situationen.

Was sind Beziehungen zu anderen Projekten?

Meist ist es so, dass Projekte nicht genau dann starten, wenn die – vorgehaltenen oder vorhandenen – Ressourcen gerade für eine neue Aufgabe frei geworden sind. Im Gegenteil – in Unternehmen, wo mehrere Projekte gleichzeitig abgewickelt werden (Stichwort Multiprojektmanagement), kommt es zu Konflikten um Ressourcen zwischen den Projekten.

Im Gegenzug können sich durch ein neues Projekt auch Synergien ergeben. Hierzu ist es hilfreich, die Beziehungen bzw. Beeinflussungen zwischen Projekten aufzulisten, um beispielsweise der Managementebene Entscheidungsgrundlagen für Priorisierungen oder sonstige Maßnahmen aufzubereiten.

Auch dieser Bereich des Projekthandbuchs bedarf während der Projektabwicklung einer laufenden Kontrolle, ob sich die Beziehungen verändert haben sowie ob die geplanten Maßnahmen durchgeführt wurden, diese zum gewünschten Ziel geführt haben oder adaptiert werden müssen.

Was bedeutet der Zusammenhang zu Unternehmenszielen?

Hat das Projekt einen Zusammenhang zu den Unternehmenszielen bzw. einen Einfluss auf die Unternehmensziele? Oder ist es „nur“ ein „normales“ Projekt für das Unternehmen? 

Beispielsweise könnte ein Projekt neue Entwicklungen beinhalten, die in Folge als strategisch wichtige Produkte platziert werden sollen. Diese Information ist somit hilfreich, um sonst nicht offensichtliche Zusammenhänge und Hintergründe darzustellen.

Wenn es in einem – meist kleineren – Projekt keinen Zusammenhang zu Unternehmenszielen gibt, so lassen Sie diesen Bereich einfach weg. Noch besser ist es, eine Zeile wie etwa „derzeit keine Zusammenhänge“ einzutragen, dann ist nämlich 1. festgehalten, dass Sie sich zumindest dazu Gedanken gemacht haben und 2. die Möglichkeit weiterhin gegeben, zu einem späteren Zeitpunkt einen Eintrag zu ergänzen anstelle den ganzen Abschnitt neu einzufügen.

Was ist die Projektorganisation?

In der Projektorganisation werden alle im Projekt unmittelbar beteiligten Rollen mit Name und Aufgabenbereich festgehalten. Die hier eingetragenen Personen müssen sich auch in der Liste der Ansprechpartner wiederfinden – alternativ werden die beiden Listen zu einer zusammengefasst.

Wenn es Sinn macht, können die wichtigsten Projektteammitglieder auch grafisch dargestellt werden, um beispielsweise die Zusammengehörigkeit bestimmter Bereiche zu betonen:

Was ist der Projektergebnisplan?

Vor allem für größere Projekte macht es Sinn, die zu liefernden Ergebnisse grob darzustellen, z.B. als Mindmap. Damit ist für das gesamte Projektteam eine gute Übersicht gegeben, wie sich die einzelnen Teile zusammensetzen und wie „das große Ganze“ (Big Picture) aussieht. Bei kleinen Projekten mit wenigen Lieferobjekten können die Ergebnisse meist direkt aus dem Projektstrukturplan entnommen werden.

Projektergebnisplan“ im Projekthandbuch“ class=“wp-image-205945″/>

Ein Projektergebnisplan macht an dieser Stelle auch dann Sinn, wenn für das Kick-Off-Meeting der Projektstrukturplan noch nicht vorliegt und/oder der Projektstrukturplan in Folge aus dem Projektergebnisplan heraus entwickelt wird.

Was bedeutet Projektkontext?

Der Projektkontext grenzt ihr Projekt, also den zu erbringenden Leistungsumfang, vom Umfeld ab. Gerade an Schnittstellen nach außen ist oft nicht immer eindeutig, wer welche Leistung zu erbringen hat. Dies wird mit dem Projektkontext festgelegt.

Der Projektkontext liefert außerdem zusätzliche Informationen über

• Mögliche Stakeholder
• Zu bedienende Schnittstellen, z.B. technischer oder organisatorischer Art
• Informationen zum Umfeld

Es gibt mehrere Arten, Kontextdiagramme zu zeichnen. Wichtig ist, dass innerhalb der Projektgrenzen alles vorhanden ist, was Lieferumfang ist und außerhalb all jenes dargestellt wird, was mit dem Lieferumfang in irgendeiner Weise interagiert, aber selbst nicht Lieferumfang ist:

In diesem Beispiel ist der Lieferumfang für das Projekt „Modul Projektmanagement für PM-Lehrgang, Kurseinheit 101“ durch die Teile Skriptum, Audiobook, Lernkontrollfragen und Klausurfragen definiert. Das Audiobook hat eine Abhängigkeit zum Skriptum, da es ja die Inhalte in audibler Form wiedergibt. Ähnlich beziehen sich die Lernkontrollfragen auf den Inhalt des Skriptums und die Klausurfragen stehen mit den Lernkontrollfragen in enger Verbindung.

Wichtiger für den Kontext sind jedoch die Schnittstellen nach außen. Der Inhalt des Skriptums steht mit den externen Komponenten „Modul QM“ und „Modul BPM“ in Verbindung – konkret ist hier eine Abstimmung der Inhalte mit den externen, d.h. nicht im Lieferumfang „Modul PM für UB KE1“ enthaltenen, Modulen durchzuführen, sodass nicht gleiche Inhalte mehrfach behandelt werden.

Die Klausurfragen werden über eine Online-Plattform gestellt und bewertet, woraus sich ebenfalls eine Schnittstelle ergibt – im konkreten Fall muss die Form der Klausurfragen technisch zur Online-Plattform passen.

Auf einen Blick ist hier erkenntlich

• mit welchen nicht im Projektlieferumfang befindlichen Komponenten – gleichgültig ob bereits vorhanden oder auch noch in einer Umsetzungsphase – interagiert wird, 
• was der eigene Lieferumfang ist 
• und vor allem: was er nicht ist.

Was sind Rahmenbedingungen?

Rahmenbedingungen (engl. constraints) sind mögliche oder faktische Einschränkungen oder Beschränkungen für mögliche Lösungen. Es empfiehlt sich, all jene Restriktionen zu dokumentieren, welche Design, Erstellung, Test, Abnahme und Einführung des Leistungsumfangs betreffen. 

Rahmenbedingungen beschreiben Aspekte des Ist- oder des Soll-Zustands, die nicht verändert werden dürfen. Es handelt sich dabei nicht um klassische Anforderungen an die Funktionalität, weil sie nicht direkt vom Projektteam umgesetzt werden. 

Was beinhaltet die Projektkommunikation?

Der Abschnitt „Kommunikationsstrukturen“ legt fest, wer mit wem worüber wie oft spricht. Insbesondere wird hier festgelegt, wie oft sich der Projektleiter mit dem Projektteam zwecks Statusabgleich trifft und wie oft der Projektleiter dem Projektauftraggeber über den Fortschritt und mögliche Schwierigkeiten berichtet.

Gerade bei größeren Projekten kann es zusätzlich notwendig sein, dass sich Sub-Teams mit Teilprojektleitern regelmäßig abstimmen. Wenn es eine gesonderte Qualitätskontrolle im Projekt gibt, ist zu überlegen, ob dies im Rahmen der Projektcontrolling-Sitzungen oder in einem gesonderten Meeting stattfinden soll. 

Bei Projekten mit besonderer Wichtigkeit für die Trägerorganisation sind zusätzlich oft eigene interne Lenkungsausschüsse etabliert, die Entscheidungen über das gesamte Projektportfolio zu treffen haben.

Welche Spielregeln gibt es?

Es empfiehlt sich, für den Projektablauf einige Spielregeln festzulegen. Dies betrifft

• Die Form von Sitzungen
• Den Umgang mit Sitzungen bezüglich Agenden und Protokollen
• Die Form der Kommunikation innerhalb des Projektteams

und dergleichen mehr. Ergänzend kann hier u.a. festgelegt werden, wie das Berichtswesen erfolgen soll, also wie oft an wen was berichtet wird – beispielsweise wer die Projektfortschrittsberichte zusätzlich zum Team zur Information erhält.

Auch die Spielregeln sind – wie fast alle Themen des Projekthandbuchs – eine dynamische Angelegenheit: sie stehen nicht für alle Zeiten in Stein gemeißelt. Es ist jedoch wichtig, bereits erste Spielregeln beim Kick-Off-Meeting mit dem Projektteam vorbereitet zu haben und diese eventuell in einer dort stattfindenden Diskussion zu adaptieren. Wenn Sie z.B. erst im Kick-Off-Meeting die Frage stellen „Welche Regeln wollen wir aufstellen?“ wird das viel mehr Zeit kosten, als wenn vernünftige Grundregeln schon vorhanden sind.

Was beinhaltet die Projektdokumentation?

Der Abschnitt Projektdokumentation legt fest

• Wo Dokumente abgelegt werden
• Wann (in welchem Fertigstellungsgrad befindliche) Dokumente abgelegt werden
• Wer auf welche Dokumente wie Zugriff hat
• Wie Dokumente einheitlich bezeichnet werden
• Wie das Projektteam über neue Dokumente informiert wird

Es empfiehlt sich, Dokumente – bei elektronischer Ablage die das Dokument enthaltene Datei – immer aussagekräftig und eindeutig zu benennen. Vorzugsweise ist am Dokumenten- bzw. Dateinamen sofort zu erkennen, zu welchem Projekt ein Dokument gehört und was es zumindest ungefähr beinhaltet.

Bei komplexeren Projekten ist es zusätzlich sinnvoll, eine Ablagestruktur für Dokumente vorzugeben. Diese wird sich beispielsweise in einer hierarchischen und benannten Ordnerstruktur niederschlagen. 

Projektdokumentation“ im Projekthandbuch“ class=“wp-image-205953″/>

Was ist die Risikoanalyse?

Bereits in der Phase der Projektdefinition ist eine erste Risikoanalyse für das Projekt anzulegen. Idealerweise gibt es bereits dazu Informationen aus der Vorprojektphase, beispielsweise aus den Überlegungen im Zuge einer Angebotserstellung.

Die Risikoanalyse wird zusätzlich aus folgenden Quellen gespeist:

• Aus „Standardrisiken“ wie Wettereinflüsse, möglichen Ressourcenengpässen, Währungsrisiken und dergleichen
• Aus der Liste der Stakeholder – wer hat welchen Einfluss auf das Projekt
• Aus der Umfeldanalyse – welche äußeren Einflüsse wirken auf das Projekt
• Aus Informationen des Projektteams – gibt es Erfahrungen mit dem aktuellen Kunden oder mit ähnlichen Kunden, welche Ansätze kommen vom Projektsponsor aus Gesprächen mit dem Auftraggeber

und dergleichen mehr.

Risiken sind dabei nicht „aus dem Bauch heraus“ zu bewerten, sondern können meist gut quantitativ eingeschätzt werden. Die übliche Methode dazu ist, eine sogenannte Risikokennzahl zu errechnen, die sich aus dem Produkt der Wahrscheinlichkeit des Eintritts des Risikos und der Auswirkung auf das Projekt ergibt. 

RKZ (Risikokennzahl) = A (Auswirkung) mal W (Wahrscheinlichkeit)

Damit dies rechnerisch möglich wird, müssen diese beiden Faktoren zuvor quantifiziert werden, beispielsweise wie folgt:

Wenn es Sinn macht, kann die Auswirkung auch auf mehrere Kategorien aufgeteilt werden, die dann für die Auswirkung addiert werden. Beispielsweise kann die Auswirkung des Eintritts eines Risikos sowohl Kosten (A_K – Auswirkung auf Kosten), Zeitverzug (A_Z – Auswirkung auf Zeit), aber auch Qualitätseinbußen (A_Q – Auswirkung auf Qualität) mit sich bringen. Die Risikokennzahl pro Risiko würde sich dann zu

RKZ = W ⋅ (A_K + A_Z + A_Q) = W ⋅ Σ( A )

errechnen.

Eine Toolunterstützung erleichtert den Umgang mit Risiken (und darauf folgenden Maßnahmen) – dafür genügt im einfachsten Fall eine Tabellenkalkulation, die wie folgt aussehen kann:

Nachteilig an gesonderten Tools ist wie immer, dass es zwischen gleichen Informationen an verschiedenen Speicherorten keine Verbindung gibt und damit einerseits der Pflegeaufwand steigt sowie andererseits die Gefahr von Inkonsistenzen besteht.

Bei einer Risikoanalyse und -bewertung handelt es sich um Schätzungen, um einen Blick in die Zukunft. Aus diesem Grund macht es Sinn, die Bewertung der Wahrscheinlichkeiten und der Auswirkungen im Team zu diskutieren. Es empfiehlt sich daher, auch die erste Risikoanalyse bereits in der Phase der Projektdefinition zu erstellen und – wenn Zeit und Rahmen dafür geeignet sind – diese beim Kick-Off-Meeting vorzustellen, zu ergänzen und zu diskutieren. Nebeneffekte sind, dass wahrscheinlich zusätzliche Risiken erkannt und identifiziert werden können, eine gemeinsame Beurteilung erfolgt ist und die Risiken dem Projektteam bereits grob bekannt sind.

Weitere Ausführungen zu diesem Thema siehe Risikomanagement.