1.2 Definition des Projekts / Techniken

Beziehung zwischen Projektdefinition und Projektplan (1.2.P1)

Das Definieren der Arbeit und das Erstellen des Projektplans erfolgt nicht notwendigerweise eins nach dem anderen. Das heißt, Sie müssen nicht zuerst die anliegende Arbeit vollständig definieren und dann in einem zweiten Schritt den Projektplan erstellen. Beachten Sie, dass manche Teile der Projektdefinition nicht beendet werden können, ohne dass man mit dem Entwurf des Projektplans beginnt. Gleichzeitig gilt, dass Sie den Projektplan nicht beenden können, ohne eine Einigung hinsichtlich der Projektdefinition zu erzielen. Sie können beispielsweise keinen Projektplan erstellen, ohne eine allgemeine Einigung über die Lieferobjekte und den Projekt-Umfang zu erzielen. Zur Definition des Projekts gehört auch eine Beschreibung des allgemeinen Ansatzes, nach dem das Projekt durchgeführt wird. Es ist hilfreich, diesen Ansatz vor der Beendigung des Projektplans zu kennen.

Bis zu einem gewissen Grad müssen die Definition der Arbeit und das Erstellen des Projektplans simultan erfolgen. Auch die beiden Hauptlieferobjekte, die Projektdefinition und der Projektplan, sollten parallel entwickelt werden. Sie werden feststellen, dass Sie in dem Maße, wie Sie Informationen über den Projektinhalt und -umfang und die Lieferobjekte zusammentragen, mit dem Entwurf eines groben Projektplans beginnen können. Je weiter Sie mit der Informationssammlung voranschreiten, desto mehr Details können Sie dem Projektplan hinzufügen. Wenn die Lieferobjekte, der Projektumfang, die Annahmen und die Vorgehensweise vollständig vorliegen, sollten Sie über genügend Informationen verfügen, um einen groben Projektplan fertig zu stellen. Dann können Sie den Projektplan dazu verwenden, das benötigte Budget, den notwendigen Arbeitsaufwand und die Dauer zu veranschlagen ? und diese Veranschlagung wird im Gegenzug zur Fertigstellung der Projektdefinition

Untergliedern Sie große Projekte in kleinere Einheiten (1.2.P2)

Die Tage der Hundert-Millionen-Projekte sind heute gezählt. Sehr große Projekte sind schlicht nicht zu managen und erfolgreich auszuführen. Mit großen Projekten verbindet sich eine Vielzahl von Problemen.

• Die Arbeit wird umso unklarer, je weiter sie in der Zukunft liegt. Große Projekte sind meist lange Projekte und das macht sie schwer planbar.
  
  
• Deshalb wird es umso schwieriger, genaue Schätzung für Aufwand, Dauer und Kosten anzugeben.
  
  
• Die geschäftlichen und technischen Bedingungen ändern sich im Laufe der Zeit. Damit werden Annahmen für die Planung sehr unsicher.
  
  
• Sie riskieren, die Unterstützung in Ihrer Organisation zu verlieren, wenn greifbare Resultate lange auf sich warten lassen.
  
  
• Es ist sehr schwierig, Bedarf und Verfügbarkeiten weit in die Zukunft vorauszusagen.
  

Grundsätzlich gilt, dass sehr große Einsätze viel schwieriger und komplexer sind als ein einzelnes Projekt. Es ist besser, wenn Sie den Gesamtumfang in handliche Brocken unterteilen, von denen jeder ein eigenes Projekt mit eigener Projektdefinition ist.

Sie können beispielsweise ein langfristiges IT-Vorhaben in mehrere Projekte auf Basis des Phasenkonzepts gliedern. Zunächst wird ein Projekt für die Analyse-Phase gestartet, danach eines für die Design-Phase, ein weiteres für Realisierung und Test und zuletzt ein Projekt für die Implementierung. Andere große Aufgaben können Sie vielleicht in kleinere Projekte unterteilen, die parallel ablaufen. Einige davon werden Sie sequentiell, andere parallel abwickeln können. Jedes Team arbeitet an seinem kleineren Projekt. Alle Arbeiten werden jedoch koordiniert, damit das Gesamtvorhaben ein Erfolg wird.

Programme vs. Projekte (1.2.P3)

