[Selbstmanagen] [Projektmanagement] [PM-Übersicht] [Integration] [PM-Begriffe]
[Analyse/Planung] [Start] [Kosten] [Qualität] [Ressourcen] [Kommunikation] [Änderung] [Risiko] [Beschaffung]
Projektanalyse und Projektplanung
Da gewisse Elemente der Projektplanung auch schon in der Projektanlyse Beachtung finden, werden an dieser Stelle die Punkte Projektanalyse und Projektplanung gemeinschaftlich behandelt. Die
Projektanalyse nimmt vor dem eigentlichen Start des Projektes sein gesamtes Umfeld unter die Lupe und beschäftigt sich mit den nötigen Arbeiten und deren Abhängigkeiten, die für die Durchführung des Projektes notwendig sind. Sie
hat somit das Ziel, alle notwendigen Dinge zu definieren und auszuwählen, die mit in den Projektablauf einbezogen werden und welche nicht. In der Projektplanung werden diese
Erkenntnisse in klare, nachvollziehbare und kontrollierbare Ablaufstrukturen gebracht, sodaß unter den gegebenen Randbedingungen die Ziele des Projektes erreicht werden können.
Klassifikation des Projektes
Das Umfeld eines Projektes besteht aus mehreren Unterbereichen, wie z.B.:
- technische Details (Machbarkeit, Risiko)
- finanzielle Details (Wirtschaftlichkeit)
- Positionierung des Projektes (Wichtigkeit, Unterstützung, Sponsoren)
- Projektbeteiligte (Steakholder)
- Auswirkung auf die Projektumwelt (sozial, wirtschaftlich)
Differenziert nach Komplexität der Aufgabenstellung (z.B. geschlossen oder offen) und der möglichen Auswirkung auf die Projektumwelt (sozial und/oder wirtschaftlich) unterscheidet man folgende vier Projekttypen:
|
||||||||
Gleiches Projektverständnis auf allen Seiten
Eine wichtige Bedingung für einen späteren reibungslosen Ablauf, ist das gleiche Verständnis über das
Projekt und seiner Ziele zwischen dem späteren Projektteam und allen anderen Projektbeteiligten. Diese Synchronisierung ist notwendig, damit die eine Gruppe nicht A annimmt, während die andere Gruppe
zunächst unbemerkt auf B hin zuarbeitet. Grund solcher Mißverständnisse sind meistens unklare oder nicht eindeutig beschriebene Ziele, die Raum für Interpretationen lassen. Ein Synchronisationsprozeß
über das gemeinsame Verständnis der Projektziele läßt sich generell in vier Schritten bewerkstelligen:
- Einführung
Beginn des Projektes mit dem Sammeln aller projektrelevanten Informationen. Hierbei muß ein globaler Blick angewendet werden, der auch strategische und langfristige Gesichtspunkte der Organisationen berücksichtigt. Hier gibt es drei wichtige Punkte. Fehlt auch nur einer, steht das Projekt auf wackeligen Beinen: - Es gibt einen Bedarf für das Projekt
- Es gibt entsprechende Geldmittel um das Projekt zu realisieren
- Es gibt von allen Seiten den festen Willen, das Projekt erfolgreich zu beenden
- Projektplanung
Erzeugung von Dokumenten, die als Kriterium für die späteren Entscheidungen herangezogen werden. Die Problemanalyse stellt die Gründe für das neue Projekt dar. Die Zielformulierung sollte ausführlich und insbesondere machbar, verständlich sowie lösungsneutral beschrieben sein. Ebenso sollten die Dokumente klare Bewertungskriterien enthalten, um die Erfüllung der Projektziele meßbar zu machen. Ebenso sollten Abbruchstrategien zu bestimmten Milestones nicht fehlen. Kontrollelemente der Planung ("Wie stelle ich sicher, daß ...") sind Qualitätssicherung, Terminkontrolle, Kostenkontrolle und kritische Erfolgsfaktoren sofern diese vorhanden sind. Weitere Planungselemente in dieser Phase sind: - Strukturplanung: Welche Arbeiten gibt es und wer führt sie durch?
- Ablaufplanung: Welche Reihenfolge der Arbeiten muß eingehalten werden und was ist deren Zeitrahmen? Können Arbeiten parallel durchgeführt werden?
- Kostenplanung: Welche Arbeit darf wieviel kosten und woher kommt das Geld? Wieviel Geld steht insgesamt zu Verfügung?
- Organisation: Welche Kommunikationsstrukturen gibt es oder müssen eingeführt werden?)
- Risikoplanung: Wo liegen die Risiken? Sind diese Risiken tragbar oder können diese beseitigt bzw. minimiert werden?
- Projektdefinition
Diese enthält Dokumente, die den Inhalt des Projektes und die finale Aufteilung in kleinere handhabbare Arbeitspakete sowie die Verantwortlichkeiten, die sich aus den Zieldefinitionen und den großen übergeordneten Aufgaben ergeben (WBS, Work Breakdown Structure) beschreiben. - Projektverständnis und Projektakzeptanz
Ein gemeinsames Projektverständnis formulieren (s. Projektdefinition) und mit allen Beteiligten - vor allem mit den Entscheidern innerhalb der Stakeholder - synchronisieren. Dieses beinhaltet als wichtigste Elemente die Rollen des Auftraggebers und des Auftragnehmers, wobei auch die Schnittstellen zwischen beiden durch Dokumente bzw. Verträge genauestens estgehalten werden.
Das Dokument SOW (Statement of Work) beinhaltet die Aufteilung der Arbeiten und der Verantwortlichkeiten der beiden Gruppen und legt eindeutig fest, wer was zu erledigen hat, wer für was verantwortlich ist oder nur an bestimmten Prozessen beteiligt ist.
Weitere Gruppen der Steakholder, die u.U. nicht direkt mit der Abwicklung des Projektes in Berührung kommen, sind das eigene Management, Ausrüster bzw. Zulieferer und die späteren Anwender des Produktes. Aber auch projektfremde Personengruppen wie Gegner (verfolgen z.B. ein anderes konkurrierendes Projekt) oder Unterstützer des Projektes, sollten in der Analyse berücksichtigt werden, da sie oft einen wichtigen positiven oder negativen Einfluß auf das Projekt ausüben können. Organisationsstrukturen sollten dabei ganzheitlich betrachtet werden. Häufig wird bei den Strukturen der einzelnen Gruppen vergessen, daß es mehr als nur eine Sichtweise gibt. Wie sie sich letztendlich darstellt ist eine Frage des Standpunktes. Grundsätzlich gibt es drei verschiedene Organisationsstrukturen, unter denen die Steakholder betrachtet werden können: - Funktionale Struktur: Wer hat in der Organisation welche Funktion?)
- Projektorientierte Struktur: Wer übt innerhalb des Projektes welche Funktion aus?)
- Matrix: Mischung auf funktionaler und projektorientierter Form
Da es in Projekten häufig zu Änderungen kommen kann, sollten die oben aufgeführten Schritte flexibel in Hinsicht auf mögliche Veränderungen formuliert werden. Prozeduren, die nach einer Änderung das
Projekt neu überdenken (Risikomanagement), sollten ebenfalls vorgesehen sein.
Hat man sich am Ende mit allen Beteiligten auf ein gemeinsames Verständnis geeinigt, müssen die erstellten Dokumente der Projektplanung entsprechend angepaßt und dem Projektteam in der
endgültigen Fassung zu Verfügung gestellt werden.
Projekt und Lebenszyklus des Produktes
Mit einem Projekt wird häufig ein Produkt oder ein Teil eines Produktes
erzeugt oder entwickelt. Während das Projekt durch ein eindeutiges Ende gekennzeichnet ist, kann das Produkt noch über das Projekt hinaus weiterleben. Entsprechendes gilt für den Anfang. Beispiele hierfür sind:
- Das Projekt betrifft nur einen Teilaspekt des Produktes
- Das Projektende stellt nur eine erste/vorläufige Version des Produktes das
- Das Projekt stellt die Entwicklung des Prototypen des Produktes dar. Die anschließende Massenproduktion wird durch dieses Projekt noch nicht erfaßt.
Daher sollte oder muß das Produkt während der Analyse des Projektes über seinen gesamten Lebenszyklus hinweg betrachtet werden. Hier hat sich bei IT-Projekten der Begriff System Development Life Cycle (SDLC) etabliert, der das Produkt in seinen Entwicklungs- und Wartungsphasen beschreibt. Typische SDLC-Phasen sind Analyse, Konzeption, Planung, Entwicklung, Implementierung, Unterstützung (Support) und Wartung (Maintenance). Die Aneinanderreihung dieser Phasen innerhalb des Procuct Life Cycles lassen sich mit unterschiedlichen Modellen darstellen:
- Waterfall Model
Wohl definierte, lineare Stufen in der Systementwicklung, an deren Ende das endgültige Produkt steht. Keine weiteren Projekte beziehen sich auf dieses Produkt. - Spiral Model
Ein iterativer Ansatz, bei dem nach der Fertigstellung einer Version des Produktes mit der Entwicklung einer neuen Version weitergemacht wird. Dieses Modell ist eine Verfeinerung des Waterfall Models wird häufig bei Softwareentwicklungen angewendet. - Incremental Release Model
Ansatz, bei dem ein Produkt (häufig Software) von einer Version zur nächsten mit weiteren Funktionen ausgestattet wird, bis das Endprodukt fertig gestellt ist. - Prototyping Model
Ansatz, um eine vorläufige Produktversion zu erstellen, um z.B die Anforderungen und Kundenerwartungen zu klären oder eine Machbarkeitsstudie durchzuführen.
Während alle Projekte mehr oder weniger gut mit dem einfachen Zyklusmodell Konzeption, Entwicklung, Implementierung und Beendigung (Close-out) beschrieben werden können, sind die Zyklen eines Produktes stark von seiner Natur abhängig und können sich daher deutlich von Produkt zu Produkt voneinander unterscheiden. IT-Projekte werden häufig als eine Aneinanderreihung von einzelnen Projekten konzipiert (z.B. eine nach und nach verbesserte Softwareversionen). Das Produkt wird von Version zu Version besser, vollständiger und komplexer. Insbesondere hier muß in der Projektanalyse auch die nach dem Projektende existierenden Produktzyklen mit berücksichtigen (Produzierbarkeit, spätere Erweiterungen, Kompatibilität, Wartung beim Kunden, Unterhaltungskosten).
Finanzielle Analyse des Projektes
Natürlich muß in der Phase der Projektanalyse der finanzielle und wirtschaftliche Aspekt eines Projektes
behandelte werden. Näheres hierzu auf der Seite Kostenmanagement.
Auswahlkriterien bei mehreren Alternativen
Was passiert wenn sich bei der Analyse herausstellt, daß es mehrere Möglichkeiten der Realisierung
gibt? Häufiges Hilfsmittel bei der Auswahl aus mehreren Projektalternativen ist ein gewichtetes Punktemodell, mit dem die einzelnen Projekte entsprechend der folgenden Methode bewertet werden:
- Identifikation von wichtigen und möglichst gemeinsamen Kriterien innerhalb der erkannten Alternativen (Aufwand, Kosten, Laufzeit, Ressourcen, ...)
- Zuweisung einer Wichtung zu den einzelnen Kriterien innerhalb des einzelnen Projektes, sodaß deren Summe insgesamt 100% ergibt
- Zuweisung von Punkten zu jedem Kriterium (Beispiel: Kurze Entwicklungszeitraum ist extrem wichtig: 40 Punkte. Produktkosten weniger wichtig: 10 Punkte)
- Multiplikation der Punkte mit den entsprechenden Wichtungen um die Gesamtpunktzahl des Projektes zu ermitteln
- Gewinner ist - wer hätte das gedacht - das Projekt mit den meisten Punkten. Je höher die Punktedifferenz zu den anderen Alternativen, um so einfacher fällt die Entscheidung.
Dieses Prinzip läßt sich ebenso leicht wie einfach bei verschiedenen Alternativen innerhalb der Projektabwicklung eines Projektes anwenden, z.B. Nutzung der eigenen Ressourcen oder Outsourcing eines bestimmten Arbeitspaketes.
Prinzipien und Entwicklung der WBS (Work Breakdown Structure)
Die WBS ist eine ergebnisorientierte Analyse der notwendigen Arbeiten für den erfolgreichen Abschluß eines Projektes. Sie definiert daher alle Arbeiten des gesamten Projektumfeldes in deren zeitlichen,
materiellen und Ressourcen bedingten Zusammenhängen. Damit hilft die WBS die A
bschätzungen des
Zeitplans, der Kosten und der Ressourcen zu verbessern.
Eine detaillierte Ausführung der WBS ist für das PM die Basis für ein erfolgreiches Management des Zeitplans, der Kosten und auftretender
Änderungen und ist daher extrem wichtig für einen planvollen und kontrollierbaren Ablauf des Projektes. Die WBS kann in Bezug auf das Produkt, auf die einzelnen Projektphasen oder in tabellarischer Form
organisiert werden. Folgende Ansätze sind möglich:
- Benutzung von Richtlinien
Einige Organisationen (z.B. DOD) stellen Richtlinien für die Erstellung von WBS zu Verfügung - Analoger Ansatz
Ähnliche Projekte liefern die Basis für eine WBS, die an das aktuelle Projekt angepaßt wird - Top-down Ansatz
Beginnend bei dem größten Arbeitspaket werden die Pakete in kleinere aufgebrochen, bis überschaubare und handhabbare Pakete entstanden sind. - Bottom-up Ansatz
Beginnend mit kleinen detaillierten Arbeiten werden die großen und damit letztendlich das gesamte Projekt zusammengesetzt. Diese Vorgehensweise ist eher unüblich.
Um eine WBS und seine Arbeitspakete von Anfang an in eine endgültige Form zu bringen um Konflikte und Nacharbeiten zu vermeiden, sollten folgende Regeln bei der Erstellung berücksichtigt werden:
- Die Arbeitspakete müssen losgelöst von anderen bearbeitet werden (Unabhängigkeit)
- Sie müssen wie das Projekt selber durch einen Start, eine endliche Laufzeit und durch ein Ende begrenzt werden
- Welche Arbeitspakete sind die Vorgänger, und welche Arbeitspakete sind die Nachfolger jeder einzelnen Aufgabe. Erst mit den Ergebnissen einer oder mehrere vorgeschalteter Arbeitspakete kann diese Teilaufgabe begonnen werden.
- Für den Start sind eindeutige Bedingungen zu definieren, mit denen ein Arbeitspaket begonnen werden kann
- Für das Ende sind eindeutige Bedingungen zu definieren, die den Abschluß eines Arbeitspaketes definieren
- Jedes Arbeitspaket muß eindeutig formuliert und dokumentiert sein, um ein gemeinsames Verständnis über seine Schnittstellen und den Ergebnissen zu erlangen
- Ein Arbeitspaket ist nur ein einziges mal in der WBS definiert
- Der Inhalt eines Arbeitspaketes ist die Summe aus den Ergebnissen der untergeordneten Arbeitspakete
- Start oder Ende von wichtigen bzw. übergeordneten Arbeitspaketen stellen die so genannten Meilensteine (Milestones) dar, an deren Verlauf man später den allgemeinen Zustand des Projektes messen kann
- Die Verantwortung für ein Arbeitspaket darf nur einer einzelnen Person zugeordnet werden, auch wenn mehrere Personen an diesem Paket arbeiten
- Für jedes der Arbeitspakete, die auf der untersten Ebene die Arbeiten eines einzelnen Teammitgliedes festlegen, sind mit allen Beteiligten die Verantwortlichkeiten und Zuständigkeiten zu klären. Dieses sollte am besten nach einer Vorplanung in einem Meeting mit dem gesamten Team durchgeführt werden, in dem die Teilaufgaben iterativ bestimmt werden (s. KickOff Meeting). Hier bekommt jeder seine Aufgaben zugewiesen, wobei eine reale Abschätzung über die Dauer der Teilaufgabe abgegeben werden muß. In dieser Phase werden neben der menschlichen Arbeitskraft auch weitere Ressourcen zugewiesen (z.B. Maschinen).
- Die WBS muß konsistent mit dem Arbeitsfluß formuliert werden. Sie muß den Fähigkeiten des Projektteams angepaßt sein, um seine Ressourcen optimal zu nutzen
- Das Projektteam sollte an der Entwicklung der WBS beteiligt sein, um die geforderte Konsistenz zwischen den Arbeitspaketen zu garantieren
- Die WBS muß als flexibles Werkzeug betrachtet werden, um auf unausweichliche Änderungen im Sinne des Projektes reagieren zu können.
Um den Ablauf eines Projektes auch für andere sichtbar zu gestalten und sich gegen Überraschungen aufgrund von unglücklichen Formulierungen oder unterschiedlichem Verständnis zu schützen, sollten folgende Dinge während der Planung und für den späteren Projektablauf berücksichtigt werden:
- Für das Projekt sollte ein Sponsor aus den Reihen der Nutzer vorhanden sein
- Spätere Nutzer des Produktes sollten im Projektteam enthalten sein
- Reguläre Meetings halten um den Projektstatus gemeinsam zu klären um ständig ein gleiches Verständnis darüber zu haben
- Auf einer regulären Basis sollte etwas an die Benutzer und die Sponsoren geliefert werden: Zwischenversionen, Statusmeldungen, ...
- Benutzer des Produktes und seine Entwickler sollten von Zeit zu Zeit zusammengeführt werden
- Vorschläge zur Reduzierung von unvollständigen oder sich ändernden Anforderungen
- Viel Wert auf die Einhaltung des Zeitplans legen
Absichtserklärung und Projektvertrag
Nach den getroffenen Projektentscheidungen ist es wichtig, die gewünschten Ergebnisse und die vereinbarten Rahmenbedingungen in einer Absichtserklärung zu beschreiben. Dieses definiert allgemein die Existenz
des Projektes und enthält deutliche Anweisungen, wie mit dem Projekt von nun an weiter zu verfahren ist. Da dieses Dokument quasi den Ausgangspunkt der Projektabwicklung darstellt, sollte es von allen
wichtigen Entscheidern (Auftraggeber, Auftragnehmer, Lieferanten) unterschrieben werden, um die gemeinsamen Vereinbarungen über den Bedarf, die Absichten und die Rahmenbedingungen des Projektes festzuhalten.
Weitere Details, die von dem Auftraggeber und dem Auftragnehmer unterzeichnet werden müssen, befinden sich in dem Projektvertrag. Dieser beinhaltet neben weiteren projektabhängigen folgende Punkte:
- Allgemeine Vorkehrungen (Sprache, Regeln, ...)
- Spezielle Garantien
- Gesetzliche Regelungen
- Finanzielle Vorkehrungen (Währung, Preis, Steuern, ...)
- Projektdurchführung (Konditionen, Auftragnehmer, Auftraggeber, Aufgabenübertragung, ...)
- Projektabnahme und die Bewertung der Ergebnisse
- Sonstige Konditionen (Patente, Lizenzen, ...)
Viele Fehler passieren durch eine mangelhafte Projektinitiierung. In der folgenden Checkliste Projekt sind noch einmal zahlreiche wichtigste Aspekte Punkte aufgeführt, die während der
Projektanalyse und am Start des Projektes bereits eine Rolle spielen.
