Projektphasen im Projektmanagement: Strukturiert zum Erfolg

Projekte punktgenau zu planen und erfolgreich umzusetzen, erfordert eine strukturierte Vorgehensweise – und damit eine Einteilung des Projekts in Phasen. Jede Phase hat dabei ihre eigenen Ziele, Arbeitsprodukte und Meilensteine, die es dem Projektteam ermöglichen, den Fortschritt des Projekts zu messen und dieses zu steuern. Im Folgenden stellen wir die Projektphasen im klassischen und agilen Projektmanagement vor und gehen kurz auf die Vorteile eines professionellen Anforderungsmanagements ein.

In diesem Artikel behandelte Themen

• Projektphasen im klassischen Projektmanagement
• Projektphasen im agilen Projektmanagement …?
• Anforderungsmanagement in jeder Phase des Projekts

Ziel des Beitrags: Projektverantwortliche (in spe) und Projektmitarbeiter erfahren, warum die Einteilung eines Projekts in Phasen maßgeblich zu dessen erfolgreichem Abschluss beiträgt.

Projektphasen sind konstitutiv für (klassische) Projekte und ermöglichen eine klare Struktur für die Planung, Durchführung und Kontrolle des Vorhabens. Anders ausgedrückt: Ohne Phasen wäre ein Projekt überhaupt kein richtiges Projekt – und auch das Risiko des Scheiterns wäre erheblich größer. Demgegenüber ebnet die Gliederung in Projektphasen den Weg für eine planvolle Abfolge von Aktivitäten und Ergebnissen, die zur Erreichung des Projektziels notwendig sind.

Die Einteilung eines Projekts in einzelne Phasen – und mithin Unterziele, Arbeitsprodukte und Meilensteine – ist damit eine zentrale Voraussetzung für erfolgreiches Projektmanagement. Neben der Strukturierung, Planung und Überwachung eines Projekts erleichtert jede Projektphase auch die Entscheidungsfindung im Projektverlauf. So können Projektmanager, Teammitglieder und Stakeholder nach Abschluss jeder Phase die Ergebnisse überprüfen und bewerten und auf der Grundlage von Fakten und Zahlen Entscheidungen über das weitere Vorgehen treffen. Ferner ermöglicht die strukturierte Herangehensweise einen effizienten Informationsaustausch innerhalb des Projektteams sowie mit den Stakeholdern. Dadurch sind alle maßgeblich Beteiligten idealerweise immer auf dem gleichen Stand

Tipp: Wer sich entsprechend über IT-Projekte informieren möchte, dem sei unser Beitrag „Die Phasen im Webprojekt“ empfohlen.

Projektphasen im klassischen Projektmanagement

Im klassischen Projektmanagement sind Projekte für gewöhnlich in fünf Phasen unterteilt, die auch als Projektlebenszyklus bezeichnet werden. Das Projekt ist hierbei in kleinere, leichter zu handhabende Phasen unterteilt, die die Planung, Überwachung und Steuerung des Projekts sowie die Zuweisung von Aufgaben an die Teammitglieder erleichtern. Zudem lassen sich durch die Gliederung in Projektphasen potenzielle Risiken und Probleme frühzeitig erkennen, um nötigenfalls umgehend gezielte Maßnahmen ergreifen und negative Auswirkungen auf das Projekt verhindern zu können.

Die fünf Projektphasen sind:

Initiierung: In der Projektphase Initiierungwird das Projekt konzipiert und das Projektziel festgelegt. Auch werden erste Anforderungen formuliert, die Stakeholder identifiziert und der Projektumfang definiert. Der Projektmanager erstellt zudem einen „groben“ Projektplan. Vor allem wird hier die Entscheidung getroffen, ob das Projekt durchgeführt wird oder nicht.

Planung: In der Projektphase Planungwird ein detaillierter Projektplan ausgearbeitet, der die Ziele, das Budget, die Ressourcen und den Zeitrahmen des Projekts festlegt.Ferner werden Aufgaben, Meilensteine und Deliverables festgelegt. Der Plan enthält eine Risikoanalyse, um mögliche Probleme oder Herausforderungen zu identifizieren und Maßnahmen ergreifen zu können.

Ausführung: In der Projektphase Ausführung werden die in der Planungsphase festgelegten Schritte umgesetzt, und die Teammitglieder arbeiten an den ihnen vom Projektmanager zugewiesenen Aufgaben, um die Meilensteine der jeweiligen Phase zu erreichen. Wichtig ist, dass das Team eng zusammenarbeitet und ausreichend kommuniziert.

Überwachung und Kontrolle: In der Projektphase Überwachung und Kontrollewird fortwährend der Projektfortschritt überprüft. Der Projektmanager behält dabei im Auge, ob die Erfüllung der einzelnen Aufgaben dem Zeitplan entspricht, das Budget eingehalten wird und die Qualität der Arbeit stimmt. Nötigenfalls greift er ein, um das Projekt wieder auf Kurs zu bringen.

Abschluss: In der Projektphase Abschlusswerden alle Deliverables daraufhin überprüft, ob sie den Anforderungen entsprechen und das Projektziel erreicht wurde. Das Produkt wird an den Auftraggeber übergeben. Ein Abschlussbericht dokumentiert die Ergebnisse und bewertet das Projekt, um aus den gewonnenen Erkenntnissen Lehren für die Zukunft ziehen zu können.

Ein solcher Phasenplan reduziert zwar die Komplexität eines Projekts, allerdings schränken „starre“ Phasen sowie die frühzeitige Festlegung von Meilensteinen die Flexibilität ein. So stößt klassisches Projektmanagement insbesondere dort schnell an seine Grenzen, wo sich die Anforderungen während des Projektverlaufs ändern. In Zeiten immer dynamischerer Märkte und höchst wandelbarer Zielgruppenerwartungen an Produkte ist eben dies heutzutage fast schon die Regel.

Hier bietet das agile Projektmanagement eine zeitgemäße Lösung an.

Projektphasen im agilen Projektmanagement …?

Im agilen Projektmanagement gibt es keine strikt vorgegebene Abfolge von Projektphasen wie im klassischen Projektmanagement. Stattdessen geht es iterativ vor und ermöglicht eine höhere Flexibilität und Anpassungsfähigkeit. Der Fokus liegt dabei auf der schnellen Umsetzung einzelner Arbeitspakete und der kontinuierlichen Verbesserung des Produkts via „Sprints“. Ein Sprint ist ein Zeitraum von ein bis vier Wochen, in dem ein bestimmtes Arbeitspaket umgesetzt und anschließend überprüft und gegebenenfalls angepasst wird.

Gleichwohl gibt es in agilen Projekten wiederkehrende Aktivitäten, die sich als „agile Projektphasen“ bezeichnen lassen und je nach Projekt und Methode variieren können. Hierzu zählen beispielsweise:

Vision: Auf Basis einer Produktvision wird ein vorläufiger Plan erstellt, um die Vision zu realisieren. Die Anforderungen werden erfasst, priorisiert und in ein Produkt-Backlog aufgenommen.

Sprint: Aus dem Produkt-Backlog wählt das Team diejenigen Aufgaben aus, die es in der jeweils zur Verfügung stehenden Zeitspanne realistischerweise erledigen kann, und arbeitet diese ab.

Review: Am Ende des Sprints diskutiert das Team, ob das anvisierte Teilziel erreicht wurde, tauscht sich über den Stand des Produkts aus und klärt die nächsten Entwicklungsschritte.