Wenn Sie ein großes Vorhaben in eine Anzahl zusammenhängender Projekte untergliedern, entsteht die Notwendigkeit nach einem ganzheitlichen Management und Koordination. Zu diesem Zweck wird ein ?Programm? eingerichtet. Ein Programm ist eine Rahmenstruktur, in der eine Reihe zusammenhängender Projekte gesteuert werden. Jedes Projekt hat einen Voll- oder Teilzeit-Projektmanager. Das Programm wird von einem Programmmanager geleitet. Das Programm selbst produziert keinerlei Lieferobjekte. Diese sind die Ergebnisse der einzelnen Projektteams. Der Zweck des Programms besteht darin:

• Die allgemeine Richtung und Führung über alle Projekte vorzugeben
  
  
• Eine effektive Kommunikation zwischen den einzelnen Projekten sicherzustellen
  
  
• Als zentrale Kontaktstelle für die Kunden und Projektteams zu agieren
  
  
• Festzulegen, wie die Einzelprojekte zu definieren sind und damit den Erfolg des Ganzen sicherzustellen
  

Der Kunde kann das Projekt nur ungenügend umschreiben (1.2.P4)

Manchmal setzt man zu hohe Erwartungen in das Ausmaß von Vorausschau und Kenntnissen, über das die Kunden verfügen. In vielen Fällen verfügt der Kunde nicht über sämtliche benötigten Informationen. Das kommt oft vor, und es hat nicht zu bedeuten, dass der Kunde nicht weiß, was er will oder tut. In vielen Fällen, insbesondere bei großen Projekten, hat der Kunde eine Vision, wie das Endergebnis aussehen wird, kann seine Vision jedoch noch nicht in konkreten Lieferobjekten artikulieren. Vielleicht kann er auch nicht alle Fragen über Projektinhalt und -umfang, Risiken, Projektorganisation, etc. beantworten.

Da die Informationen, die dem Projektmanager zur Verfügung stehen, alles andere als vollständig sind, wird er es vielleicht für notwendig erachten, die Details zu erraten. Dies ist keine gute Lösung. Besser ist es, von vorneherein alles zu sagen, was Sie wissen, und ebenso auch alles, was Sie nicht wissen. Wenn man Sie auffordert, eine Veranschlagung von Arbeitsaufwand, Kosten und Dauer abzuliefern, werden Sie auf der Grundlage der verbleibenden Ungewissheit eine Bandbreite zwischen einer hoch angelegten und einer niedrig angelegten Schätzung angeben müssen.

Eine viel bessere Alternative ist, falls dazu die Möglichkeit besteht, die Arbeit einfach in eine Reihe kleinerer Projekte aufzuteilen. Selbst wenn die Endergebnisse nicht klar definiert werden können, sollte es eine gewisse Menge an Arbeit geben, die gut definiert ist. Dies wird im Gegenzug zu den Informationen führen, die für die endgültige Lösung benötigt werden. Sie sollten ein Projekt nur soweit definieren, wie sie es heute überblicken können. Definieren und planen Sie erst dann Nachfolgeprojekte um die verbleibende Arbeit abzudecken, wenn weitere Details bekannt werden. Beispielsweise wird ein erstes Projekt gestartet, das die Anforderungen genau erfasst. Aus den Resultaten wird das zweite Projekt die tatsächlichen Lieferobjekte produzieren.

Wenn es Ihnen nicht gestattet ist, das Projekt in kleinere Teilstücke aufzuspalten, sollten Sie zumindest über genügend Informationen verfügen, um das Projekt für die ersten 90 Tage planen zu können. Auch hier gilt, dass Sie eine detaillierte Planung der kurzfristig anliegenden Arbeit vornehmen und die längerfristigere Arbeit weniger präzise definiert belassen. Monatlich sollten Sie die verbleibende Arbeit neu planen und definieren. Je mehr Informationen Sie mit der Zeit erhalten, desto detaillierter und einfacher wird die Planung der verbleibenden Arbeiten. Diese Erkenntnisse teilen Sie mit dem Sponsor und holen sich die Einwilligung mit den Arbeiten fortzufahren.

Projektorganisation - Rollen und Verantwortlichkeiten (1.2.P5)

Für kleine Projekte ist die Organisationsstruktur recht einfach. Vielfach besteht sie nur aus dem Projektmanager und dem Kunden / Sponsor.

Bei großen Projekten können ziemlich komplexe Organisationsstrukturen entstehen, auch wenn Sie dies vermeiden wollen. Je mehr Personen in einem Projekt beteiligt sind, umso wichtiger wird es, dass jedem seine Rolle und Verantwortlichkeit verständlich ist. Das letzte was Sie möchten sind Leute, die Ihnen Direktiven vorgeben wollen als wären sie der Sponsor, obwohl sie nur Stakeholder sind. Ein anderes Problem sind Personen die glauben, sie wären ins Projektteam aufgenommen, die aber ebenfalls nur Stakeholder sind.

