Projektstart
Je nachdem, ob ein Projekt klassisch oder agil durchgeführt wird, fällt der Projektstart unterschiedlich aus. In agilen Projekten ist wesentlich weniger Planungsaufwand erforderlich und es kann zeitnah mit der eigentlichen Projektarbeit begonnen werden. Der Releaseplan beschreibt den geschätzten Umfang der einzelnen Projektbestandteile, das Product-Backlog dokumentiert detailliert die Anforderungen, ändert sich im weiteren Projektverlauf stetig und wird den Anforderungen sowie den Erfahrungen des Projektteams angepasst (vgl. Röpstorff/Wiechmann 2016, S.178ff.).
Im klassischen Projektmanagement gibt es unterschiedliche Zeitpunkte, ab wann von Projektstart gesprochen wird. Dies hängt von der Sichtweise ab. Unterschieden wird hier zwischen Projektstart im engeren und im weiteren Sinne (vgl. Schulz 2019, S. 38). Der Projektstart im engeren Sinne meint den ideellen Projektstart, wenn die erste Projektidee und der Wille entstehen, ein Projekt durchzuführen. Zu diesem Zeitpunkt wird häufig der Meilenstein 0 (MS=0) gesetzt, da bis zu diesem Zeitpunkt weder Leistungen erbracht noch Zeit und Kosten verbraucht wurden.
Der Projektstart im weiteren Sinne umfasst zusätzlich die Projektbeauftragung, die Auftragsklärung, den Beginn der Wertschöpfung, die erste grobe Planung und das Kick-off-Meeting. Insofern sollte der Projektstart an sich auch eher als eigene Phase betrachtet werden. Alle Fehler, die zu Beginn eines Projekts erkannt und vermieden werden, helfen, den Projekterfolg zu sichern. Insofern sollte auf den Projektstart eher mehr als zu wenig Zeit verwendet werden. In jedem Fall gibt es aber ein Merkmal, das verpflichtet, den Start zu setzen, unabhängig davon, ob das Projekt agil oder klassisch durchgeführt wird.
Spätestens mit dem Beginn von Zählen, Messen und Produzieren muss das Projekt starten. In der Phase des Projektstarts erstellt die Auftrag gebende Person in klassisch durchgeführten Projekten das Lastenheft, das die Vorstellungen und Anforderungen des Projekts beschreibt. Auf Basis des Lastenhefts schreibt der Auftragnehmende das sogenannte Pflichtenheft, in dem er die eigenen Realisierungsvorgaben auf Basis der Anforderung beschreibt (vgl. GPM 2019, S. 1069). Bevor mit der Durchführung eines Projekts begonnen werden kann, muss die Auftrag gebende Person das Pflichtenheft freigeben.
Das Heft soll gewährleisten, dass sowohl Auftraggebende als auch Auftragnehmende die gleichen Vorstellungen von den Projektzielen und Ergebnissen haben (siehe Abb.).
Auftragsklärung
In der Phase des Projektstarts findet die Auftragsklärung statt. Sie ist in jedem Fall als Prozess zu verstehen und hat das Ziel, die Bedürfnisse vom Auftraggebenden
für den Auftragnehmenden verständlich zu machen. Im Verlauf einer gelungenen Auftragsklärung verstehen die Auftraggebenden und Auftragnehmenden mehr
und mehr, welches Problem mit dem Projekt gelöst werden soll und welche Anforderungen sich daraus für die Arbeit im Projekt ergeben. Wie muss eine Auftragsklärung gestaltet sein, damit sie gut gelingt? Zunächst einmal sollte sowohl vom Auftraggebenden als auch vom Auftragnehmenden ausreichend Zeit investiert werden, um das Anliegen zu formulieren und Fragen zu stellen. Es empfiehlt sich, mehrere Termine für die Auftragsklärung einzuplanen, um zwischen diesen Terminen die Projektidee und die Umsetzung der Kundenwünsche (Auftrag gebende Person) immer weiter zu konkretisieren. Ziel ist es, am Ende der Auftragsklärung ein formuliertes Pflichtenheft zu haben, in dem verständlich und nachvollziehbar die Ziele für das Projekt, aber auch das Vorgehen in Form der Detailplanung beschrieben sind. In agilen Projekten beschreibt der Releaseplan Verantwortlichkeiten, Ressourcen und die Zeitplanung.
Eine sehr gute Vorlage zur Gestaltung der Auftragsklärung findet sich bei Mayrshofer und Kröger (vgl. Mayrshofer/Kröger 2011, S. 127). Neben ausreichend Zeit helfen Kreativitätstechniken (siehe Kap. 3.5.) und Visualisierungen (siehe Kap. 3.3) dabei, ein gemeinsames Verständnis für das Projekt zu entwickeln. Sowohl in agilen als auch in klassischen Projekten sollte zu Beginn ein Kick-off- Workshop mit dem Projektteam und gegebenenfalls der Auftrag gebenden Person oder wichtigen Stakeholdern5 stattfinden, um eine Identifikation mit dem Projekt und den Projektbeteiligten zu erzeugen und an der gemeinsamen Vision zu arbeiten.
Kick-off-Workshop
Je nach Projektgröße kann ein Kick-off-Workshop einen halben bis drei Tage dauern (vgl. GPM 2019, S.1471). Er sollte an einem Ort stattfinden, an dem die Teilnehmenden
in Ruhe arbeiten können. Je nachdem, wie das Projekt aufgesetzt ist – ob agil oder klassisch – kann der Workshop vom Scrum-Master, der Projektleitung oder aber auch einer externen Person moderiert werden. In jedem Fall sollten ausreichend Moderationsmaterialien vorhanden sein, damit die Themen und Ergebnisse visualisiert und festgehalten werden können. Typische Themen eines Kickoff-Workshops sind die Vorstellung der Projekthistorie (Warum machen wir dieses Projekt?), Vorgaben für das Projektmanagement, Zieldefinition, Stakeholderanalyse, Risikoanalyse, Rollenklärung, Regelung für die Zusammenarbeit sowie erste konkrete Folgeschritte und Verabredungen für das weitere Vorgehen (vgl. ebd.). Das Ergebnis eines Kick-off- oder auch Anforderungsworkshops ist in traditionellen Projekten häufig eine erste Version des Pflichtenhefts, in agilen Projekten der Releaseplan.
Projekt definieren
Ein Projekt hat einen definierten Anfang und ein definiertes Ende – innerhalb dieser beiden Punkte müssen die Anforderungen und damit der Umfang des Projekts
definiert werden. Um sich einem guten Verständnis für das Projekt und damit dem Projektumfang anzunähern, gibt es verschiedene Tools und Methoden, die im Folgenden kurz dargestellt werden sollen. Diese Methoden lassen sich sowohl in klassisch durchgeführten Projekten als auch in agilen Projekten gut einsetzen.
Projektsteckbrief
Der Projektsteckbrief ist ein übersichtliches Dokument, meist ein One-Pager, welches alle relevanten Informationen zum Projekt enthält. Der Steckbrief gibt den Projektbeteiligten eine gute Übersicht über die Idee, die mithilfe dieses Projekts umgesetzt werden soll (siehe Abb.7). Häufig stellt der Projektsteckbrief in Kombination mit anderen Dokumenten (Business Case6) auch eine Entscheidungsvorlage dar, um Gremien eine Handreichung zu geben, auf deren Grundlage entschieden werden kann, ob das
Projekt umgesetzt werden soll oder nicht (vgl. Kuster u. a. 2018, S. 43).
Project-Canvas
Big Picture
Das Big Picture erhebt den Anspruch, das große Ganze zu betrachten. Es soll das Projekt mit seinen Prozessen, Ideen und Visionen in Form eines Gesamtbildes darstellen,
idealerweise überwiegend in Form von Symbolen, mit wenig Schrift. Die wichtigsten Aspekte und Zusammenhänge des Projekts werden plakativ dargestellt. Ebenso wie die anderen Methoden schafft das bei Projektstart eine gemeinsame Sicht auf die Dinge. Es dient zudem als Diskussionsgrundlage und beim Erstellen treten unterschiedliche Sichtweisen, Prioritäten und Perspektiven genauso zutage wie fehlende Informationen und erste Risiken (vgl. GPM 2019, S. 1112). Big Pictures können analog oder digital dargestellt werden (siehe Abb. 9).
User-Story
Die User-Story ist eine Methode aus dem agilen Projektmanagement, mit deren Hilfe Kundenbedürfnisse formuliert werden. Auch der Projektumfang lässt sich mit User-Stories sehr gut eingrenzen, da deutlich wird, welche Bedürfnisse überhaupt erfüllt werden müssen und welche nicht. Die User-Story ist keine grafische Visualisierung von Anforderungen, sondern ein Sprachraster, mit dessen Hilfe Kundenwünsche formuliert werden. Dies erfolgt immer auf der Basis folgenden Rasters:
- „Als Nutzer[:in] will ich Ziel/Wunsch damit Nutzen.“ (Foegen 2017, S. 131ff.)
Eine User-Story für ein Recruiting-Projekt könnte beispielsweise lauten: „Als Bewerberin möchte ich auf der Internetseite herausfinden können, wie dieses Unternehmen zur Vereinbarkeit von Familie und Beruf steht, um für mich entscheiden zu können, ob dieser Arbeitgeber für mich infrage kommt.“ (User-Story PIP Projekt, WS 2016/17).
Ziele definieren
Ziele sind deutlich zu unterscheiden von Anforderungen. Ziele beschreiben, was im Projekt erreicht werden soll, Anforderungen beschreiben, in welcher Güte und mit welcher Qualität die Ziele erreicht werden sollen. Die Anforderungen werden aus den Zielen abgeleitet, nicht umgekehrt (vgl. Kuster u. a. 2018, S. 105). Ziele, die zu Projektbeginn beschrieben werden, sollten bestimmte Kriterien erfüllen. So sollten sie beispielsweise SMART sein. Das Akronym SMART steht für spezifisch, messbar, attraktiv, realistisch und terminiert. Im klassischen Projektmanagement muss jedes Ziel gemäß dieser Kriterien operationalisiert, d. h. messbar gemacht werden. Für jedes Ziel wird ein Grad und ein Maß benötigt (vgl. GPM 2019, S. 1067).
Eine Zielbeschreibung könnte dann wie folgt lauten: „Erstellung des Simulationsprogramms mit Matlap und Simulink-Programm bis April 2018 erstellen, testen mit Fehlerquote unter 5 Prozent, interner Betatest durch Mitglieder des Projektteams, externer Betatest bis Ende Juni 2018.“ (PIP Projekt, WS 2018/19)
Je nachdem, ob ein Projekt agil oder klassisch durchgeführt wird, wird auch mit Zielen anders verfahren. Traditionell stehen zu Beginn eines klassisch durchgeführten
Projekts Ziele und Anforderung fest. Kosten und Zeit dagegen können sich im Projektverlauf häufig noch ändern. Bei agilen Projekten ist es genau umgekehrt: Hier werden zu Projektbeginn Zeit und Kosten klar definiert, wodurch auch der Leistung Grenzen gesetzt sind. Daher können sich in agilen Projekten die Ziele im Verlauf durchaus noch ändern (vgl. Kuster u. a. 2018, S. 81) (siehe Abb. 10).
Kreativitätstechniken
Projekte beschäftigen sich mit etwas Neuem. Neues braucht Innovation und Ideen: Kreativität ist gefordert. Daher ist der Einsatz von verschiedensten Kreativitätstechniken
bei jedem Projektmanagementansatz empfehlenswert. In Bezug auf Kreativität hat agiles Arbeiten und Denken die Projektwelt erheblich bereichert. Neue Methoden sind entstanden und Methoden aus anderen Bereichen wie etwa der Freizeitpädagogik finden nun auch Einsatz in professionellen Projektteams.
So kann beispielsweise mit der Methode Lego Serious Play® gerade bei Projektstart im Team ein dreidimensionales Big Picture erstellt werden, was nicht nur Projektanforderungen definiert, sondern gleichzeitig auch den Teamgeist und die Verbindung zum Projekt fördert (siehe Bildbeispiele 7). Es gibt eine Vielzahl an Kreativitätstechniken. Dabei wird unterschieden zwischen eher intuitiven Methoden wie Brainstorming oder Mindmapping und eher systematischen Techniken wie dem morphologischen Kasten oder der Osborne-Checkliste.
Im Lexikon der Projektmanagementmethoden finden sich diverse Methoden, passend zur Projektarbeit beschrieben (vgl. Drews/Hillebrand 2010). Darüber hinaus sind das große Handbuch für Innovation (vgl. Burkhardt u. a. 2018) sowie das Praxisbuch Agilität zu empfehlen (vgl. Häusling u. a. 2018).
Was ist ein Projekt?
Grundsätzlich lassen sich viele Definitionen zum Wort „Projekt“ finden. Schauen wir auf das Wort selbst: Aus etymologischer Sicht bedeutet „Projectum“ so viel wie „das nach vorn Geworfene“. Was bedeutet das im „praktisch-wissenschaftlichen“ Sinn? Eine allgemeingültige Definition gibt es bislang nicht und in der Projektpraxis definieren Organisationen und Unternehmen diesen Begriff für sich höchst individuell.