Retrospektive: Das Team prüft die Qualität des zurückliegenden Sprints und leitet aus den Erfahrungen potenzielle Verbesserungsmaßnahmen für den nächsten Sprint ab. Diese Phasen wiederholen sich Projektverlauf wieder und wieder. Auf diese Weise kann sichergestellt werden, dass das Team seine Arbeit und das Produkt fortwährend verbessert, flexibel auf externe Einflüsse reagiert und so „nach und nach“ die Anforderungen des Kunden erfüllt.

Anforderungsmanagement in jeder Phase des Projekts

Die Kundenanforderungen nach Abschluss des Projekts exakt erfüllt zu haben, gelingt umso besser, wenn in Projekten ein professionelles Anforderungsmanagement integriert ist – eine Kernkompetenz von blindwerk, Agentur für komplexe digitale Projekte mit ausschließlichem Fokus auf agiles Projektmanagement.

Das Anforderungsmanagement bzw. Requirements Engineering erstreckt sich dabei über den gesamten Projektlebenszyklus bzw. alle Phasen des Projekts und dient der fortwährenden Identifizierung, Analyse, Priorisierung und Verwaltung von Anforderungen. Insbesondere in agilen Projekten ist es unerlässlich für den Erfolg, weil es deren Anpassungsfähigkeit erhöht. Zudem beugt die kontinuierliche Überwachung, Überprüfung und Anpassung der Anforderungen an Änderungen der Projektumgebung oder der Stakeholder-Bedürfnisse Problemen im Projekt vor und hilft, Risiken und Kosten zu reduzieren und die Kundenzufriedenheit zu steigern.

Als Agentur für digitales Projektmanagement bringt blindwerk IT-Projekte für mittlere und große Unternehmen erfolgreich zum Abschluss. Dann vereinbaren Sie ein unverbindliches Chemistry Meeting mit uns!

Chemistry Meetings: Wider die leidige Pitch-Kultur! 

Pitches haben ihre Tücken und sind für Unternehmen äußerst zeit- und kostenintensiv. Und auch Agenturen sind oftmals nicht allzu wild drauf, da sie für relativ kleine Honorare meist Großes (vor)leisten müssen. Für beide Seiten sind Chemistry Meetings daher eine sinnvolle Alternative, da so in einem ersten Schritt vorgefühlt werden kann, ob man überhaupt fachlich und menschlich zueinander passt.

In diesem Artikel behandelte Themen

• Was bringt ein Chemistry Meeting Unternehmen und Agenturen?
• Viele Agenturen stehen nicht sonderlich auf Pitches
• Finden Unternehmen so überhaupt den Traumpartner?
• Das Chemistry Meeting dient primär dem Kennenlernen
• So ebnen Chemistry Meetings den Weg zum Projekterfolg

Ziel des Beitrags: Entscheider und Projektverantwortliche erfahren, welche Vorteile ein Chemistry Meeting gegenüber einem Pitch hat, und können so besser beurteilen, welcher Weg für sie der richtige ist.

Was bringt ein Chemistry Meeting Unternehmen und Agenturen?

In agilen Projekten kommt es noch mehr darauf an, dass die Chemie zwischen Kunde und Agentur stimmt. Denn gegenüber dem klassischen Projektmanagement ist das beauftragende Unternehmen hier sehr viel stärker in die Abläufe eingebunden.

Ein Beispiel: Bei der agilen Methode Scrum etwa fungiert oftmals ein entsprechend qualifizierter Mitarbeiter des Unternehmens als Product Owner. Damit ist er Teil des Scrum-Teams, übernimmt eine Vielzahl zentraler Aufgaben und stellt sicher, dass das spätere Produkt den Anforderungen sowohl seines Unternehmens als auch des Marktes genügt.

Aber auch abgesehen davon sind Kunden in agilen Projekten viel präsenter: Über den gesamten Projektverlauf hinweg intensiv am Prozess beteiligt, können sie per regelmäßigem Feedback immer wieder steuernd eingreifen. Bei Scrum ist das insbesondere durch die für gewöhnlich alle sieben oder vierzehn Tage stattfindenden Sprint Reviews möglich.

Wegen der engen, nicht selten mehrmonatigen oder gar mehrjährigen Zusammenarbeit muss es daher gerade im agilen Projektmanagement nicht nur fachlich zwischen Agentur und Auftraggeber passen. Sondern vor allem auch (zwischen)menschlich. Sonst ist schnell mal Sand im Getriebe, falls man sich nicht „versteht“ … was sich dann als äußerst schlecht für den Projekterfolg erweisen kann. 

Wenn sich Unternehmen also länger binden, wie beispielsweise bei der Entwicklung und Implementierung einer digitalen Strategie, tun sie gut daran, bei der Suche nach einer passenden Agentur nicht zwingend auf klassische Pitches zu setzen. Diese haben ihre Grenzen und Tücken. Als zielführende Alternative dazu bieten sich – in einem ersten Schritt – Chemistry Meetings mit ausgewählten Dienstleistern an. Nicht nur im Fall agiler Projekte!

Viele Agenturen stehen nicht sonderlich auf Pitches

Lassen Unternehmen bei mittleren oder großen Projektvorhaben mehrere Agenturen per Pitch gegeneinander antreten, so ist hiermit in der Regel ein hoher Zeit- und Kostenaufwand verbunden. Daran ändert sich auch dann nichts, wenn sie die Aufwandsentschädigung für die ins Rennen gehenden Agenturen möglichst gering halten. Schließlich binden sowohl Vorbereitung als auch Durchführung meist erhebliche personelle Ressourcen. Für die teilnehmenden Agenturen gilt das Gleiche.

Hinzu kommt, dass Agenturen nicht auf jeden Zug aufspringen, zumal es sich für sie erst dann richtig auszahlt, wenn sie am Ende tatsächlich den Zuschlag bekommen.

Dafür müssen sie jedoch in (konzeptionelle/kreative) Vorleistung gehen – was sich letztlich nur für den Gewinner lohnt. Denn in der Aufwandsentschädigung, sofern überhaupt eine vorgesehen ist, spiegelt sich der Wert der für den Pitch geleisteten Arbeit nur bedingt wider. Freundlich ausgedrückt.

Heißt gleichzeitig: Die Verlierer zahlen im Grunde genommen drauf. Der Anreiz ist alles in allem also eher überschaubar.

Finden Unternehmen so überhaupt den Traumpartner?

Vorteilhaft für Unternehmen ist dagegen, dass ihnen bei Pitches bereits potenziell verwertbare Ergebnisse präsentiert werden und sie grundsätzlich den Preis der nachfolgenden Leistung „kontrollieren“ können. Auch viele öffentliche Ausschreibungen zielen ja durch entsprechend festgezurrte Vergabekriterien von vornherein darauf ab, den jeweils günstigsten Projektpartner auszuwählen.

Dies hat jedoch zur Folge, dass sich manche Agenturen nicht sonderlich ins Zeug legen und stattdessen versuchen, mit einer „Lösung aus der Schublade“ durchzukommen. Wenn sie denn überhaupt mitpitchen. 

So laufen Unternehmen Gefahr, dass ihr neues Projekt gleich in zweierlei Hinsicht suboptimal startet: Zum einen ist die agenturseitige Vorleistung, auf der idealerweise alles Weitere basiert, nicht unbedingt das Nonplusultra – um zum anderen angeln sie sich auf diese Weise auch nicht unbedingt die am besten für das Gesamtvorhaben in Frage kommende Agentur. Beziehungsweise den erhofften Traumpartner. 