Einige der generellen Projektrollen und Verantwortlichkeiten werden in Abschnitt ?1.2.2 Projektdefinition / Rollen und Verantwortlichkeiten? beschrieben.

Projekt-Genehmigung (1.2.P6)

Es gibt mehrere Möglichkeiten, ein Projekt formal genehmigen zu lassen. Wie bei den meisten anderen Aktivitäten im TenStep Projektmanagement-Prozess ist auch hier ein wenig Planung der Schlüssel zum Erfolg. Bei kleinen Projekten reicht vermutlich eine Unterschrift des Hauptkunden oder des Sponsors. Bei größeren Projekten fragen Sie Ihren Manager und den Sponsor, wer eine explizite oder implizite Genehmigung der Projektdefinition erteilen wird und wer nur eine Kopie für Informationszwecke erhalten soll. Allgemein können Sie folgende Ausgangspunkte für Ihr Vorgehen verwenden:

• Sponsor und wichtige Stakeholder: Verlangen Sie eine explizite Abnahme, sei es in Form einer Unterschrift auf der Projektdefinition oder einer diesbezüglichen E-Mail. Das Entscheidende dabei ist, dass die Zustimmung explizit ausgedrückt wird und dass Sie alle Abnahmen in einem Ordner sammeln.
  
  
• Übrige Stakeholder: Holen Sie eine implizite Genehmigung ein. Schicken Sie diesen Personen eine Kopie der Projektdefinition mit Ersuchen um Überprüfung und Feedback. Setzen Sie ihnen eine Frist für die Antwort. Ohne Rückantwort gilt die Projektdefinition als abgenommen. Nehmen Sie vorkommende Vorbehalte mit Ihrem Projekt-Sponsor auf.
  
  
• Übrige Beteiligte: Schicken Sie ihnen eine Kopie der Projektdefinition zur Information und stehen Sie Ihnen für Fragen zur Verfügung. Die Kopie bedarf keiner Zustimmung.
  

Das Magische Dreieck - Triple Constraint (1.2.P7)

Am Ende des Definitions- und Planungs-Prozesses (Schritte 1 und 2) sollten Sie mit Ihrem Sponsor vereinbart haben, welche Arbeiten Sie durchführen werden, welche Kosten (Aufwand) dabei anfallen werden und wie lange es dauern wird. Diese drei Punkte bilden damit ein Dreieck, das als Magisches Dreieck auch Triple Constraint bezeichnet wird. Der entscheidende Aspekt des Triple Constraint ist, dass wenn sich einer der drei Punkte ändert, sich mindestens einer der anderen Punkte, wenn nicht gar beide, ebenfalls ändern muss. (Es gibt mehrere Darstellungsarten für das Triple Constraint. Der Punkt Kosten kann auch als Aufwand bezeichnet werden, was sinnvoller ist, wenn die Arbeitskosten ausschließlich interner Natur sind und wenn neben ihnen keine anderen Kosten anfallen. Der Punkt Projektumfang wird manchmal als Qualität bezeichnet, womit der Schwerpunkt dann darin liegt, bei bestimmten Kosten und einer bestimmten Dauer ein bestimmtes Qualitätsniveau zu erreichen. Dies ist nur eine begrenzte Sicht der Möglichkeiten, das allgemeine Konzept ist dennoch gültig.)