Mit Chemistry Meetings geht da vergleichsweise mehr. Weil sie niederschwelliger sind. Ein Widerspruch? Nein, wie sich im Folgenden zeigen wird. 

Das Chemistry Meeting dient primär dem Kennenlernen

Auch Agenturen haben ein gesteigertes Interesse an Projekten, die für beide Seiten stimmig sind. Etwa wenn es um zentrale Werte, die grundsätzliche Herangehensweise und die Qualität der Zusammenarbeit geht. Dazu gehört der kommunikative Austausch auf Augenhöhe ebenso wie ein Höchstmaß an angemessener Aufrichtigkeit. 

Wie gesagt, die Chemie muss stimmen. Dazu muss man sich aber zunächst einmal gegenseitig beschnuppern und kennenlernen können. Eben das leisten Chemistry Meetings binnen weniger Stunden.

Klar ist damit: Vor allem bei längerfristigen Projekten kommt es auf eine größtmögliche Schnittmenge zwischen der Unternehmenskultur des Kunden und dem Selbstverständnis der Agentur an. Umso besser klappt später die (agile) Projektarbeit aller Beteiligten! 

Zudem ist es für Agenturen fundamental wichtig, sich bereits im allerersten Schritt ein Bild davon machen zu können, welchen Stellenwert das Unternehmen professionellem Projektmanagement beimisst. Und ob in dieser Hinsicht überhaupt schon „gut geölte“ Andockpunkte vorhanden sind. Nicht minder wichtig: Ist man auch die fachlichen Herausforderungen betreffend auf einer Wellenlänge?

Insofern kommen Chemistry Meetings ohne konkrete Aufgabenstellungen wie beispielsweise den grafischen Erstentwurf für den Relaunch einer Firmenwebsite aus. Das ist nicht ihr Ziel.

So ebnen Chemistry Meetings den Weg zum Projekterfolg

Bedeutet: Während aufgabengetriebene Pitches von jetzt auf gleich in die Vollen gehen, um eine nach Maßgabe der jeweiligen Vergabekriterien „geeignete“ Agentur herauszufiltern, erlaubt ein Chemistry Meeting zunächst einmal ein gegenseitiges Kennenlernen, bei dem es zuvorderst um Soft Facts geht. Ohne dabei Hard Facts wie die beiderseitige Expertise sowie die Problemlösungskompetenz der Agentur komplett auszublenden. Letzteres lässt sich etwa in Form eines integrierten Mini-Workshops o. ä. zu einer spezifischen Fragestellung aus dem Kontext des geplanten Projekts abbilden.

Damit führen Chemistry Meetings zwar nicht sogleich zu elaborierten Konzepten, sagen dafür aber schon viel über die Art und Weise des Miteinanders im Projekt aus. Zudem entfällt somit die vorgelagerte Ausarbeitung einer dezidierten, anschlussfähigen Agenturaufgabe nebst Briefing. Sowie die nicht minder aufwändige Evaluierung der Ergebnisse.

Kurzum, Chemistry Meetings sind bei Weitem nicht so zeit- und kostenintensiv. Vielmehr ermöglichen sie es Unternehmen, relativ schnell den menschlich wie fachlich am besten passenden Projektpartner zu identifizieren und mit diesem anschließend einen Probeauftrag oder ein Vorprojekt als Reality-Check durchzuführen. Somit minimieren sie das Risiko einer späteren Bauchlandung und weisen Unternehmen den richtigen Weg zum Projekterfolg. 

Sie haben ein neues digitales Projekt in der Pipeline und suchen eine erfahrene Projektmanagement-Agentur mit entsprechender Expertise? Dann vereinbaren Sie ein unverbindliches Chemistry Meeting mit uns!

Einführung Requirements Engineering und Projektmanagement

Das Management von Anforderungen bzw. Requirements Engineerings sollte immer integraler Bestandteil von (agilem) Projektmanagement sein. Denn es schützt Projekte davor, plötzlich in Schieflage zu geraten. Etwa indem sich bestimmte Vorgaben des Kunden später als nicht realisierbar erweisen. Daher muss jede einzelne Anforderung zuvor auf Herz und Nieren geprüft werden. Dies hilft, Risiken zu minimieren, Kosten zu senken und den Zeitplan einzuhalten. 

In diesem Artikel behandelte Themen

• Was ist Requirements Engineering und warum ist es im Projektmanagement so wichtig?
• Worin bestehen die Ziele von Requirements Engineering?
• Warum ist Requirements Engineering wichtig?
• Was versteht man unter einer Anforderung?
• Erhebung, Analyse, Dokumentation und Management
• Aufgaben eines Requirements Engineers
• Anforderungen auf dem Prüfstand: Qualitätskriterien
• Arten der Anforderung: Funktional vs. nicht-funktional
• Anforderung richtig formulieren: Lösung nicht vorwegnehmen
• Fazit: Besser auf Anforderungsmanagement setzen!

Ziel des Beitrags: Projektverantwortliche erfahren, was Requirements Engineering ist und wie sie Anforderungen richtig einordnen, Streitigkeiten im Projekt vermeiden und Risiken minimieren. 

Was ist Requirements Engineering und warum ist es im Projektmanagement so wichtig?

Sicherlich haben Sie es schon bemerkt: Sowohl in der deutschen als auch in der englischen Übersetzung geht es um Anforderungen (Requirements). Dass diese in komplexen Projekten irgendwie “gemanagt” werden müssen, ist noch unmittelbar einleuchtend. Aber “Engineering”?

Tatsächlich ist das Anforderungsmanagement ein wichtiger Bestandteil bei der Entwicklung und Konstruktion von Maschinen, Software und anderen Produkten. Nicht selten werden im Maschinenbau deshalb auch Ingenieure für das Requirements Engineering eingesetzt. Und in der Software- oder Web-Entwicklung greifen wir entsprechend auf Experten zurück – hier ist es Bestandteil von Software Engineering. Es geht also um deutlich mehr als nur um Projektmanagement: Fachliche Expertise ist unabdingbar!

Grob gesprochen umfasst Requirements Engineering alle Methoden und Maßnahmen, um Problemen im Projekt vorzubeugen. Während Testing die eine, nachgelagerte Seite der Medaille ist, zeigt das Anforderungsmanagement die andere, vorgelagerte Seite.

In diesem Zusammenhang vielleicht ebenfalls interessant für Sie: “Wie bereite ich ein digitales Projekt perfekt vor?”

Worin bestehen die Ziele von Requirements Engineering?

Häufig werden Vorgaben durch den Auftraggeber kommuniziert und einfach umgesetzt. Geprüft wird vielfach nur, ob sie richtig verstanden wurden und was ihre Realisierung kostet. Unberücksichtigt bleibt oft, inwieweit sie sinnvoll sind, ob es einfacher und vielleicht kostengünstiger geht. Denn der Kunde ist schließlich König! So beginnen oftmals Projekte, die ohne Anforderungsmanagement auskommen (müssen). 

Wer sich stattdessen frühzeitig um das Erheben und Managen seiner Anforderungen kümmert, verfolgt die folgenden Ziele:

• Kosten während der Realisierung senken
• Wartungskosten und andere langfristige Kosten senken
• Zeitliche Vorgaben einhalten
• Risiken senken
• Qualität des Produkts sichern
• Vorgaben einhalten

Gerade das frühzeitige Kümmern um Anforderungen ist also wichtig, um die genannten Ziele zu erreichen. Wie groß die Vorteile durch Requirements Engineering sind, lässt sich gut an der sogenannten “Rule of Ten” veranschaulichen. 

Warum ist Requirements Engineering wichtig?

Die “Rule of Ten” besagt, dass Fehler möglichst früh erkannt und behoben werden sollten: Denn bei jeder Produktionsstufe verzehnfachen sich die Folgekosten, um einen Fehler zu beheben. Fehler, die also bereits vor der Entwicklung des Projekts oder einzelner Komponenten erkannt werden, reduzieren die Kosten während der gesamten Projektlaufzeit (s. Projektlebenszyklus) drastisch. Und gerade das Vorbeugen von Fehlern ist die Domäne von Requirements Engineering!

Beispiele für Rule of Ten

• Rückrufaktion von Produkten
• Hohe Abbruchrate im Online-Shop
• Ausnutzung einer Schwachstelle in einer Software (Hacker-Angriff)
• Höhere Projekteffizienz
• Weniger Change Requests im Projektverlauf
• Verlagerung von Fehlern in das Vorprodukt
• Frühes Erkennen von Problemen
• Geringere Projektkosten, da Folgekosten aus Fehlern vermieden werden
• Projektabschluss „in time and budget”
• Höhere Kundenzufriedenheit
• Weniger Imageschäden
• Zielorienter Abschluss

Hat man einen Fehler also einmal “verbaut”, kann es äußerst schwierig sein, ihn zu reparieren. Ein mangelhaftes Requirements Engineering kann so äußerst unangenehm werden. Doch manchmal sind die Ergebnisse auch zum Schmunzeln:

Das sogenannte UX Designer Paradox hingegen zeigt, dass mangelhaftes Anforderungsmanagement auch dazu führen kann, dass ein vermeintlich innovatives Produkt leider überhaupt nicht zu den formulierten “Musts” des Endkunden passt. Bevor Sie also teure Features in Ihr Produkt einbauen, lohnt sich ein genauer Blick auf die Anforderungen Ihrer Zielgruppe. Auftraggeber, Designer und auch Entwickler realisieren zu oft Funktionen, die ihren eigenen Wünschen und Vorlieben entsprechen. Requirements Engineering hilft Ihnen dabei, diese Fehlentwicklungen zu vermeiden. 

Kurzum: Offensichtlich gibt es also Anforderungen, die eher nicht so gut sind! Und das, obwohl die Projektbeteiligten von ihnen überzeugt waren. Persönliche Vorlieben sind anscheinend völlig ungeeignet, um eine Anforderung bewerten zu können.

Was versteht man unter einer Anforderung?

Schon dem Wort nach ist eine Anforderung etwas, das “angefordert” wird. Sie ist somit üblicherweise ausdrücklich verlangt, erbeten und muss daher in jedem Fall kommuniziert werden. Da sie wortwörtlich “gefordert” wird, handelt es sich um eine benötigte Eigenschaft. Entsprechende Vorgaben können unter anderem von Auftraggebern, Behörden, dem Gesetzgeber, Mitarbeitern oder Endkunden gestellt werden:  

• Dritte: Was muss das System aus formaler, rechtlicher oder vertraglicher Sicht erfüllen (z. B. Gesetze, Normen, Spezifikationen)? 
• Auftraggeber: Welche internen Abläufe, innerbetrieblichen Prozesse, Anforderungen von Mitarbeitern, Dokumentationspflichten etc. sind zu berücksichtigen?
• Auftragnehmer: Wie muss der Kunde dem Projektteam zuarbeiten, damit das Projekt erfolgreich verlaufen kann?
• Endkunden: Was genau braucht der Endkunde, um sein Problem zu lösen oder ein bestimmtes Ziel zu erreichen (z. B. Bedienbarkeit, Endgeräte, Erlebnis)?

Wer aber bestimmt, was gefordert wird, was für Ihr Projekt wichtig ist? Und wie entscheiden Sie, wenn unterschiedliche Auffassungen darüber, was wichtig ist, zu Streitigkeiten führen? Gerade hier setzt Anforderungsmanagement an. 

Erhebung, Analyse, Dokumentation und Management

Kunden sind keine IT-Experten. Gewisse Zusammenhänge können diese verständlicherweise weder kennen noch verstehen. Also formulieren Kunden ihre Anforderungen oft unvollständig, unstrukturiert, fehlerhaft, nicht immer verständlich und teilweise sogar widersprüchlich. Gleichzeitig erwarten sie, dass der IT-Dienstleister alles verstanden hat, jeden Punkt genau prüft, Risiken abwägt und das gewünschte Software-Produkt gemäß den Vorgaben realisiert. 

Hier kommt das Requirements Engineering ins Spiel, das im Grunde wie folgt abläuft:

• Anforderungen erheben: Was muss das Produkt aus Sicht des Auftraggebers, des Endkunden etc. erfüllen oder leisten?
• Anforderungen transformieren: Wie lassen sich diese unstrukturierten Informationen in eine Form bringen, die verständlich und strukturiert ist (klassischerweise in Form eines Lastenhefts)?
• Systemanforderungen erstellen: Inwieweit ist das Projekt mit diesen Anforderungen unter Berücksichtigung zugrunde gelegter qualitativer Merkmale und Restriktionen realisierbar?  

Anforderungsmanagement besteht im Grunde also darin, implizite Anforderungen explizit zu formulieren. Ein Anforderungsmanager stellt somit sicher, dass diese unter anderem vollständig, korrekt, verständlich und realisierbar sind. Dazu kümmert er sich um deren Erhebung, Analyse, Dokumentation und Management.

Agiles Projektmanagement und Requirements Engineering (ARE) 

In agilen Projekten findet Anforderungsmanagement im Grunde die ganze Zeit über statt. Anforderungen werden für jedes Feature ermittelt, etwa in “User Stories” (so nennt man im Projektmanagement allgemeine Beschreibungen beispielsweise von Software-Features).

Auch hier geht es darum, eine Anforderung zu erheben (hier des Website-Besuchers), ohne etwa eine konkrete technische Lösung vorwegzunehmen (vgl. unten) – und zwar in der Sprache des Kunden.

Die wohl wichtigste Frage- oder Problemstellung im Requirements Engineering lautet damit: Wie ermitteln wir jede einzelne relevante Anforderung für das Projekt, falls/wenn der Auftraggeber nicht in der Lage dazu ist, sie zu kommunizieren?

Aufgaben eines Requirements Engineers 

Im Grunde enthält jedes durchdachte Projektmanagement bereits ein Anforderungsmanagement. In agilen Projekten findet etwa eine Priorisierung durch den sogenannten Product Owner statt. Das ist die Person, die die Aufgabenliste verwaltet und die Priorisierung vornimmt.

Was kann ich tun, wenn mich die Masse an Anforderungen erschlägt?