Dieses Konzept ist einfach zu visualisieren, wenn Sie sich die Beziehungen als ein Dreieck vorstellen, dessen Seiten die Aspekte Kosten, Dauer und Projektinhalt und -umfang darstellen.
Wenn der Projektumfang zunimmt, nehmen ebenso die Kosten zu und/oder der Abgabetermin verschiebt sich nach hinten. Wenn Sie mehr Arbeit zu erledigen haben, werden folglich die Kosten (Aufwand) steigen und vielleicht die Dauer verlängern. (Ebenso könnten die Kosten (Aufwand) abnehmen und/oder der Abgabetermin früher liegen, wenn der Projektumfang reduziert wird.
Wenn Sie gebeten werden, das Tempo zu steigern und das Projekt früher als vorgesehen fertig stellen, wäre es logisch nach weniger Arbeit zu fragen. Wenn Sie nun gebeten werden, die gleiche Arbeit bei kürzerer Dauer abzuliefern, muss die dritte Seite des Magischen Dreiecks angepasst werden ? müssen also die Kosten erhöht werden, damit die Balance erhalten bleibt.

Der Projektplan (1.2.P8)

Der Projektplan ist ein einzelnes Lieferobjekt, in dem sämtliche Projektmanagement-Dokumente abgelegt werden können, die in den Schritten 1.0 Projektdefinition und 2.0 Aufbau von Arbeitsplan und Budget verfasst werden. Selbstverständlich kann man auf die Dokumente auch individuell Bezug nehmen, doch der Projektplan kann dazu dienen, sie alle zusammenzufassen. Der Projektplan enthält:

• Projektdefinition (auch Projektcharter und / oder Festlegung des Projektumfangs genannt)
  
  
• Festlegung des Projektumfangs, Veranschlagung des Kosten-, Arbeits- und Zeitaufwands, Rollen und Pflichten, etc.
  
  
• Arbeitsplan (Terminplan), Projektstrukturplan, Meilensteine
  
  
• Projektmanagement-Verfahren
  
  
• Inhalts- und Umfangsmanagement Plan, Terminplan und Kostenmanagementplan
  
  
• Qualitätsmanagementplan, Personalplan
  
  
• Kommunikationsplan, Risikomanagementplan
  
  
• Projektgenehmigungen
  
  
• Weitere Projektmanagement-Dokumente
  

Der Projektplan kann ein tatsächliches Dokument sein, oder auch ein Heft oder ein Ordner. Sie könnten ein Ringheft führen, in dem all diese Dokumente abgelegt sind, und dieses Ringheft Projektplan nennen. Oder Sie könnten auf Ihrem Server unter dem Namen Projektplan einen Ordner speichern, in dem sie elektronische Kopien sämtlicher im Ordner enthaltenen Lieferobjekte ablegen.

Versuchen Sie, die zum Ausdruck gebrachten Wünsche und die realen Wünsche Ihres Kunden zu erkennen (1.2.P9)

Die Projektdefinition enthält eine allgemeine Beschreibung des Projekts. In der Projektdefinition werden die Bedürfnisse des Kunden sowie die Veranschlagungen des Projektteams bezüglich Arbeits-, Zeit- und Kostenaufwand speziell aufgeführt. Nähere Details zu den Bedürfnissen des Kunden werden schließlich bei der Erstellung des Pflichtenhefts erfasst.

Projektmanager und Projektteam müssen sich unbedingt darüber im Klaren sein, dass die wahren Bedürfnisse des Kunden nicht unbedingt deckungsgleich mit den Bedürfnissen sind, die Ihnen genannt wurden und auf deren Grundlage die Projektdefinition und das Pflichtenheft verfasst worden sind. In vielen Fällen kennt der Kunde bei Projektbeginn seine wahren Bedürfnisse selbst nicht. Diese können gelegentlich im Laufe des Projekts zutage treten. Ebenso mag der Kunde zwar eine klare Vorstellung von seinen Bedürfnissen haben, doch es fällt ihm schwer, diese dem Projektteam gegenüber zum Ausdruck zu bringen. Bis zu einem gewissen Grad ist eben dies Sinn und Zweck des Umfangs-Änderungsmanagements ? der Kunde soll Gelegenheit haben, die Anforderungen des Projekts zu ändern, während es noch im Gange ist.

Das Projektteam kann nichts Besseres tun, als die zum Ausdruck gebrachten Bedürfnisse des Kunden zu dokumentieren und sie als Grundlage zur Abnahme der Projektdefinition und des Pflichtenhefts zu verwenden. Dennoch stimmt auch, dass das Projektteam sich nach Kräften bemühen sollte, die wahren Bedürfnisse des Kunden zu ermitteln. Zu diesem Zweck wird es gute Fragen sowie zielgerichtete nachträgliche Fragen stellen, Input von allen wichtigen Stakeholdern einholen, weitere Fragen stellen, wenn die Anforderungen keinen Sinn zu ergeben scheinen, etc.. Gewiss sollte das Projektteam tun, was es kann, um die wahren Bedürfnisse des Kunden zu ermitteln. Je eher die wahren Bedürfnisse des Kunden sich mit den zum Ausdruck gebrachten Bedürfnissen decken, desto eher wird es Ihnen gelingen, das Projekt auf Anhieb richtig durchzuführen.

Nächstes Kapitel: 1.2.1 Definition des Projekts / Ziele