• Priorisieren: Wichtige Aufgaben werden nach oben priorisiert, weniger wichtige nach unten. So werden alle notwendigen Punkte zuerst abgearbeitet, weniger wichtigere nach hinten verschoben.
• Sprints: Um den Überblick nicht zu verlieren, wird nicht alles auf einmal abgearbeitet. Das Projekt wird in kleinere Pakete aufgeteilt, die nach und nach in sogenannten Sprints realisiert werden.
• Eliminieren: Vielfach werden in Projekten Dinge realisiert, die – wenn man mal ehrlich ist – niemand braucht. In einer bereits priorisierten Liste aller Anforderungen sollten jene mit geringer Priorität auf den Prüfstand gestellt werden.
• Verfallsdatum: Wenn manches davon auch nach Monaten oder gar Jahren nicht umgesetzt wurde, das Projekt vielleicht sogar längst online gegangen ist, lohnt es sich, über ein Verfallsdatum nachzudenken. Ist etwas zum Beispiel älter 12 Monate, wandert es ins Archiv.
• Qualitätskriterien: Legen Sie Kriterien für Anforderungen fest! Dann wird Ihre Anforderungsliste stets aufgeräumt(er) sein. Die Priorisierung fällt Ihnen leichter, bestimmte Dinge können ohne Streit eliminiert werden. Welche Qualitätskriterien sinnvoll sind, diskutieren wir weiter unten.

Je mehr eine solche Person zum fachlichen Gehirn im Erstellen, Verwalten und Analysieren von Vorgaben wird, unter anderem die Dokumentation vornimmt und Beziehungen zwischen Anforderungen herstellt, desto mehr wird er zum Requirements Engineer. Weg vom reinen Projektmanagement, hin zum fachlich versierten, dokumenten- oder datenbankbasierten Anforderungsmanagement: So lässt sich eine Abgrenzung zu Projektmanagern vornehmen, wobei die Grenze durchaus fließend ist.

Anforderungen auf dem Prüfstand: Qualitätskriterien

Jedes komplexere Projekt kennt sie: Diskussionen darüber, inwieweit eine bestimmte Anforderung Sinn ergibt, überzogen, zu teuer oder schlicht nicht realisierbar ist. Oft prallen ganz unterschiedliche Meinungen und Sichtweisen aufeinander, und ausgetauscht werden dann mal mehr, mal weniger gute Begründungen. Am Ende setzt sich nicht selten derjenige durch, der den längeren Atem, das Budget oder eben “das Sagen” hat – oft mit fatalen Konsequenzen für den Projekterfolg!

Anforderungen, die bei Einhaltung von Qualitätskriterien so keine Chance auf eine Berücksichtigung im Projekt hätten, führen dazu, dass beispielsweise ein Webprojekt 

• zu teuer wird,
• zeitintensiv ist,
• geringeren Mehrwert bietet,
• schlechte Usability zeigt,
• unnötig komplex gerät und 
• widersprüchliche Ziele verfolgt.

Hinzu kommt, dass so manche Anforderung nicht wirklich objektiv ist. Was zu Problemen führen kann!

Qualitätskriterien helfen dabei, sich gegen sinnlose oder überzogene Forderungen durchzusetzen

Qualitätskriterien helfen dabei, endlose Diskussionen und Auseinandersetzungen zu vermeiden. Formulieren Sie mit allen Beteiligten klare Kriterien, die für jede Anforderung erfüllt sein müssen. Welche Qualitätskriterien Sie tatsächlich brauchen, kann stark von Ihrem Projekt abhängen.

Ausführlich beschrieben und erklärt wird all dies (und vieles mehr) in dem aktuellen Fachbuch “Basiswissen Requirements Engineering” von Klaus Pohl und Chris Rupp.

Häufig spielen die folgenden Kriterien eine wichtige Rolle:

• Realisierbar: Anforderungen müssen in dem gesetzten zeitlichen Rahmen und mit den vorhandenen Ressourcen technisch und finanziell machbar sein.
• Adäquat: Die Lösung muss zum Kunden bzw. Endkunden passen (s. “The UX Designer Paradox”).
• Konsistent: Eine Anforderung darf nicht im Widerspruch zu einer anderen stehen. Wenn beispielsweise die Ladezeit einer Website überdurchschnittlich gut sein soll, kann keine Anforderung realisiert werden, die dem zuwiderläuft, etwa durch das übermäßige Einbinden von Skripten durch Drittanbieter, um möglichst vielfältige Funktionen zur Verfügung zu stellen. 
• Vollständig: Anforderungen sollten vollständig beschrieben werden, so dass wichtige Funktionen oder Aspekte nicht weggelassen werden. 
• Verständlich: Wichtig ist natürlich auch, dass die Beschreibung jeder Anforderung für alle Beteiligten (etwa Stakeholder) verständlich ist. 
• Eindeutig: Eine Anforderung sollte auf keinen Fall falsch oder anders verstanden werden können. Sie muss also eindeutig sein!
• Prüfbar: Jede Anforderung muss überprüfbar und nachverfolgbar sein, da wir nur so wissen können, ob wir sie letztlich erfüllt haben und inwieweit sie zum Erreichen des Projektziels beiträgt.
• Notwendig: Welche Anforderungen sind in dem geltenden Systemkontext wirklich notwendig?  
• Abgestimmt: Zu guter Letzt sollte selbstverständlich mit allen Beteiligten (insbesondere mit den Stakeholdern) abgestimmt werden, ob jede einzelne Anforderung so korrekt ist und umgesetzt werden soll.

Bevor Sie Ihre Anforderungen anhand von Qualitätskriterien erheben und schließlich formulieren, sollten Sie zwischen funktionalen und nicht-funktionalen unterscheiden. Dies hilft Ihnen beispielsweise dabei, nicht etwa Funktion und Design zu vermengen, sondern daraus unterschiedliche Anforderungen zu generieren.

Arten der Anforderung: funktional vs. nicht-funktional 

Gemeinhin beschreiben Auftraggeber, WAS eine Software tun soll. Zumindest liegt der Schwerpunkt oft auf diesen funktionalen Aspekten. Weil das häufig aber nicht ausreicht, um jede Anforderung zu berücksichtigen, braucht es auch nicht-funktionale Anforderungen. Mit diesen wird darüber hinaus gefordert, WIE oder WIE GUT das System eine Aufgabe erfüllen soll (etwa Zeitverhalten, Zuverlässigkeit, Wartbarkeit, Sicherheit, Aussehen, Usability, Leistung und Effizienz) – also Qualitätsanforderungen. 

• Beispiel für eine funktionale Anforderung: Das Shop-System soll den Checkout in einem Schritt durchführen (sog. One-Page-Checkout). 
• Beispiel für eine nicht-funktionale Anforderung: Der Checkout soll alle für den Kaufabschluss benötigten Buttons im sichtbaren Bereich zeigen (“Above the fold” ). 

Nicht-funktional sind neben den Qualitätsanforderungen in der Regel auch die Randbedingungen (Constraints). Eine Randbedingung könnte zum Beispiel darin bestehen, dass ein Projekt mit dem Content-Management-System TYPO3, einem PHP-Framework wie Laravel oder nach einem bestimmten Standard realisiert werden soll. Neben solchen technischen bzw. normativen Constraints können etwa auch kulturelle oder spezifische Vorgaben des Auftraggebers einschränkend wirken. 

Die Anforderung richtig formulieren: Lösung nicht vorwegnehmen!

Anforderungen beschreiben nicht, wie etwas realisiert werden soll (auf welche Art und Weise, mit welcher Technologie o. ä.). Demgegenüber sollen Entwickler entscheiden können, mit welcher Lösung sie die Anforderung erfüllen. Dabei nehmen sie die Nutzerperspektive ein, in der agilen Entwicklung etwa in Form von User Stories. Damit sollen praktikable, aber auch neue, innovative Lösungen gefördert werden. Die Anforderung soll nicht die Lösung vorwegnehmen, da so meist nur althergebrachte Ergebnisse gefördert werden.

Fazit: Besser auf Anforderungsmanagement setzen!

Requirements Engineering im Projektmanagement bedeutet, sich mit Anforderungen systematisch zu beschäftigen – und das möglichst frühzeitig, da sonst die Kosten in späteren Projektphasen überproportional steigen können (s. “Rule of Ten”). In sehr komplexen oder besonders komplizierten Projekten gleichen die Anforderungen einem Bau- oder Konstruktionsplan, da Abhängigkeiten zwischen diesen erstellt, verfeinert und durch Änderungen aktualisiert werden. Dann kann es auch sinnvoll sein, ein datenbankbasiertes Requirements Engineering zu nutzen, um Aktualisierungen automatisch an der einen Stelle vornehmen zu können, wenn sich an einer anderen Stelle eine Anforderung ändert. 

Qualitätskriterien sind besonders wichtig, weil eine Anforderung nicht durch subjektives Empfinden bewertet werden sollte, sondern durch objektive, unter allen Beteiligten geteilte Maßstäbe. Und es ist wichtig, sie richtig einzuordnen: Betrifft eine Anforderung eine Funktion oder geht es eher um einen reinen Design-Aspekt?

Obwohl sich der Requirements Engineer viel mit Dokumentation und Analyse beschäftigt, sollte er kommunikationsstark sein. Denn er muss die Wünsche aller Stakeholder unter einen Hut bringen und dem Entwicklungsteam kommunizieren. Er behält das Ziel im Blick, ein Produkt zu entwickeln, das die gesetzten Anforderungen erfüllt, unter Minimierung von Kosten und Risiken.

Bei blindwerk setzen wir konsequent auf professionelles Anforderungsmanagement und führen die digitalen Projekte unserer Kunden so zum Erfolg. Vereinbaren Sie gerne ein unverbindliches Erstgespräch mit uns, um mehr über unsere Arbeitsweise zu erfahren!

Wann ist ein Projekt ein Projekt?

In der Alltagssprache verwässert die Grenze zwischen „Projekt“ und „Prozess“ zusehends. Per Definition sind Komplexität, Einmaligkeit und Neuartigkeit hier einige der zentralen Kriterien. Im Folgenden erfahren Sie, worin die weiteren Unterschiede bestehen – und warum es für Ihr Unternehmen oder Ihre Organisation wichtig ist, genau zu differenzieren und das gesamte Vorhaben nicht mit punktuellen Aufgaben zu verwechseln. Mit besonderem Fokus auf agiles Projektmanagement.

In diesem Artikel behandelte Themen

• Was ist ein Projekt? Definition und inhaltliche Abgrenzung
• Projekt vs. Prozess: Exkurs anhand eines drängenden Beispiels
• Sind Routineprojekte mit starren Strukturen noch zeitgemäß?
• Modernes Projektmanagement: Eine Frage des Mindsets!

Ziel des Beitrags: Im Projektmanagement noch unerfahrene Entscheider in Unternehmen sowie interessierte Laien erfahren, welche Kriterien für Projekte maßgeblich sind – und was nicht dazu zählt.

Was ist ein Projekt? Definition und inhaltliche Abgrenzung

Die DIN 69901 beschreibt Grundlagen, Prozesse, Prozessmodelle, Methoden, Daten, Datenmodelle und Begriffe im Projektmanagement. Danach ist ein Projekt definiert als ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist.

Zu den zentralen Kriterien gehören aus unserer Sicht:

• Zielvorgabe
• Plan/Vision
• Ressourcen
• Einmaligkeit
• Komplexität
• Neuartigkeit
• Projektorganisation

Die Betrachtung als Vorhaben ermöglicht es, Projekte von einzelnen Aufgaben zu unterscheiden. So etwa von Routine-, Linien- und Prozessaufgaben, die einem immer wieder reproduzierbaren Ablauf folgen. Dazu weiter unten mehr. Ein Vorhaben hingegen, insbesondere wenn es komplex ist und unter Einsatz zeitlicher, finanzieller und personeller Ressourcen auf die Entwicklung von etwas Neuartigem abzielt, das nicht in Einzelarbeit realisiert werden kann, bedarf einer Projektorganisation. Im eigentlichen Projektmanagement gilt es dann, zunächst einen mehr oder minder einzigartigen Lösungsweg zu ermitteln und diesen Schritt für Schritt umsetzen zu lassen.

Das klassische Projektmanagement sieht dafür einen unter anderem für die Erstellung des Projektplans zuständigen Projektleiter und ein Projektteam vor, während beispielsweise die Zusammenarbeit in agilen Projekten nach der Scrum-Methode einen Scrum Master, einen Product Owner sowie ein Entwicklungsteam umfasst.

In diesem Beitrag bringen wir ein wenig Licht ins Dunkel, liefern ein einleuchtendes Beispiel und gehen darauf ein, warum agiles Projektmanagement möglicherweise auch für Sie das Gebot der Stunde ist.

Projekt vs. Prozess: Exkurs anhand eines drängenden Beispiels

Ein gutes Beispiel für ein Projekt ist die Entwicklung und Implementierung einer Digitalstrategie im Unternehmen – gerade weil die Digitalisierung derzeit die wohl größte Aufgabe für die deutsche Wirtschaft darstellt. Ohne Projektorganisation und Projektmanagement ist dieses komplexe Vorhaben von vornherein zum Scheitern verurteilt – nämlich genau dann, wenn Unternehmen versuchen, es vorrangig über bereits etablierte Prozesse abzubilden.

Denn diese wiederholen im Grunde genommen ein und dieselben Aufgaben bzw. Vorgänge, führen zu ein und denselben Ergebnissen und werden via Prozessmanagement [sic!] lediglich immer weiter optimiert. Darum geht es bei einem Projekt aber nicht. Vielmehr sind Projekte bis auf Weiteres einmalig, werden durch Meilensteine in Phasen unterteilt und sollen in einem definierten Zeitrahmen etwas Neues oder Innovatives hervorbringen – sei es ein Produkt, ein Produktfeature oder eben eine Digitalstrategie (s. o.). Klar, wenn man einen völlig neuen Zielort erreichen möchte, ruft man im Navigationssystem ja auch nicht alte Routenbeschreibungen ab und probiert ad hoc ein paar Abkürzungen aus.

Projekte erfordern also eine völlig andere Herangehensweise als etwa das operative Online-Marketing, das einen eher prozessualen Charakter hat. Im Falle der „digitalen Nachzügler“ in unserem obigen Beispiel ist somit auch das für Projekte konstitutive Merkmal der Neuartigkeit erfüllt. Und nur der Vollständigkeit halber: Zwar können zum Vorhaben passende Prozesse ein Projekt vorantreiben, indem sie Teilaufgaben übernehmen. Jedoch sind sie niemals Projekte an sich. Ihnen fehlt die Einmaligkeit, Komplexität, zeitliche Komponente und anderes mehr. Im allgemeinen Sprachgebrauch geht diese alles entscheidende Differenzierung zwischen Projekt und Prozess jedoch oftmals ein wenig unter.

Sind Routineprojekte mit starren Strukturen noch zeitgemäß?

Doch was ist mit Vorhaben, die zwar komplex, aber nicht neuartig sind? Die gibt es schließlich auch. Klar ist: Solche „Routineprojekte“ sind bis zu einem gewissen Grad standardisierbar. Etwa wenn es um praxisbewährte Produktentwicklungsprojekte geht. Allerdings bergen standardisierte und somit „von Natur aus“ lineare Projektabläufe wegen des zunehmenden Innovationsdrucks im Markt stets die Gefahr, den Anschluss an aktuelle Entwicklungen zu verlieren.

Heißt: Da sie auf klassisches Projektmanagement setzen, sind Routineprojekte im Vergleich zu agilen Ansätzen nicht anpassungsfähig genug und ermutigen schon mal gar nicht zu Experimenten. Insofern mündet ein „eingestaubtes“ Vorgehen nicht selten in suboptimalen Ergebnissen. Denn was nützt es einem Unternehmen oder einer Organisation, einerseits die Projektkosten gesenkt zu haben, wenn das Produkt andererseits an den zwischenzeitlich gewandelten Anforderungen im jeweiligen Marktsegment vorbei entwickelt wurde und folgerichtig keine Nutzer bzw. Abnehmer findet? Dann wurden letztlich nur wichtige zeitliche, finanzielle und personelle Ressourcen verschwendet.

Unternehmen oder Organisationen, die auf standardisierte Projektabläufe setzen, sind daher gut beraten, diese regelmäßig auf den Prüfstand zu stellen. Oder gleich auf agiles Projektmanagement umzuswitchen. Zumal die heutzutage immer kapriziöseren Markt- bzw. Kundenanforderungen ein erhöhtes Maß an Flexibilität erfordern. Für Vorhaben, in deren DNA keinerlei Möglichkeit zur Anpassung und Neuartigkeit eingeschrieben ist, wird die Luft also immer dünner.

Viele Projekte, die in Unternehmen durchgeführt werden, lassen sich ohnehin nicht vollständig standardisieren. Das ist seit jeher so, da selbst vermeintliche Routineprojekte unabhängig von ihrer Komplexität immer auch neuartige Elemente enthalten können. Doch ohne Blick dafür verkommen Projektvorhaben im hier verstandenen Sinne schnell zu starren Prozessen, die zwar ihre Aufgabe erfüllen, am Ende aber doch nur Ressourcen verbrennen, ohne jemals ins anvisierte Ziel zu kommen. Wirklich Neues entsteht so nicht.

Modernes Projektmanagement: Eine Frage des Mindsets!

Mit all dem tun sich große, hierarchische und eher traditionell aufgestellte Unternehmen und Organisationen bekanntermaßen schwer: Die erste Hürde war vor einigen Jahrzehnten die Umstellung auf eine konsequente Projektorganisation – jetzt ist es der Schwenk von klassischem Projektmanagement hin zu agilem Projektmanagement. Auch weil Agilität ein völlig neues Mindset voraussetzt und einen erheblichen strukturellen Umbau im Unternehmen nach sich zieht.

Unstrittig ist jedoch, dass eine besser an die Markterfordernisse angepasste Organisation des Projekts mit agilen Teams als kleinen, beweglichen „Organisationseinheiten auf Zeit“ innerhalb der großen, vormals streng hierarchischen Organisation in der Regel bessere Ergebnisse erzielt. So ist in agilen Projekten (idealerweise) vieles anders: Es gibt keine in Stein gemeißelte Arbeitsteilung und keine festen Rollen, und statt einer strikten Hackordnung wird in modernen Projekten zumeist auf Augenhöhe zusammengearbeitet. Das Entwicklungsteam organisiert sich dabei vorzugsweise selbst und arbeitet während der Sprints bei Scrum weitgehend autark. Außerdem ist die Kommunikation innerhalb des Projektteams und nach außen möglichst offen.

Nur dann und nur dann führen agile Projekte gegenüber klassischen Projekten vermehrt zum Erfolg. Vorausgesetzt natürlich, die Strukturen im Projekt sind für alle Beteiligten durchweg sinnstiftend und bleiben flexibel, ohne plötzlich infolge von Über-Organisation zu erstarren. Blinder Gehorsam hinsichtlich einer wie auch immer von oben diktierten „richtigen Arbeitsweise“ ist hier tödlich und widerspricht dem agilen Gedanken.

An den oben genannten Kriterien bzw. der Definition für Projekte ändert dies selbstverständlich nichts. Denn nur dann ist ein Projekt ein Projekt.

Ihr Ziel ist unser Ziel! Als Agentur für komplexes Projektmanagement realisiert blindwerk seit vielen Jahren erfolgreiche Digital-Projekte für mittlere und große Unternehmen.
Jetzt Kontakt aufnehmen

Was ist der Projektlebenszyklus?

Jedes Projekt durchläuft mehrere maßgebliche Phasen. Zusammen machen diese den Projektlebenszyklus aus. In diesem Beitrag erklären wir, welche Projektphasen das im Einzelnen sind, wodurch sie sich auszeichnen und warum sie im Projektmanagement unverzichtbar sind. So können Unternehmen nicht zuletzt die Kosten besser im Blick behalten – und in den Griff bekommen.

In diesem Artikel behandelte Themen

• Projektmanagement: Die vier Phasen des Projektlebenszyklus
• Jedes Projekt hat (letztlich) einen individuellen Lebensweg
• Die Phasen des Projektlebenszyklus im Einzelnen

Ziel des Beitrags: Entscheider in Unternehmen und Projektverantwortliche (in spe) erfahren, welchen Beitrag die Einhaltung des Projektlebenszyklus zum Gelingen von Projekten leistet.

Projektmanagement: Die vier Phasen des Projektlebenszyklus

Der Projektlebenszyklus ist der „Lebensweg“ eines Projekts von dessen Start bis zu dessen Ende und umfasst klassischerweise vier Phasen: Initiierung, Planung, Durchführung und Abschluss. Als eines der zentralen Verfahren im Projektmanagement wird dadurch sichergestellt, dass sich ein Projekt zielgerichtet, effizient und konsistent ausführen lässt. Sowohl hinsichtlich des Aufwands (Zeit und Kosten) als auch hinsichtlich der Qualität des Produkts bzw. Ergebnisses.

„Verfahren“ klingt hier jedoch insofern etwas hochgestochen, als der Projektlebenszyklus im Grunde genommen nur die immergleiche chronologische Abfolge aufeinander aufbauender Schritte bzw. Projektphasen ist, ohne die klassische oder agile Projekte nicht erfolgreich durchführbar sind. Sprich: Zwar überlappen sich die einzelnen Phasen bisweilen ein wenig – aber ihre Reihenfolge bleibt stets dieselbe. An deren Ende steht immer ein größerer Meilenstein.

Insbesondere bei der Entwicklung innovativer Produkte kommt neben einer Machbarkeitsstudie oftmals eine Vorentwicklungsphase sowie eine Pilotphase hinzu. Ferner gibt es nicht die eine allgemeingütige Definition von Projektlebenszyklus, sondern leicht voneinander abweichende Definitionen. Deren Nuancen sind an dieser Stelle jedoch zu vernachlässigen. Vielmehr erfahren Sie, wodurch sich im Projektmanagement die vier zentralen Phasen des Projektlebenszyklus im Kern auszeichnen.

Jedes Projekt hat (letztlich) einen individuellen Lebensweg

Der Projektlebenszyklus ist neben dem Projektstrukturplan als hierarchischer Darstellung sämtlicher Aufgaben innerhalb eines Projekts also entscheidend für dessen Erfolg. Denn beides trägt maßgeblich dazu bei, dass Projekte sowohl über eine Grob- als auch über eine Feinstruktur verfügen. Dies ist vor allem beim Management komplexer Projekte unabdingbar: Ohne Unterteilung in klar voneinander abgegrenzte Phasen, Unterphasen und Arbeitspakete würden Projektleiter, Team und Stakeholder schnell den Überblick verlieren.

Innerhalb dieses strukturellen Gefüges wird unter anderem festgelegt:

• Wer erstellt in den Projektphasen was und wann?
• Was davon sind wegweisende Meilensteine?
• Wie wird das Projekt gesteuert und überprüft?
• Welche Kriterien sind bei der Qualitätskontrolle zu beachten?
• Wann gilt eine Projektphase als abgeschlossen?
• Wann gilt das Projekt insgesamt als abgeschlossen?

Wichtig: Da Projekte in aller Regel einmalig und einzigartig sind und sich dahingehend von sich kontinuierlich wiederholenden Prozessen unterscheiden, sind diese Fragen immer wieder aufs Neue zu beantworten. So gesehen hat jedes Projekt letzten Endes einen individuellen Lebensweg.

Mehr über die Charakteristika von Projekten erfahren Sie in unserem Beitrag „Wann ist ein Projekt ein Projekt?“.

Die Phasen des Projektlebenszyklus im Einzelnen

Die einzelnen Phasen des Projektlebenszyklus werden während des Projektverlaufs vom Projektteam der Reihe nach durchlaufen – allerdings weichen die Aufgaben des Projektmanagers dabei signifikant von denen seines Teams ab. Denn das Projektmanagement ist eher selten direkt an der Abarbeitung der Arbeitspakete beteiligt. Auch kommt das Team schwerpunktmäßig erst in der Umsetzungsphase zum Zug, während das Projektmanagement über alle Projektphasen hinweg aktiv ist und, Seite an Seite mit den Stakeholdern, im Wesentlichen übergeordnete Entscheidungen trifft.

Vielleicht interessiert Sie in diesem Zusammenhang auch unser Beitrag „Die Phasen im Webprojekt”.

Hier nun die vier entscheidenden Projektphasen:

Phase 1: Initiierung

Projekte beginnen mit einer mehr oder minder klaren Idee und münden in ein konkretes Vorhaben mit einem eindeutigen Ziel. Oder einer Vision, sofern es sich um agile Projekte handelt. Hier wie dort müssen der Auftraggeber und die Projektbeteiligten aber zunächst einmal die gleichen Vorstellungen von dem zu entwickelnden Produkt sowie dem hierfür anfallenden Zeit- und Kostenrahmen haben, und dies gilt es initial im Projektauftrag festzuhalten. Das ist dann der Startschuss für das Projekt.

Voraussetzungen dafür sind ein gegebener Bedarf im Zielmarkt sowie die personelle, technische und wirtschaftliche Durchführbarkeit des Vorhabens.

Die Initiierungsphase ist im Rahmen des Projektlebenszyklus ein strategischer Schritt, der den roten Faden für das Projekt vorgibt und in den nachfolgenden Phasen dem Management dabei hilft zu erkennen, ob das Projekt auf dem richtigen Weg ist.

Phase 2: Planung

In der Planungsphase legt der Projektleiter (idealerweise in enger Abstimmung mit seinem Team) fest, welche Einzelschritte in welcher Reihenfolge den besten Weg ins Ziel weisen. Dazu schnürt das Projektmanagement Arbeitspakete, weist diese jeweils geeigneten Mitarbeitern zu und kalkuliert mit Blick auf das Budget die einzelnen Aufwände. Auch die Auswahl der passenden Projektmanagement-Software fällt in diese Phase.

Zu diesen taktischen, in die Strategie eingebetteten Maßnahmen gehört darüber hinaus die Identifikation absehbarer Risiken, um diesen bestmöglich vorbeugen zu können. Bis hin zur Eindämmung projektgefährdender Folgen im Krisenfall. Es bedarf also eines guten Controllings, welches es dem Projektmanagement ermöglicht, genau dann gegenzusteuern, wenn beispielsweise Meilensteine nicht in der geplanten Zeit erreicht werden oder die Kosten aus dem Ruder laufen. All dies ist eine Frage der minutiösen Planung im Vorfeld.

Damit der Projektlebenszyklus jederzeit intakt bleibt, müssen zudem effiziente Kommunikationsprozesse voreingestellt werden. Nur so kann das Projektmanagement im Projektverlauf intern wie extern alle Beteiligten zeitnah und punktgenau informieren (und ggf. instruieren) und das Projekt über alle Projektphasen hinweg auf Kurs halten.

Phase 3: Umsetzung

Controlling und Projektsteuerung sind während der Realisierung des Projekts also das schlagende Herz des Projektlebenszyklus. Hierbei behält das Projektmanagement die Teilziele während der Umsetzung ebenso im Auge wie das übergeordnete Projektziel und gleicht routinemäßig (weder in zu großen noch in zu kleinen Intervallen) den Ist-Zustand mit dem Soll-Zustand ab. Indem so der Planfortschritt an „neuralgischen“ Punkten wie etwa den Meilensteinen erfassbar und bewertbar wird, bleibt das Projektteam handlungsfähig und kann etwaige Untiefen besser umschiffen.

Dazu sind nicht zuletzt regelmäßige Statusmeetings mit dem gesamten Projektteam notwendig. Hierdurch bleiben alle Projektbeteiligten auf demselben Stand, und das Team weiß, wann es was zu liefern hat. Außerdem können so Missverständnisse und Probleme rechtzeitig erkannt und Verzögerungen ausgeglichen werden, indem der Projektplan punktuell entzerrt wird. Daher sollte dieser immer gewisse Puffer vorsehen.

Mit anderen Worten: Wird die Dauer der Projektphasen (vor allem die Umsetzungsphase mit all ihren Einzelschritten) zu „optimistisch“ geplant, kann die Luft schnell dünn werden, wenn mal was nicht so gut klappt, und das Projekt in eine Schieflage geraten. Ein erfahrenes Projektmanagement weiß um dieses allgegenwärtige Risiko.

Phase 4: Abschluss

Der Projektlebenszyklus endet, wenn das im Projektplan definierte Ziel unter Erfüllung aller Leistungsmerkmale erreicht und das Produkt vom Auftraggeber abgenommen wurde. Zudem erstellt der Projektleiter einen Projektbericht.

Auch sollte eine „Lessons-learned-Analyse“ durchgeführt werden, in die sowohl die Erfahrungen des Projektteams als auch das Feedback vom Kunden einfließen. Die Leitfrage lautet dabei: Was lief gut, was lief schlecht? Ebenfalls im Projektbericht festgehalten, lassen sich auf Basis dieser Informationen und Erkenntnisse die Effizienz und mithin die Erfolgsaussichten zukünftiger Projekte steigern. All dies gilt selbstverständlich auch für gescheiterte Projekte.

Als Agentur für digitale Projekte weiß blindwerk, wie Sie Ihr Projektmanagement optimieren können. Im Erstgespräch ermitteln wir gerne zusammen mit Ihnen, welche Hebel dafür die richtigen sind.